Преимущества LabVIEW 64

[jane_wild]

Ребята, будет ли скомпилированное приложение в среде LV 64 иметь преимущества над LV 32 при пересылке больших объемов информации? Я имею ввиду сбор данных сразу с пяти модулей по 32 канала каждый с Sampling rate 5000. (cDAQ 8 slots ethernet) Кроме того в проекте используются function global variable, в которых могут "крутится" до одного миллиона собраных значений. На PC утанолена W10 и память 16Gb. В каких случаях желательно использовать LV 64? Спасибо

[dadreamer]

По поводу работы с железом не скажу, но есть информация общего плана.
LabVIEW 32-Bit vs. 64-Bit Development Environments FAQ
LabVIEW 32-Bit and 64-Bit Compatibility

LabVIEW 64-bit does not provide any speed improvements over LabVIEW 32-bit, but it does allow the program access to more system memory at once.

Я пишу ПО в 64-bit, так как часто работаю с машинным зрением и порой приходится обрабатывать большие изображения. Ну, и всё равно рано или поздно 32 бита безнадёжно устареют, как это случилось с 16 битами. Уже сейчас всё больше разработчиков софта отказываются от поддержки x32.

Перекомпиляция программы для 64-битной системы позволит ей использовать огромные объемы оперативной памяти, а также убыстрит скорость ее работы на 5-15%. Убыстрение на 5-10% произойдет за счет использования архитектурных возможностей 64-битного процессора, например большего количества регистров. Еще 1%-5% прироста скорости обуславливается отсутствием прослойки WOW64, которая транслирует вызовы API между 32-битными приложениями и 64-битной операционной системой.

There are several benefits of 64-bit x86 over 32-bit x86: more addressable memory, more integer registers, twice the XMM registers, a better calling convention, guaranteed SSE2... The only downside is using 64-bit pointers, which implies more memory and cache usage. In practice, many programs can expect to be slightly faster in x64 (e.g. 10%), but pointer-heavy programs may even see a decrease in performance.

По поводу последней цитаты: поскольку указатели внутри используются на каждом шагу, то практический выигрыш при переходе на x64 составит не 10%, а где-то 5% или даже меньше.

[Artem.spb]

И все преимущества перечёркиваются фразой

Should I download the 32-bit or the 64-bit version of LabVIEW?
For new applications, NI recommends that you download the 32-bit version unless you require the additional memory provided by the 64-bit option. See LabVIEW 32-Bit and 64-Bit Compatibility for further discussion.

:)
К тому же не всё нормально работает в 64, поэтому я до сих пор держусь на этой версии. Например, работа со звуком (которая и так криво сделана) под 64 вообще не работа.
Так что тут надо по ситуации смотреть. Если нужны большие объёмы памяти, то без 64 никуда, а в остальном я предпочитаю 32.

[jane_wild]

Спасибо, стало немного понятней. Почитала по ссылкам... Получается держать обе версии LabVIEW на девелоперской машине без проблем, а вот увидеть или не увидеть преимущества возможно только скомпилировав и запустив приложение на реальной машине. Отсюда возник вопрос: уживутся ли RTE обеих версий на целевой машине? Что бы возможно было запуская их по очереди, оценить результат.

Повторюсь приложение работает с большими массивами, в одном из режимов в Functional global variable накапливаются массивы и выводятся на XY Graph. Нужно "держать" измерения в "сыром виде" минимум последние 5 минут, вот и получается 5000 rate * 300 sec = 1500000 измерений на один канал. А их четыре (два по Х и два по Y) пока получается без задержек и подтормаживания "держать" чуть больше трех минут, ограничив размер массивов по одному миллиону - при поступлении новой порции данных такое же колличество самых первых удаляются. А еще остальных канналов вагон и маленькая тележка, ресурсы отнимают, но хоть на график не выводятся.
Вот я и подумала, может 64 бита улучшат ситуацию.
PS Наш IT-шник попробывал поставить мощную видео карту Quadro P4000, предположив что проблема в ней,ситуация не изменилась, вернул обратно GeForce GTX 1650, а мог бы и оставить жмот

[Artem.spb]

уживутся ли RTE обеих версий на целевой машине?

При установке RT ставится автоматом. Отсюда следствие - уживутся, причём не только разной битности, но и разных версий.

Если я не ошибся в расчётах, то это гиганское количество точек занимает всего 22Мб. Ну может 44, если брать XY, а не только Y, отсюда вывод - памятинадо не так уж и много, а шансы ускориться минимальные.
Если уж пытаться ускоряться на аппаратном уровне, то надо память разгонять, а не видяху.

Оптимизировать надо в других местах.
У меня была схожая проблема при работе с "водопадом". Всё упиралось в неспособность машины "прокачать" несколько десятков Мб в памяти.
По софту надо разобраться, как вы данные гоняете. Если это массив "удалить-соединить", то стоит поискать в этом направлении.
С водопадом я разгонялся через DVR, хранил массив ссылок на строки водопада, вместо того, чтобы каждый раз строить новый двумерный массив. При передаче массивов из читалки в анализ опять же можно DVR протестировать, а не сразу массив в очередь отправлять.
Дальше можно подумать, а надо ли так часто обновлять графики.
Следующий шаг - о ужас - понизить точность (dbl->sgl->int).
В случае с водопадом всё элементарно, там шкалы не видны, только яркость, поэтому я без проблем перешёл в i16 и тем самым уменьшил объём данных в 4 раза без какой-либо потери "точности".
В итоге получаю стрёмный интерфейс с хорошей производительностью

[jane_wild]

Данные из "читалки" передаются очередью 2D массив, я где то читала что в очередях физически передаются ссылка на массив, а не сами данные.. может я не права.
Перед выводом на XY добавляю так

А вот как понизить разрядность 16-ти битного NI-9205 я не знаю, ведь в Polymorphic selector доступен только DBL

[Artem.spb]

А вот как понизить разрядность 16-ти битного NI-9205 я не знаю, ведь в Polymorphic selector доступен только DBL

sgl.png (9.18 КБ) 1895 просмотров

[dadreamer]

Данные из "читалки" передаются очередью 2D массив

На картинке 1D или что-то осталось за кадром?

я где то читала что в очередях физически передаются ссылка на массив, а не сами данные..

DVR так работает, собственно название Data Value Reference намекает. Очереди гоняют данные. На внутреннем уровне это может быть хэндл на массив, чтобы не создавать оверхэда при чтении/записи.

Может быть, здесь подойдёт кольцевой буфер? https://lavag.org/topic/21268-malleable ... ent=136237 Сделан на "малярных" Так что >= 2017. Для более старых есть такой тулкит: https://lavag.org/topic/18535-cr-circular-buffer/

[jane_wild]

На картинке 1D или что-то осталось за кадром?

Из очереди читается 2D массив, индексами выбираются нужные четыре 1D массива и далее уже на FGV и потом на XY Graph.

DVR так работает, собственно название Data Value Reference намекает

То что DVR работает по ссылкам это понятно, я имела ввиду, что где то читала мол несмотря на то, что тип очереди есть массив Double, на самом деле очередью физически передается ссылка на этот массив, вот не уверена что так оно и есть

Кольцевой буфер... Посмотрела по ссылке и даже скачала и установила vip. Там есть четыре примера, которые помогут разобратся, как это все работает. Поковыряюсь на досуге, может пойму. Никогда раньше Type Specialization Structure не приходилось применять..

[dadreamer]

Никогда раньше Type Specialization Structure не приходилось применять..

Внутрь лезть не обязательно. Этот буфер работает как запись в видеорегистраторе: буфер заполняется до тех пор, пока не будет достигнут его изначальный размер; как только это случается, старые данные затираются более новыми. То есть, буфер замкнут и бесконечен. Для передачи ссылки на буфер между параллельными потоками используется DVR. Также DVR позволяет получить доступ к внутреннему содержимому, если это необходимо. Если поток один, то можно обойтись безо всяких DVR, а работать с кластером (by-value).

Плюсов я тут два могу выделить:
- vim'ы адаптируются к типу буфера, так что возможно использовать одни и те же для буферов разных типов;
- при правильном использовании не будет создавать лишних копий данных (т.е., использование In Place Element Structure и галки Allow Parallel Read-Only Access, если нет модификаций данных).

Заметил тут, что при (пере)подключениях проводов к vim'ам почему-то не перекомпилирует основной и стрелка остаётся сломанной. Надо или сохранить или перекомпилировать принудительно: зажать Ctrl и кликнуть ЛКМ по стрелке запуска . Может, конечно, это у меня только так.

[Artem.spb]

Из очереди читается 2D массив, индексами выбираются нужные четыре 1D массива и далее уже на FGV и потом на XY Graph.

А FGV зачем?
Вообще, не очень понятная идея с ними в наших реалиях. Может я что-то при них не знаю, но их суть - замена global var во времена, когда GV не существовали. А сейчас это просто усложнение себе жизни (созданием ещё одного VI). Конечно, производительность не тестировал, но мне кажется FGV ничем не лучше обычных GV.
Ну и в целом, очередь->FGV->график. Т.е. очередь и график живут в разных мирах?
Хотя на картинке обычные сдвиговые используются.

[jane_wild]

А FGV зачем?
Вообще, не очень понятная идея с ними в наших реалиях. Может я что-то при них не знаю, но их суть - замена global var во времена, когда GV не существовали. А сейчас это просто усложнение себе жизни (созданием ещё одного VI). Конечно, производительность не тестировал, но мне кажется FGV ничем не лучше обычных GV.
Ну и в целом, очередь->FGV->график. Т.е. очередь и график живут в разных мирах?
Хотя на картинке обычные сдвиговые используются.

Видимо это я что то не знаю. Как Глобальная переменная может добавить к имеющимся данным, порцию новых? А вот FGV может и другого, простого, способа хранить собранные данные я не нашла. В XY нет истории, как в Chart и отображаются данные которые в данный момент поступили на вход. А мне нужно, как я уже упоминала, на XY отображать данные последних 5 ти минут обновляя их по мере поступления. Вот FGV и служит мне для этого, накапливая в сдвиговых регистрах данные, создавая таким образом историю.. Подскажите другой способ, буду признательна.
dadreamer вот предложил кольцевой буфер... обязательно попробую, возможно производительность улучшится...

[Artem.spb]

А вот FGV может

FGV как и GV может всё то, что запрограммируети программист :)
В вашем случае (если я правильно понимаю "архитектуру") FGV не особо нужны, те самые сдвиговые я бы организовал в самом цикле, а не выносил бы их во внешний subVI