Распараллеливание, управление стековой, динамической памятью
-
- assistant
- Сообщения: 120
- Зарегистрирован: 05 сен 2019, 21:01
- Версия LabVIEW: 2019
- Контактная информация:
Re: Ускорение процесса при выделении стековой памяти
Я изучил материал, но, к сожалению, даются в основном общие слова о памяти, примеры использования, но не дается более строгое представление того, как разбита память и чему соответствует в LabVIEW тот же стек. Пока то, что я понял, это то, что динамическая память (heap) используется всегда, в том числе и под статические переменные, однако, можно программно заставить его выделять память либо из кучи, либо из статики, стековые аналогичным кодом тоже можно - правильно ли я понимаю ? Но где вообще в таком случае проявляется понятие стекового объекта ? Не могли бы вы привести какой нибудь пример объекта, чтобы мне было понятнее ?
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: Распараллеливание, управление стековой, динамической пам
Нельзя так программно "заставлять" LabVIEW работать с памятью. Просто это никому не нужно, т.к. компилятор берет всю работу на себя.
Мы делили апельсин - много наших полегло...
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Ускорение процесса при выделении стековой памяти
Более подробного описания, помимо того, что есть по ссылкам, не найдёте. Может, существуют какие-то внутренние доки в офисах NI, но ни у кого к ним доступа нет. Полагаю, как обычная программа под i386, использует стэк по прямому назначению - для передачи параметров (переменных) в отдельные подпрограммы (внешние вызовы), например тот же менеджер mgcore или какие-то иные внешние библиотеки, коих подключается довольно много при работе среды. В переменные push'атся, в подпрограмме pop'ятся. Ничего уникального тут не изобретено. Может быть, иногда какие-то операции с переменными выполняются inline как раз на стэке, раз это быстрее, чем в куче. По кр. мере я всё это вижу именно так, и ничего более подсказать не могу. Дебаггеры в помощь.dakishi писал(а):к сожалению, даются в основном общие слова о памяти, примеры использования, но не дается более строгое представление того, как разбита память и чему соответствует в LabVIEW тот же стек.
Не знаю, какими инструментами можно было бы сделать это из-под , то есть, прямо с диаграммы. И не видел никаких специальных функций для этого. Как вариант, вызов внешней DLL'ки с _alloca, и надо смотреть в отладчике, где он выделит область памяти. Ну, или реверсить движок и, возможно, переписывать часть функций по работе с памятью, что явно бессмысленная затея, т.к. жизни не хватит на это дело, и совсем скоро (буквально какие-то несколько лет) многие перейдут на NXG, которая почти с нуля переписана.dakishi писал(а):можно программно заставить его выделять память либо из кучи, либо из статики, стековые аналогичным кодом тоже можно - правильно ли я понимаю ?
Честно, не до конца этот вопрос понимаю. Ячейка памяти, выделенная на стэке, чем не объект? Тот же указатель на экземпляр класса в памяти, например. Или переменная INT32 в 4 байта размером. Есть указатель на объект, можно с ним работать.dakishi писал(а):Но где вообще в таком случае проявляется понятие стекового объекта ? Не могли бы вы привести какой нибудь пример объекта, чтобы мне было понятнее ?
Странное какое-то задание, что-то из области реверс-инжиниринга. Изучать работу с памятью легче всего было бы на какой-то маленькой самописной программке, но никак не на таком громоздком и сложном приложении как . Неужели препод может дать такое неподъёмное и бессмысленное задание? Оно бесперспективно со всех точек зрения. Или это ваши личные изыскания?
ЗЫ: старайтесь избегать мульти-цитирования, очень загромождает форум и становится тяжело читать сообщения. Не помню, прописано или нет это у нас в правилах, но это уместно на любом форуме. Есть быстрый ответ, есть расширенный ответ, есть тэги [ q ][ /q ].
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: Распараллеливание, управление стековой, динамической пам
dakishi, присоединяюсь к dadreamer - пожалуйста, не цитируйте кучу ответов. В предыдущих Ваших ответах я его убрал - постарайтесь на будущее цитировать по-сути (ведь можно процитировать конкретный кусок ответа, а не целый пост).
Мы делили апельсин - много наших полегло...
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: Распараллеливание, управление стековой, динамической пам
Как было выше уже отмечено компиляторы это нетривиальная задача даже для очень опытных программистов.как разбита память и чему соответствует в LabVIEW тот же стек
Как бы Вы распределили память в случае с Labview:
1. Какая ОС - MacOS, Windows, VxWorks, Linux, Pharlap, Ni Linux Rt
2. Какой процессор - motorolla 68000, x86, x86_64, ARM.
3. Какое железо. Может программа использует FPGA
4. Какой уровень оптимизации
Для каждого случая подход будет разный.
Максимальная глубина до которой можно дойти в Labview средствами Labview это константы, переменные, строки и массивы.
Погружение далее это С, С++. В последних версиях есть Python Node. Но здесь уже Labview заканчивается.