Size: a a a

Compiler Development

2020 June 13

VT

Vasiliy Tereshkov in Compiler Development
Peter Sovietov
«Due to the efficient for loop implementation» — а за счет чего эффективность?
По сравнению с Wren - за счёт того, что подход ближе к C и не требует построения диапазона и операции in. Судя по туманным комментариям автора Wren, он сам не был доволен своим циклом for. Никаких benchmark'ов с активным использованием этого цикла он у себя, кажется, так и не опубликовал.
источник

PS

Peter Sovietov in Compiler Development
Vasiliy Tereshkov
По сравнению с Wren - за счёт того, что подход ближе к C и не требует построения диапазона и операции in. Судя по туманным комментариям автора Wren, он сам не был доволен своим циклом for. Никаких benchmark'ов с активным использованием этого цикла он у себя, кажется, так и не опубликовал.
А мне кажется, что дело, в первую очередь, в том, что Wren динамически типизирован. И при этом не имеет продвинутого JIT-компилятора. Думаю, полезнее было бы сравнить с LuaJit и V8. С перспективой сравнения с ЯП из своей весовой категорией (то есть со статической типизацией).
источник

PS

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

PS

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

VT

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

PS

Peter Sovietov in Compiler Development
источник

VT

Vasiliy Tereshkov in Compiler Development
Peter Sovietov
Кстати, странно со стороны автора Wren утверждать, что у него получилась быстрая реализация. Посмотрите на его VM: https://github.com/wren-lang/wren/blob/main/src/vm/wren_opcodes.h
Наверное, автор Wren вынес на суд публики только те тесты, за которые не стыдно (как, собственно, пока поступил и я с Umka - надеюсь исправиться). Ничего похожего на перемножение матриц автор Wren не показал. Вообще, интересно, как он борется с Lua. У Lua, начиная с 5-й версии, регистровая виртуальная машина - и она раза в 2...3 быстрее 4-й версии со стековой машиной. А в Wren - была и остаётся стековая.
источник

МБ

Михаил Бахтерев... in Compiler Development
IC Rainbow
билет 1: схему можешь написать - джун, пролог - мидл, идрис - сеньёр.
билет 2: интерпретатор - джун, ллвм эмитер - мидл, новый нескучный ISA - сеньёр.
билет 3: всё склеено мейком - джун, кастомная сборка - мидл, всё склеено мейком - сеньёр 😂
Б1: Когда игрушечная Схема написана, то игрушечный Пролог пишется на call/cc довольно быстро, я бы сказал, что прописать аккуратно механизм call/cc сложнее, чем потом прописать Пролог даже с некоторыми оптимизациями.

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

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

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

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

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

IR

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

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

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

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

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

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

AT

Alexander Tchitchigi... in Compiler Development
Переслано от Andrey @ozkriff Lesn...
источник

AM

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

AN

Alexander Nasonov in Compiler Development
Vasiliy Tereshkov
Моё подозрение на цикл for пало потому, что при трёх вложенных циклах Umka обходит Wren и Python (последний, вроде бы, как раз известен медлительностью for), но недотягивает до не-JITового Lua (а быстрота его реализации for, кажется, даже заставила в своё время делать именно на Lua фреймворк для нейросетей torch). При этом с точки зрения типизации, и Lua, и Wren - динамические, и в обоих массивы - это объекты. Более того, автор Wren уверяет, что по сравнению с Lua уменьшил потери от динамизма (благодаря NaN boxing).
У майка было несколько постов про циклы. Вот один из них http://lua-users.org/lists/lua-l/2011-02/msg00585.html
источник

А

Алексей ayaye :)... in Compiler Development
Alexander Malkov
Добрый день. У меня может такой, холиварный вопрос, но все таки.. что лучше использовать для разбора текста Flex/Bison или Antlr4?
я за antlr
источник

IK

Ivan Kochurkin in Compiler Development
Какого текста?
источник

PS

Peter Sovietov in Compiler Development
Alexander Nasonov
У майка было несколько постов про циклы. Вот один из них http://lua-users.org/lists/lua-l/2011-02/msg00585.html
Хорошо бы иметь разбор основных техник из LuaJIT. Причем, не на хакерском уровне, с погружением в не слишком существенные детали, а на нормальном инженерно-академическом. С указанием источников основных идей. Потому что Mike Pall не столько изобрел что-то новое, сколько аккуратно реализовал совокупность известных приемов.
источник

TS

Timur Safin in Compiler Development
Peter Sovietov
Хорошо бы иметь разбор основных техник из LuaJIT. Причем, не на хакерском уровне, с погружением в не слишком существенные детали, а на нормальном инженерно-академическом. С указанием источников основных идей. Потому что Mike Pall не столько изобрел что-то новое, сколько аккуратно реализовал совокупность известных приемов.
Хорошо бы @igelhaus есть такое где?
источник

PS

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

λ

λoλdog in Compiler Development
Alexander Malkov
Добрый день. У меня может такой, холиварный вопрос, но все таки.. что лучше использовать для разбора текста Flex/Bison или Antlr4?
Без разницы
источник

AN

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

AN

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