Мы используем файлы cookie и сервисы аналитики. Ознакомьтесь с нашей Политикой сбора данных и выберите, какие типы cookie вы разрешаете:
cookie_policy_accepted — хранит ваш выбор cookiePHPSESSID — сессияkey3 — запоминание входа_ix — единая сессия входа на ixbt.comadminuserskey — вход администратораtopic_add_autosave — автосохранение черновикаls_photoset_target_tmp — временные данные загрузки фотоgeo_country — определяет ваш регион_ga, _ga_*, _ym_uid, _ym_d, _ym_* — статистика посещений__gads, __gpi — таргетирование объявленийВы всегда можете изменить свои предпочтения в настройках.
«Движок портирован в режиме „интерпретатора“ — ahead-of-time шаблонного компилятора с внутренним предствавлением на псевдоассемблере....»
Там этот код можно раз в 15 оптимизировать…
https://youtu.be/5TtOQQAtt3A
И игрухи современные вполне нормально тянет при наличии правильно скомпилированных исходников.
https://youtu.be/5TtOQQAtt3A
https://youtu.be/5TtOQQAtt3A
1) Движок портирован в режиме «интерпретатора» — 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.
https://youtu.be/5TtOQQAtt3A
«Движок портирован в режиме „интерпретатора“ — ahead-of-time шаблонного компилятора с внутренним предствавлением на псевдоассемблере.»
Движок портирован в режиме «интерпретатора» — ahead-of-time шаблонного компилятора с внутренним предствавлением на псевдоассемблере…
И далее по тексту закрепенного ко мента а данном видосе
…
«Движок портирован в режиме „интерпретатора“ — ahead-of-time шаблонного компилятора с внутренним предствавлением на псевдоассемблере… „
https://youtu.be/5TtOQQAtt3A
Нормально скомпилированная игрушка вот в этом примере: https://youtu.be/5TtOQQAtt3A
https://youtu.be/5TtOQQAtt3A
Просто надо уметь дорабатывать напильником программный код…
Дайте угадаю, игру запустили в режиме двоичной трансляции?
А давайте сравним как интел будет тащить реалтайм трансляцию сталкера в кодах иксбокса например…