Вот к примеру еще один

очень неудачный синтаксис констант

LuaJIT.

ну лично у меня всегда была надежда что луаджит подтянется до 5.4, но до пенсии боюсь не будет

для ленивых: означает жёсткий запрет страницам памяти быть одновременно записываемыми из запущенного процесса и исполняемыми

Арсений "zeux" Капулкин этим занимается не первый год. У них вроде jit там свой был или они пробовали что-то такое.

Смотрю его твиттер. Категорически согласен про инструментарий.

У luajit есть ограничения. А один из основных недостатков на мой взгляд - очень мутный и плохо поддерживаемый исходный код. При всей мощи и красоте что-то исправить в нем проблематично.

Поэтому я и говорю: переписать его на плюсы. Для начала. А потом от трассировки отказаться.

Трассировка сильная сторона на мой взгляд. Не стоит от нее отказываться.

Поэтому я и говорю: переписать его на плюсы. Для начала. А потом от трассировки отказаться.

Ну типа да. Зачем переписывать на плюсы если уже написано на сишке? Какой профит дадут плюсы? Потому что видно только ухудшения.

(даже переписывание Сишного кода Майка на Си обычного человека даст выигрыш. Извинити)

Если реализовать трассировку, она будет невозможна на сишке. Майк шаманил с динасмом, динасм нереализуем на сишке и плюсах насколько я знаю.

Если реализовать трассировку, она будет невозможна на сишке. Майк шаманил с динасмом, динасм нереализуем на сишке и плюсах насколько я знаю.

Если реализовать трассировку, она будет невозможна на сишке. Майк шаманил с динасмом, динасм нереализуем на сишке и плюсах насколько я знаю.

Трассировка сильная сторона на мой взгляд. Не стоит от нее отказываться.

(даже переписывание Сишного кода Майка на Си обычного человека даст выигрыш. Извинити)

Почему бы не запилить ECS или аналог? DOD? Потому что ООП понятнее всего для типовых разработчиков? )

Была сильной. Сейчас тормозит развитие.

> Сишка многократно лучше портируется и стабильно функционирует. Потеряешь несколько десятков платформ и разрастёшь бинарь раз в тридцать. А ещё он начнёт требовать visual c++ пяти разных версий или аналогов. Да, да, бинарь можно обрезать. Но смысл? Ещё потеряются сишные интерфейсы, которые используют ВСЕ: шарпы, сами плюсы, всякие расты и прочие голанги, при подключении внешних либ.

Да, понятно для типовых разработчиков. К примеру стратегии оптимизатора кода можно сделать расширяемыми. Наследуйся от базовых классов и пробуй.

Методы LuaJIT уже потырили в пых и v8 ))

Можете рассказать подробнее о проблемах?

Если я не ошибаюсь jit как концепция имеет академическое происхождение. Кстати в C# и Erlang также компиляция по требованию.

В Эрланг 24 чистый АОТ. Называется JIT, потому что типа "оно само вызывается".

Накладные расходы на контекст, многопоточность, сборка. Вероятно, всё решаемо, но по мере решения выигрыш по сравнению с метод-бэйсед сперва нивелируется, затем становится отрицательным.

Просто я в расылке либы AsmJit видел ссылки на исходный код Erlang. Зачем-то они применяют AsmJit? Особо глубоко я не заглядывал.

Можете рассказать подробнее о проблемах?

Method-based, есть статьи почитать что за подход?

В детали не лез, но компиляция там строго после загрузки модуля, но перед исполнением.

Возможно для чего-то вроде ffi? Для генерапции кода вызова внешних функций. Вот кстати интереснейшая библиотека https://asmjit.com/ Но я не люблю C++

Тут как вышло. Меня сосватали на Луа/ЛЖ как раз тогда, когда вышел Эрланг 24. В итоге я по инерции погонял 24 на всяких бенчах, что-то там отслеживаю - но глубоко в кишки, как раньше, уже не лез. Когда по работе дойду до следующего этапа, вот там будут задействованы идеи в том числе из Эрланга, буду вникать.

В luajit мне нравится идея трассировки и отслеживания горячих участков кода.

Сейчас мне понятно, что метод+статический анализ будут быстрее, чем трейс. Но СА должен быть заточен под язык. С Луа это по очевидным причинам сложно.

Это красивая идея, но в долгосрочной перспективе проигрышная. Но красивая.

К тому же на современных машинах может иметь смысл использовать несколько потоков. Основной поток - код пользователя и вм, сгенерированный код. Второй поток может допустим по таймеру сканировать память первого потока и проверять временные метки циклов(сколько раз вызывался код и тд) в памяти и переписывать часть кода. Пока только концепт.

Мне не нравится то, что статический анализ занимает много времени. Он хорош, но тормозит цикл разработки. Если допустим 20% вычислительного времени будет занимать нагрузка от вирт машины и среды выполнения, а 80% - собственно выполнение кода пользователя, то уже хороший расклад. Теряешь производительность, особенно в момент запуска программы, загрузки модули и т.д. но выигрываешь в скорости разработки.

К тому же на современных машинах может иметь смысл использовать несколько потоков. Основной поток - код пользователя и вм, сгенерированный код. Второй поток может допустим по таймеру сканировать память первого потока и проверять временные метки циклов(сколько раз вызывался код и тд) в памяти и переписывать часть кода. Пока только концепт.

Оно несколько не так работает, конечно. Там даже расстановка меток требует определённых эвристик (читай: интуиции). И в итоге всё равно выделенный "горячий путь" оказывается довольно мал. Да, он охренеть как быстр, но не 100%, и девиации логики его ломают. А метод, может, и помедленнее, но это под 100% кода. Сильно упрощаю, конечно.

Также можно использовать шире механизм виртуальной памяти. Я не знаю как это работает в LuaJit, не помню эти моменты. Идея в выделении большого куска через mmap или VirtualAlloc и писать в него код. Тут еще нужен отдельный менеджер памяти со списком свободных блоков. Большой кусок - от нескольких гигабайт. Я не ориентируюсь на встроенные системы, а скорее на многоядерные машины с достаточным количеством памяти.

В LuaJIT вариант dlmalloc. Отличная штука, быстрая, но общего назначения. Хотя, может, Майк уже допилил custom-fit.

Я говорю про выделение большого участка вирт памяти и сверху свой менеджер памяти. Вот здесь рассказывается про такой подход https://www.youtube.com/watch?v=0SrB7O4udZQ&ab_channel=GaijinJam

Ну т.е арены? Стандартный подход.

Ну т.е арены? Стандартный подход.

Еще мне не очень нравится, что в LuaJit используется свой ассемблер. Я хочу использовать FASM в своей реализации. Он компактен, многопроходен и быстр, не требует линковщика(встроенный).

Только он статический. Скомпилять "int foo(int, int)" легко, потому что заранее всё известно. Компилять "function foo(a, b)" куда сложнее, потому что хрен его знает, что прилетит со стека. Поэтому надо уметь на ходу подстраиваться. В итоге DynASM - это такой своеобычный вариант IR, как во многих современных трансляторах.

У меня такая идея - взять ванильую Lua и добавлять в нее вызовы своей библиотеки в разный местах. После генерации кода, в основной цикл и т.д. Библиотека пишется на Rust, в нее встроен FASM. Те начать не с переписывания Lua, а с замены выполнения байткода своим генерированным кодом. Не уверен в таком подходе, но он позволит начать с минимальных изменений в код Lua. И в целом легче переносить на все версии - 5.2, 5.3, 5.4

так-то, в индустрии трассирующие jit-ы проиграли https://news.ycombinator.com/item?id=16204373

Всем привет , хочу сделать заказ на языке ЛУА , для World of Warcraft игры... Кто готов взяться ,Пишите в личку.

Lua *

Идея в том, что трассирующие jit могут позволить писать программисту "говнокод", но он будет довольно хорошо работать. К примеру использовать сложное многоуровневое хэширование, создавать много промежуточных объектов. Человек пишет понятный ему код, занимается логикой алгоритма. А машина оптимизирует до приемлемого уровня. Статический анализ может не дать таких выгод, особенно с динамическими языками.

Всем привет , хочу сделать заказ на языке ЛУА , для World of Warcraft игры... Кто готов взяться ,Пишите в личку.

ну вот ПОЧЕМУ, ПОЧЕМУ ВЫ ВСЕ ПИШЕТЕ "Lua" КАПСЛОКОМ, А?!?!?!?!?!?!?!?!

ну вот ПОЧЕМУ, ПОЧЕМУ ВЫ ВСЕ ПИШЕТЕ "Lua" КАПСЛОКОМ, А?!?!?!?!?!?!?!?!

ага... вы ещё JAVA пишите

Just Another Vendor-lock Achtung? :)

ага... вы ещё JAVA пишите

а может просто надо больно бить за говнокод?

g'zactly

Ор

ну вот ПОЧЕМУ, ПОЧЕМУ ВЫ ВСЕ ПИШЕТЕ "Lua" КАПСЛОКОМ, А?!?!?!?!?!?!?!?!