Size: a a a

2021 November 06

RA

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

RA

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

ШТ

Шмель Тяжеловес... in pro.lua
В luajit мне нравится идея трассировки и отслеживания горячих участков кода.
источник

RA

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

ШТ

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

ШТ

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

ШТ

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

RA

R A in pro.lua
За всё приходится так или иначе платить. В трейсинге расходы просто становятся скрытыми. Но вот эта скрытость, во-первых, достаточно неприятно накапливается, во-вторых, поддерживать тяжело. СА как выделенный этап тут выигрывает.
источник

RA

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

ШТ

Шмель Тяжеловес... in pro.lua
Спасибо.
источник

RA

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

ШТ

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

RA

R A in pro.lua
Ну т.е арены? Стандартный подход.
источник

ШТ

Шмель Тяжеловес... in pro.lua
Они самые.
источник

ШТ

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

RA

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

ШТ

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

RA

R A in pro.lua
Gradual method-based. Эффект даст, но без СА неполноценный.
источник

M

Mikhail in pro.lua
Ну что... Luau теперь для всех. Больше это не часть Роблокса.

https://devforum.roblox.com/t/luau-goes-open-source/1534471
источник

S

Snusmumriken in pro.lua
Ля, ты опоздал где-то на неделю, уже обсудили и обсосали ))
источник