LabVIEW Compiler

[Igor_G]

Добрый день,
долго дискутировал с LabVIEW Support на тему оптимизации кода для LabVIEW Compiler.
Идея достаточна простая - сконвертировать исходник в binary формат оптимированый для LabVIEW Compiler и работать с ним. После получения результата - сконвертировать назад в формат исходника.
Цель - экономия ресурсов РС. Думаю дальше объяснеть не надо почему.
Вопрос лишь в том какой с каким форматом LabVIEW Compiler дружит? LabVIEW Support - сказал что не имеет права давать эту информацию, но получить ее другими путями криминала нет.
Есть у кого Идеи, как можно эту Информацию вытащить с помощью LabVIEW?
П.С.
Где то читал уже (по моему здесь, но найти больше не могу), что кто-то уже дорылся намного дальше (с помощью LabVIEW и был код) на каком языке написана LabVIEW. Может знает кто, где это?
На основе этого можно было бы узнать то что я хочу получить.

[dadreamer]

Читали вот эту статью: http://www.labview-rus.blogspot.ru/2010/01/3.html ?

[Borjomy_1]

А вам не кажется, что проблема оптимизации лежит в большей части, в области написания программы? Напихают там всяких экспресс-Vi-ев, а потом удивляются, а чего-это исполняемый файл разбух. Большой размер программы, в том числе, при выполнении, связан с тем, что вам значительно легче манипулировать большими объемами данных, чем в других средах. Если есть необходимость оптимизировать объем, то гораздо выгоднее искать пути оптимизации алгоритма. Встроенные средства позволяют выявлять места, где производится копирование данных.

Модуль, который позволяет делать приложения под Windows CE (PDA Module), транслирует VI в СИ-шные файлы, которые потом компилируются через MS Visual Studio. Естественно, они не показываются и скидываются во временный каталог, однако если очень хочется заниматься извращениями, то можно их оттуда выдернуть.
Внутренние функции написаны на СИ, это несомненно. Однако большая часть функций и вы это можете сами видеть - написана на Labview.

[dadreamer]

Посмотрите также вот эту тему, там есть полезные вещи относительно оптимизации.

[AndreyDmitriev]

Идея достаточна простая - сконвертировать исходник в бинарный формат оптимированый для LabVIEW Compiler и работать с ним. После получения результата - сконвертировать назад в формат исходника.

Мне вот думается, вы сами не очень хорошо понимаете, чего хотите. Особенно непонятна фаза "сконвертировать назад в формат исходника."

Сама по себе ядро LabVIEW написано на C++ (для LV2012 использовалась Visual Studio 2008) с привлечением кой-каких сторонних библиотек (Qt довольно активно пользуется, Intel MKL для математики и т.д). "Обвеска" (типа тех же пробников, многочисленные диалоги и инструменты) - на том же LabVIEW.

Внутри там, скажем так, некий псевдо язык - и в этом смысле он ничем не отличается от того же Си (ну с той лишь разницей, что не в текстовом, а во внутреннем формате). То, что мы видим на блок-диаграмме - просто графическое представление. В режиме разработки в виртуальном инструменте присутствуют блок-диаграмма и скомпилированный код (в последних версиях его можно отделить от VI и хранить отдельно - это удобно для системы контроля версий). Компиляция происходит "на лету", что приятно (в этом смысле LabVIEW впереди планеты всей). В скомпилированном в исполняемый файл инструменте присутствует только скомпилированный код - блок диаграмма там уже не требуется.

Собственно для компиляции используется виртуальная машина LLVM (http://llvm.org). То, что вам суппорт говорит, что это закрытая инфа - это чушь, зайдите на http://llvm.org/Users.html - там NI с LabVIEW чёрным по белому. Собственно процесс компиляции - он в несколько проходов осуществляется. Вначале разумеется проверяется то, что диаграмма правильна (ну то есть все типы, отсутствие "broken wires" и т.д.). Затем блок-диаграмма переводится в представление DFIR (Dataflow Intermediate Representation) - не знаю, как это лучше назвать по-русски, но по сути это просто граф (скорее несколько подграфов, ибо код в процессе компиляции объединяется в "сгустки", которые затем будут выполняться параллельно - я как-нибудь об этом напишу). Затем производится декомпозиция и оптимизация - выбрасывается ненужный код, оптимизируются вычисления. Ну, к примеру если какие-то вычисления производятся в цикле, но могут быть вынесены за его пределы, то это возможно будет оптимизировано. После этого оптимизированный граф DFIR переводится в представление LLVM. Я не думаю, что используется текстовая фаза, скорей всего компилятор LLVM был слегка "допилен" NI, и туда сразу отправляются двоичные данные. Компилятор компилирует код в машинный, который и иполняется, когда вы жамкаете по кнопке Run.

Как работает компилятор, можно вот тут почитать:
http://www.ni.com/white-paper/11472/en

Код, выдавемый LabVIEW "на гора" действительно не оптимален и прожорлив, но я, право, плохо понимаю, что вы тут хотите оптимизировать на "бинарном" уровне и какие ресурсы собираетесь экономить. Теоретически, вы можете подсунуть внутреннему компилятору LLVM, который используется на последней фазе, свой собственный "оптимизированный" код (профит, кстати, будет небольшой, ибо за "неоптимальность" в основном LLVM отвечает), либо зайти с другой стороны, и перехватить DFIR и перевести его в машинное представление своим "оптимизированным" компилятором в обход LLVM. Проблема в том, что процесс компиляции осуществляется "на лету" и закрыт - у вас просто нет той "точки вхождения" за которую вы могли бы "зацепиться". Потребуется серьёзный реверс-инжиниринг и целая система хуков. Трудоёмкость процесса сравнима с написанием опенсорсного LabVIEW с нуля - в одиночку и жизни может не хватить.

Ещё пара замечаний про перевод LabVIEW кода в Си. Такая возможность действительно есть, но при компиляции инструмента этот механизм не используется и к предмету дискуссии эта фича не имеет никакого отношения. Вдобавок львиная доля функций не поддерживается. Кроме того, там генеряется однопоточный исходный код, то есть стоит положить пару несвязанных While циклов на диаграмму и генерация Си кода станет невозможна (впрочем последнюю версию тулкита я не ковырял).

Так что просто изначально рисуйте оптимальный код. Когда совсем уж упрётесь в производительность - можно преписать часть на Си (можно даже и на ассемблере), скомпилировать в DLL, либо использовать высокопроизводительные библиотеки типа тех же интеловских - будет куда как быстрее.

[dadreamer]

AndreyDmitriev

Давно хотелось спросить такую вещь. Скомпилированный код можно достать из VICD и посмотреть его листинг... Но как его запустить? Простое переименование расширения ничего не даёт. Если честно, когда я с этим экспериментировал, я ожидал увидеть сразу лицевую панель и прочие фишки, как после компиляции в App Builder'е. Неужели панель компилируется отдельно и потом как-то аттачится" к процессу?.. Прошу прощения за безграмотность :)

[AndreyDmitriev]

AndreyDmitriev

Давно хотелось спросить такую вещь. Скомпилированный код можно достать из VICD и посмотреть его листинг... Но как его запустить? Простое переименование расширения ничего не даёт. Если честно, когда я с этим экспериментировал, я ожидал увидеть сразу лицевую панель и прочие фишки, как после компиляции в App Builder'е. Неужели панель компилируется отдельно и потом как-то аттачится" к процессу?.. Прошу прощения за безграмотность :)

Запустить извлечённый код так просто не получится - он не самодлостаточен, а на рантайм и другие ресурсы завязан
Панель там лежит в отдельном ресурсе, не в VICD (я не сомтрел, где именно, это может быть ресурс FPHP или что-то типа этого). Код ссылается на ресурсы панели. Кстати, из скомпилированного в exe VI панели удаляются (если это, конечно не Top Level, где панель необходима), так что визуальное представление панели и внутреннее представление ресурсов - они тоже разделены, как и в случае с блок-диаграммой. Что касается "прямого" запуска кода - то тут требуется загрузчик этого самого кода (в режиме разработки эту роль берёт на себя сама LabVIEW, а при запуске исполняемого файла - рантайм). Переименовывать извлечённый из ресурса код (в exe) смысла не имеет, ибо Windows тоже имеет свой определённый формат исполняемых файлов - там есть заголовок, ресурсы, собственно код, и т.д. Это всё равно что dll в exe переименовать - оно от этого работать не будет. Ну а запуск приложения LabVIEW грубо говоря выглядит примерно следующим образом - там в exe файле есть небольшой загрузчик, килобайт на 50, который ищет соответствующую версию RunTime, найдя её, вызывает основную функцию (типа WinMain), после чего эта функция извлекает из исполняемого приложения код (по сути там просто zip архив с набором VI) в память (его ведь ещё распаковать надо), создаёт необходимое количество потоков, передаёт им управление, а сама встаёт в бесконечный цикл, обрабатывающий сообщения Windows (такой цикл должен быть в любом Windows приложении). Именно когда этот цикл останавливается, мы видим сообщение "приложение не отвечает". Где-то так. Это на самом деле всё домыслы, ибо это не документировано, но, полагаю я недалёк от истины.

[dadreamer]

AndreyDmitriev

Большое спасибо за разъяснения. Жаль, конечно, что сделано немного не так, как в традиционных языках: при каждом запуске разрабатываемого приложения код компилируется сразу в exe вместе со всеми ресурсами (формы, картинки, скины, менюшки) и лежит себе спокойно в папке вместе с исходниками... Но если бы каждый раз вызывал полноценный exe-builder, программа сильно бы тормозила и запускалась секунд через 5 как минимум.

[Igor_G]

Сначала большое спасибо за линки. Есть что почитать и над чем подумать.

(1) Все что существует в цифровом формате - можно рассматривать, как бинарный формат. Поэтому исходник (график, текст ... в поставленом вопросе не имеет ни какого значения).
(2) Бинарный формат - не что иное как набор 0,1. И занимаемое им место не зависит от того, как информация интерпретируется (a, или 12(okt), или 01100001, или 61(hex), или 97(dez), или YQ==(base64)). При условии, что бит кодировка конечно остается постоянной.
(3) Различные компиляторы отличаются друг от друга, тем что они по разному работают с бинарным форматом.
(4) LаbVIEW компилирует "на лету". Согласен, что это удобно, но до определённого момента. И в этот момент надо бы знать, что же делает compiler и как ему облегчить работу. Т.е. предложить ему тот формат который он не будет больше преобразовывать "на лету" и работать дальше иммено в этом формате. Тем самым будут экономиться ресурсы компьютера - которые расходуются обычно на luxus (компиляция "на лету" в двух направлениях). Уходить от этого luxus я хочу только в самых критических моментах, когда дальнейшая оптимизация обычными путями не помогает.

Единственное что я хочу знать - что предложить LаbVIEW compiler чтобы он прекратил свой "полет" и начал спокойно "переваривать" уже "разжеванную пищу". Как раз на этот вопрос суппорт отказался категорически отвечать (секрет).

П.С.
Меня сегодня больше всего интересует работа с текстовыми файлами (1-5 ГБ). Они содержат практически всю ASCII таблицу (за исключение конечно первых 32 символов). ASCII имеет изначально имел 7bit кодирунг, сегодня 1byte => ожидается, что LаbVIEW compiler будет резервировать для каждого ASCII символа 1byte или 7bit. На практике - 6bit. Здесь тоже было бы очень интересно узнать ASCII 6bit таблицу которую использует LаbVIEW. На этот вопрос суппорт отказался категорически отвечать тоже. А ведь он опять же пусть и косвенно, но привязан к вопросу LаbVIEW compiler формата.

[Borjomy_1]

(4) а что вас в этом напрягает? Энергопотребление или то, что температура процессора повысится на 1 градус? У вас компьютер подтормаживает? Если нет этого, то никакого практического значения эта задача не имеет.

[dadreamer]

Igor_G
Приобретите сами, или пусть предприятие закажет, более мощное оборудование (компьютеры, контроллеры, платы ввода-вывода, ...), если вам так важна скорость и производительность. Вы собираетесь дорабатывать продукт, который создавался с 1986 года множеством людей на нескольких платформах... Скорее всего вы не привнесёте ничего нового, а лишь потратите собственное время.

[AndreyDmitriev]

Единственное что я хочу знать - что предложить LаbVIEW compiler чтобы он прекратил свой "полет" и начал спокойно "переваривать" уже "разжеванную пищу". Как раз на этот вопрос суппорт отказался категорически отвечать (секрет).

Это не то чтобы секрет, просто нет такой возможности. Проще выражаясь - просто нет той "тарелки", куда вы можете положить "разжёванную пищу". В последних версиях там и так всё достаточно оптимизировано, чтобы максимально исключить промежуточные фазы компиляции (прочтите два последних абзаца в параграфе 2 по ссылке, что я выше дал).

Меня сегодня больше всего интересует работа с текстовыми файлами (1-5 ГБ). Они содержат практически всю ASCII таблицу (за исключение конечно первых 32 символов). ASCII имеет изначально имел 7bit кодирунг, сегодня 1byte => ожидается, что LаbVIEW compiler будет резервировать для каждого ASCII символа 1byte или 7bit. На практике - 6bit. Здесь тоже было бы очень интересно узнать ASCII 6bit таблицу которую использует LаbVIEW. На этот вопрос суппорт отказался категорически отвечать тоже. А ведь он опять же пусть и косвенно, но привязан к вопросу LаbVIEW compiler формата.

Уж не обижайтесь, но этот страшный поток сознания даже страшно комментировать. Нет никакой "ASCII 6bit таблицы которую использует LаbVIEW". Компьютер изначально оперирует байтами, размер которых - восемь битов. Либо словами, размер которых - два байта. У него изначально такая архитектура. Ну вот, к примеру, у меня на столе лежит камера, которая отдаёт мне картинку в 12 бит. В памяти каждый пиксель тем не менее занимает 16 бит (четыре остаются не заняты). Теоретически камера могла бы писать два пикселя в три байта, но мне пришлось бы выполнить распаковку этих данных, что вызвало бы почти двойной расход памяти.

Если я правильно улавливаю вашу цель - у вас есть некие данные, где каждый символ может иметь максимум одно из 64х возможных значений (то есть занимает 6 бит). Вы хотите сократить объём используемой памяти, как оперативной, так и дисковой, поместив первый символ в первый байт, заняв шесть бит, затем два бита следующего символа в тот же самый байт, а четыре оставшихся - в следующий, и так далее. Так что четыре шестибитных символа будут занимать три восьмибитных байта. Вообще это называется "битовая упаковка". Понятно, что все функции работы со строками такой формат переварить не смогут. И вы хотите подсунуть компилятору "разжёванный" код, оперирирующий шестибитными данными? Скажем так, если бы вы смогли переключить регистры и память компьютера в "шестибитный" режим, то это имело бы смысл, но такой возможности нет. Таким образом упакованные данные всё равно придётся распаковывать, либо выполнять маскирование битов при всех операциях и получить тем самым неслабые пенальти в производительности (почитайте про битовые поля на досуге). Если вы просто упираетесь в ограничение памяти - просто перейдите на 64 бит систему и соотвтетствующую версию LabVIEW, храните свои шестибитные данные в восьмибитных байтах и наступит счастье. Ну либо обрабатывайте данные блоками.

Вообще сентенция про шесть бит - она тоже спорная. В английском языке, если мне не изменяет память - 26 букв. В двух регистрах это даёт нам 52 значения. Плюс цифры 0...9 - получается 62. Перевод строки тоже нужен. Знаки препинания вам, стало быть не требуются?

[Andrew Lunev]

Меня сегодня больше всего интересует работа с текстовыми файлами (1-5 ГБ). Они содержат практически всю ASCII таблицу (за исключение конечно первых 32 символов). ASCII имеет изначально имел 7bit кодирунг, сегодня 1byte => ожидается, что LаbVIEW compiler будет резервировать для каждого ASCII символа 1byte или 7bit. На практике - 6bit. Здесь тоже было бы очень интересно узнать ASCII 6bit таблицу которую использует LаbVIEW. На этот вопрос суппорт отказался категорически отвечать тоже. А ведь он опять же пусть и косвенно, но привязан к вопросу LаbVIEW compiler формата.

Я вас еще больше расстрою. Например для хранения переменной типа Boolean LabView использует 32 бита. Это связано с тем, что так получается быстрей работать с переменной. Вроде как для современных процессоров это самая оптимальная величина адресации. То есть приоритет отдается быстродействию, а не использованию памяти.
Если на один символ будет уходить 7 бит, то как их будет адресовать алгоритм? Скорее он должен будет прочитать 2 байта и потом битовыми операциями вытащить из них ваш символ. Это намного ухудшит быстродействие, чем если тратить на символ 8 бит. Да и идея хранить данные в текстовом файле размером 5 Гб это вообще какое-то извращение. За такое увольнять надо тех, кто проектировал систему и придумывал формат данных.
P.S. Конечно в байте может быть любое кол-во бит, но уже очень давно принято, что в байте 8 бит. Почему у вас в байте 7 бит? У вас какая-то особенная система?

[Andrew Lunev]

Вообще сентенция про шесть бит - она тоже спорная. В английском языке, если мне не изменяет память - 26 букв. В двух регистрах это даёт нам 52 значения. Плюс цифры 0...9 - получается 62. Перевод строки тоже нужен. Знаки препинания вам, стало быть не требуются?

Автор вопроса сместил все значения на 1 бит. Изначально ASCII таблица была 7-бит, потом в нее добавили псевдографику и дополнительные символы и стало 8-бит. У него же и в байте 7 бит и в ASCII 6 бит. Видимо он "законченный программист" раз даже в обычной жизни счет начинает с нуля. :) То есть приходит в магазин и просит продать ему ноль батонов хлеба...

[dadreamer]

ТС, а ноги-то похоже отсюда растут?.. Вы всё так же пытаетесь обрабатывать гигантские текстовые файлы, генерируемые PCAN Explorer? И те советы вам не помогли?