А теперь основная причина тормозов указана товарищем @helce:
1) Движок LuaJIT портирован в режиме «интерпретатора» — ahead-of-time шаблонного компилятора с внутренним предствавлением на псевдоассемблере.
2) Проект выложен в открытый доступ за исключением кодогенератора, с предгенеренным кодом на github-е: github.com/helce/LuaJIT
3) Порт достаточно медленный в виду архитектурных особенностей движка, т.к. используется рандом-доступ к шаблоном с вычислением адреса каждого следущего и хранение всех операндов и результатов операций в памяти. Т.е. для выполнения простейшей операции a = b, требуется загрузить операнды из памяти, вычислить a, записать в память, вычислить адрес следующего шаблона, подготовить операнды и передать управление. В итоге заместо одного такта получается в районе 20 в «хорошем случае» и сотни в случае кэш-промахов. На интелах подобная модель может работать относительно быстро, т.к. планированием всего этого счастья будет заниматься процессор, на эльбрусе такое же не прокатывает.
4) По моим расчетам можно сделать минимум раз в 10-15 быстрее, если переписать механизм взаимодействия шаблонов на использование «шаблонных лент», с записью в память только на переходах. Это и jit-итить имеет смысл, т.к. код получится связанный. И планирование будет в разы лучше. По крайней мере тестовый компилятор brainfck получился довольно быстрым (на нем отлаживал кодогенератор dynasm).
5) Однако это довольно большой объем работы, а т.к. у автора luajit не то что документации нет, а даже с комментариями в коде беда, проще с нуля написать. Но боюсь у меня нет столько свободного времени.
6) Jit-а в текущих реалиях не планируется, т.к. толку от него будет мало, да и запрещено пока публиковать opcode-ы, а кодогенератор то на lua написан и будет требовать установки на машину.
7) Ошибки все еще присутствуют минорные, т.к. тестов конкретно luajit немного, а api отличается от ванильного lua-5. Несколько ошибок удалось отловить как раз на openxray.
1) Движок LuaJIT портирован в режиме «интерпретатора» — ahead-of-time шаблонного компилятора с внутренним предствавлением на псевдоассемблере.
2) Проект выложен в открытый доступ за исключением кодогенератора, с предгенеренным кодом на github-е: github.com/helce/LuaJIT
3) Порт достаточно медленный в виду архитектурных особенностей движка, т.к. используется рандом-доступ к шаблоном с вычислением адреса каждого следущего и хранение всех операндов и результатов операций в памяти. Т.е. для выполнения простейшей операции a = b, требуется загрузить операнды из памяти, вычислить a, записать в память, вычислить адрес следующего шаблона, подготовить операнды и передать управление. В итоге заместо одного такта получается в районе 20 в «хорошем случае» и сотни в случае кэш-промахов. На интелах подобная модель может работать относительно быстро, т.к. планированием всего этого счастья будет заниматься процессор, на эльбрусе такое же не прокатывает.
4) По моим расчетам можно сделать минимум раз в 10-15 быстрее, если переписать механизм взаимодействия шаблонов на использование «шаблонных лент», с записью в память только на переходах. Это и jit-итить имеет смысл, т.к. код получится связанный. И планирование будет в разы лучше. По крайней мере тестовый компилятор brainfck получился довольно быстрым (на нем отлаживал кодогенератор dynasm).
5) Однако это довольно большой объем работы, а т.к. у автора luajit не то что документации нет, а даже с комментариями в коде беда, проще с нуля написать. Но боюсь у меня нет столько свободного времени.
6) Jit-а в текущих реалиях не планируется, т.к. толку от него будет мало, да и запрещено пока публиковать opcode-ы, а кодогенератор то на lua написан и будет требовать установки на машину.
7) Ошибки все еще присутствуют минорные, т.к. тестов конкретно luajit немного, а api отличается от ванильного lua-5. Несколько ошибок удалось отловить как раз на openxray.