executor. то есть некий субъект с обратной связью, неким окружением кем можно командовать и кого можно программировать для решения задач с визуальным фидбэком

Набираешь код на Лого и черепашка по экрану двигается

IPONWEB выпустил свой JIT в опенсорс :)

Здорово, но жаль что даже у заинтересованных в развитии джит команд нет координации усилий. Фрагментация сообщества только увеличивается.

Кажется (могу и ошибаться), что отсутствие координации -- одна из существенных черт опен сорса и не факт, что это плохо. Плюс эта фрагментация на самом деле меньше, чем кажется. На примере: если в raptorjit появится какое-то существенное улучшение, работающее в общем случае, нет почти никаких шансов, что оно не появится в luavela (и наоборот). Фрагментация касается каких-то частностей (и опять же не факт, что это плохо)

Примерно понимая в коком состоянии майк полл забросил разработку - кажется что все новые разработки даже на 10% вперед не ушли

А в каком состоянии Майк Полл забросил разработку? И что такое 10%?

Добавь в чат терминатора уже

Посмотрите 2.0 beta 3 и сравните с 2.1

I'm glad to announce the first public release of LuaVela, an implementation of Lua 5.1 based on LuaJIT 2.0. The project was started as a fork of LuaJIT 2.0 in 2015. The primary goal was to fix the notorious 2Gb memory limit on the x86-64 platform. Eventually the project accumulated several features that we would like to share with the community. List of major features: * Full support for 64-bit memory without any tricks or hacks in the interpreter and JIT compiler; * "Sealing": An ability to hide some data from the garbage collector. In IPONWEB, we use this generation-like (or, better, Eden-like) trick to mark data with the same lifetime as the application instance itself reducing overall pressure on GC; * Immutability: Data structures may be (recursively) marked immutable in run-time. This implemented via an extension API, the syntax of the language is unaffected; * Coroutine timeouts: There are C-level extension APIs that allow to control the life time of coroutines – once a coroutine runs for too long, it is terminated by the virtual machine; * Some new optimizations in the JIT compiler (but some of them are not brand new if one compares with LuaJIT 2.1); * New C- and Lua-level extension APIs; * Platform-level sampling profiler; * Memory usage profiler; * Platform-level code coverage. Apart from that: * CMake is used as a build system for the project; * 6 test suites are bundled with the project: Lua 5.1 test suite, LuaJIT test suite, CERN MAD test suite (partially), lua-Harness test suite and two suites written inside IPONWEB (for testing at Lua- and C-level, respectively); * Documentation bundle is included into the release, too. All the docs are in the RST format and make docs will build you the HTML version if you have Sphinx installed. This one is the last thing we prepared before the release, so apologies for some mishmash there, we will sort it out eventually. Feel free to ask any questions, but here is a FAQ list based on what I've been asked during my talks, etc.: Q: What does "Vela" in LuaVela mean? A: It is Vela constellation. Q: What does "uJIT" mean in the docs and the core code base? A: This is an internal name of the project in IPONWEB. Unfortunately, we could not simply strip it off prior to the public release, so apologies for possible confusion. LuaVela is the preferred public name of the project, uJIT is something like an internal "code name". Q: What is the level of compatibility with Lua 5.1? A: The same as for LuaJIT 2.0. But we wish we could make the implementation closer to the PUC-Rio implementation. Q: Why not LuaJIT 2.1 + LJ_GC64? A: As far as I know, this solution got stabilized by 2016-2017. Alas, we needed something working earlier. Besides, some experiments we ran in 2015 with LuaJIT 2.1 showed performance degradation for our cases. Q: What about support for Lua 5.2+? A: Unfortunately, we do not have resources to implement it on our own. However, patches are welcome. We definitely do *not* plan to increase the compatibility gap with the PUC-Rio implementation. E.g. dropping support for C API or any initiative like this is not an option for the project. Q: What about support for other OSes and other platforms than Linux x86-64? A: I doubt that 32-bit platforms will be supported. Regarding other operating systems, we do not have resources to implement it on our own. However, patches are welcome. And last, but definitely not least. Many people have worked hard to make this public release happen. I would like to acknowledge some of them personally: * Igor Ehrlich, the godfather of the project who started it and did an unbelievable amount of work during the project's early development and establishment phases. In 2016, he gave an excellent talk (sorry, in Russian only) about our reasons to start an own implementation [1]; * Maxim Bolshov, who put much of his expertise into JIT-related things; * Ilya Dailidyonok, who, apart from delivering various features, did a fantastic work polishing the code base at all levels preparing it for the public release.

Скачал, собрал. Не люблю скрипты cmake, это типа промышленный стандарт? Может потестируем на абстрактных тестах?

Есть (прошу прощения, не у компа) make prepare_benchmarks cd tests ./run_benchmarks.sh

что означает Vela?

@CyberSpirit вот кого надо на Highload++

я этого не знал

@igelhaus расскажите, что значит запечатать объект? seal

у вас ссылки не работают на странице с документацией. local a = ujit.immutable(value) а вот это просто делает его read-only, но как только оно выйдет из скоупа либо a = nil соберётся gc?

и ещё у вас везде используется api через ujit, а проект LuaVela - неконсистентно))

Это всё-таки не отвечает на мои вопросы (ещё раз): * А в каком состоянии по вашему мнению Майк Полл забросил разработку? * И что такое по вашему мнению 10%? Но я тем не менее как-то попробую ответить. Во-первых, бетой в 2019 году по-прежнему является ветка 2.1, а 2.0 – stable. Сравнивая 2.1 и LuaVela, я не берусь утверждать, что LuaVela – это bugless code, но я хотя бы могу сказать, что она крутится с 2017 года в боевом окружении, обрабатывая сотни миллиардов запросов ежесуточно (я не преувеличиваю). А про LuaJIT 2.1 у меня проверенной информации нет. При этом, возвращаясь к стабильной ветке 2.0: она просто не умеет работать со всей виртуальной памятью на 64-битной платформе на Линуксах, а LuaVela (как потомок стабильной 2.0) – умеет. Да, 2.1 имеет режим LJ_GC64, но, насколько я помню доклад Питера на митапе в Лондоне (смотрели?), этот режим стабилизировался только к 2017 году. Далее, не JIT-ом единым живы реализации Lua. Например, ещё хочется эффективно использовать память в бизнес-приложениях. Для этой цели и была добавлена функциональность силинга (о ней см. в анонсе) и DataState (забыл упомянуть об этом, это возможность задёшево разделять read-only данные между несколькими экземплярами VM). В этот момент мы бесплатным бонусом получаем возможность делать какие-то данные иммутабельными (как я рассказывал на докладе в прошлом году, ujit.immutable(_G) спасает нас от проблем опечаток в именах переменных). Но если мы говорим о JIT-е: * В LuaVela затащено очень многое из того, что есть в LuaJIT 2.1. Из крупного, что не сделано – trace stitching для "компиляции" вызовов Lua C API; * В LuaVela есть расширения стандартной бибилиотеки, в которых собраны некоторые полезные на наш взгляд функции общего назначения. Они написаны на C, и многие из них JIT-компилируются; * В LuaVela появились оптимизации, которые помогают улучшить работу машинного кода при обилии с операциями с памятью (это очень частый случай при скриптовании бизнес-логики, и вот тут оригинальный JIT ведёт себя не очень хорошо – безусловно делая всех в чисто вычислительных задачах). Наконец, код платформы опубликован сразу с несколькими тестовыми сюитами и документацией, которую мы писали, накапливая экспертизу в течение многих лет. Можно брать, смотреть, пробовать, тестировать, контрибутить. В общем и целом – да, проблема фрагментации, безусловно, есть. Это тот случай, когда сильная сторона языка оборачивается его же слабостью. Но утверждение про 10% – это выглядит как-то непонятно.

И это тоже верно. Мы поправим, спасибо!

Что нового в 5.4 я не очень знаю но даже 5.3 поддержки нет и не планируется

потом будем экспериментировать дальше: function foo() mt = {} mt.__close = function() print("close a") end mt.__gc = function() print("gc a") end local <toclose> a = {} setmetatable(a, mt) return a end local d = foo() print("======") Должно быть: close a ======= gc a

Все что описано типа поддержки ппмяти больше 2 гиг читать смешно и странно

Есть (прошу прощения, не у компа) make prepare_benchmarks cd tests ./run_benchmarks.sh

Все что описано типа поддержки ппмяти больше 2 гиг читать смешно и странно

А что в этом смешного и что странного?

оформите новость на IT ресурсах: habr, opennet, tproger, linux.org.ru

Сделал apt-get install libtext-table-perl liblist-allutils-perl и оно заработало. Работало довольно долго, загружен был только один процессор. Тесты ведь можно замногопоточить?

ему обидно что мы отстаём от js и питона

он гений?

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

Ну то есть та же идея с GC была имплементирована не раз и не дала никакого перф буста