По сравнению с Wren - за счёт того, что подход ближе к C и не требует построения диапазона и операции in. Судя по туманным комментариям автора Wren, он сам не был доволен своим циклом for. Никаких benchmark'ов с активным использованием этого цикла он у себя, кажется, так и не опубликовал.

А мне кажется, что дело, в первую очередь, в том, что Wren динамически типизирован. И при этом не имеет продвинутого JIT-компилятора. Думаю, полезнее было бы сравнить с LuaJit и V8. С перспективой сравнения с ЯП из своей весовой категорией (то есть со статической типизацией).

Кстати, странно со стороны автора Wren утверждать, что у него получилась быстрая реализация. Посмотрите на его VM: https://github.com/wren-lang/wren/blob/main/src/vm/wren_opcodes.h

И сравните с Вашей, где есть тот же getarrayptr. Понятно, почему тест  с перемножением матриц так себя показывает. Тут и динамическая Umka бы победила :)

Моё подозрение на цикл for пало потому, что при трёх вложенных циклах Umka обходит Wren и Python (последний, вроде бы, как раз известен медлительностью for), но недотягивает до не-JITового Lua (а быстрота его реализации for, кажется, даже заставила в своё время делать именно на Lua фреймворк для нейросетей torch). При этом с точки зрения типизации, и Lua, и Wren - динамические, и в обоих массивы - это объекты. Более того, автор Wren уверяет, что по сравнению с Lua уменьшил потери от динамизма (благодаря NaN boxing).

Собственно, вот: https://github.com/wren-lang/wren/blob/main/src/vm/wren_compiler.c#L2865

Наверное, автор Wren вынес на суд публики только те тесты, за которые не стыдно (как, собственно, пока поступил и я с Umka - надеюсь исправиться). Ничего похожего на перемножение матриц автор Wren не показал. Вообще, интересно, как он борется с Lua. У Lua, начиная с 5-й версии, регистровая виртуальная машина - и она раза в 2...3 быстрее 4-й версии со стековой машиной. А в Wren - была и остаётся стековая.

Б1: Когда игрушечная Схема написана, то игрушечный Пролог пишется на call/cc довольно быстро, я бы сказал, что прописать аккуратно механизм call/cc сложнее, чем потом прописать Пролог даже с некоторыми оптимизациями.

Игрушечный Idris -- это примерно нечто сравнимое по сложности с самой Схемой: с одной стороны, нужна абстрактная интерпретация свободных переменных, а с другой не нужны call/cc и макросы, которые в Схеме доставляют проблем.

Если речь идёт о полноценных Схеме, Прологе и Идрисе, то ранжирование тоже не очевидно. В каждой из тем есть свои серьёзные вызовы. В Схеме -- это оптимизация, в Прологе -- методы оптимизации и эффективный поиск, совмещённый с вводом/выводом, в Idris -- заморочки с тем, как организовывать контексты вывода типов, неявные (implicit), взаимную рекурсивность, кодировки для индуктивных типов, проверки тотальности и прочее такое. Впрочем, и в Схеме, и в Прологе, придётся тоже работать (при оптимизации) с выводом и типов, и свойств функций, а в Idris надо работать с оптимизациями, хотя тут полегче.

Б2: сделать свой нескучный IR гораздо проще, чем уложиться в многолетние наслоения идей и костылей в LLVM. Чисто технически LLVM требует более обширных знаний и больших навыков, чем изобретение свеженького, красивого и уютного IR.

Б3: gnu make уже давно поддерживает сценарии на Guile, поэтому, теперь для make кастомное и не кастомное -- понятия довольно расплывчатые.

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

всё так. поэтому градации такие и есть. на это третий пункт третьего билета толсто намекает.

Добрый день. У меня может такой, холиварный вопрос, но все таки.. что лучше использовать для разбора текста Flex/Bison или Antlr4?

У майка было несколько постов про циклы. Вот один из них http://lua-users.org/lists/lua-l/2011-02/msg00585.html

я за antlr

Какого текста?

Хорошо бы иметь разбор основных техник из LuaJIT. Причем, не на хакерском уровне, с погружением в не слишком существенные детали, а на нормальном инженерно-академическом. С указанием источников основных идей. Потому что Mike Pall не столько изобрел что-то новое, сколько аккуратно реализовал совокупность известных приемов.

Хорошо бы @igelhaus есть такое где?

Читатели PLComp знакомы с небольшой статьей Later Binding: Just-in-Time Compilation of a Younger Dynamic Programming Language. Но она довольно поверхностная.

Без разницы

Я думаю, что код Майка надо читать как роман Улисс, с профессиональными комментариями, но увы, комментариев пока нет.

Вот тут есть одностраничное описание идей LuaJIT, но это пересказ главного поста Майка  (LuaJIT 2.0 intellectual property disclosure and research opportunities) http://files.catwell.info/misc/mirror/tracing-jit-haskell-schilling.pdf#page179