#prog #lisp #amazingopensource
LISP with GC in 436 bytes (достаточно, чтобы уместиться на загрузочном секторе)
LISP with GC in 436 bytes (достаточно, чтобы уместиться на загрузочном секторе)
justine.lol
LISP with GC in 436 bytes
LISP engine that's tiny enough to fit in a 512-byte master boot record
Ничто так не поднимает самооценку, как расписывание рекрутёру своей экспертизы в Rust
Forwarded from Venithinking
когда я встречаю людей, которые носят одноразовые маски по несколько дней, мне всегда хочется спросить: "у вас есть любимая одноразовая салфетка, которой вы вытираете рот?"
Блог*
Так всё-таки, для чего нужен dependency injection?
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from 🎵Илья проигрывает пианино 🎵
Наблюдаю динамическое программирование в реальном времени, кажется они готовы сдаться спустя пол часа
Хиханьки да хаханьки. А я тут телефон уронил в воду. И теперь непонятно, насколько он живой.
Да, я пытался его просушить. Нет, не вышло, потому крышку снять не удалось, не смотря на где-то полчаса, кажется, возни с ней. Короче, оставил в сухом рисе.
Невозможность как-то повлиять на это сильно меня расстроила. А ещё это мне показало, насколько сильно я полагаюсь на свой телефон. Я, блин, ни деньги другому человеку перенести теперь не могу, ни заказать такси, ни заранее билет на электричку купить.
Короче, если завтра он не будет в порядке, то я отменяю нафиг все планы. Не могу так.
Да, я пытался его просушить. Нет, не вышло, потому крышку снять не удалось, не смотря на где-то полчаса, кажется, возни с ней. Короче, оставил в сухом рисе.
Невозможность как-то повлиять на это сильно меня расстроила. А ещё это мне показало, насколько сильно я полагаюсь на свой телефон. Я, блин, ни деньги другому человеку перенести теперь не могу, ни заказать такси, ни заранее билет на электричку купить.
Короче, если завтра он не будет в порядке, то я отменяю нафиг все планы. Не могу так.
#prog #rust #article
В rustc есть такое дизайнерское решение: замыкание захватывает в сгенерированном типе все типы из своего окружения, в том числе и те, которые не имеют никакого отношения к коду замыкания. Это приводит к увеличению числа генерируемого LLVM IR и, как следствие, замедлению компиляции. И если выдумаете, что это чисто теоретическая проблема, то вот вам опровержение: issue в репе раста, в которомТолян David Tolnay говорит, что:
> In fact this closure contributes more LLVM IR than all but 5 significantly larger functions
И это для замыкания, которое делает то, что вообще не зависит от захватываемых параметров!
Один из подходов для решения этой проблемы — добавить анализ, который будет проверять, что тИповые параметры реально используются, и для неиспользуемых не проделывать мономорфизацию. Именно такой анализ под названием "polymorphisation" реализовал человек по имени David Wood, причём как часть своей магистерской диссертации. К сожалению, выяснилось, что этот анализ неполон и в реализованном виде может приводить к мискомпиляции кода (метка regression-from-stable-to-nightly). В итоге проблему пришлось решить отключением полиморфизации.
С того момента утекло немало воды и были внесены некоторые улучшения, но полиморфизация так и осталось проходом, отключённым по умолчанию. В немалой степени это связано с тем, что этот анализ был реализован в виде запроса, который рассматривает не более одной функции за раз. Для уточнения анализа требовалось сделать анализ транзитивным, что не работает с текущей архитектурой компилятора, которая запрещает циклы запросов. Я связался с Давидом, и он сказал мне, что у lcnr есть идеи, как это можно исправить, и даже дал ссылки на наработки: 1, 2. Другое дело, что в текущем виде решение пока что неработоспособно, и последнее шевеление был в октябре этого года. Давид, впрочем, сказал, что это у него в списке дел на следующий год.
И ещё кое-что. Отсутствие полиморфизации позволяет написать код, в котором замыкание захватывает собственный тип и потому приводит к ошибке компиляции на этапе мономорфизации. Что совсем нехорошо, мономорфизация происходит по требованию, а потому то, компилируется код или нет, зависит от уровня оптимизации, точнее, от того, сможет ли оптимизация убрать мертвый путь исполнения, который триггерит бесконечную мономорфизацию.
Вот такая вот фигня.
P. S.: диссертацию советую прочитать, это неплохой экскурс во внутреннее устройство rustc, а в начале много ссылок на работ по оптимизации, связанные со специализацией и генерализацией кода.
В rustc есть такое дизайнерское решение: замыкание захватывает в сгенерированном типе все типы из своего окружения, в том числе и те, которые не имеют никакого отношения к коду замыкания. Это приводит к увеличению числа генерируемого LLVM IR и, как следствие, замедлению компиляции. И если выдумаете, что это чисто теоретическая проблема, то вот вам опровержение: issue в репе раста, в котором
> In fact this closure contributes more LLVM IR than all but 5 significantly larger functions
И это для замыкания, которое делает то, что вообще не зависит от захватываемых параметров!
Один из подходов для решения этой проблемы — добавить анализ, который будет проверять, что тИповые параметры реально используются, и для неиспользуемых не проделывать мономорфизацию. Именно такой анализ под названием "polymorphisation" реализовал человек по имени David Wood, причём как часть своей магистерской диссертации. К сожалению, выяснилось, что этот анализ неполон и в реализованном виде может приводить к мискомпиляции кода (метка regression-from-stable-to-nightly). В итоге проблему пришлось решить отключением полиморфизации.
С того момента утекло немало воды и были внесены некоторые улучшения, но полиморфизация так и осталось проходом, отключённым по умолчанию. В немалой степени это связано с тем, что этот анализ был реализован в виде запроса, который рассматривает не более одной функции за раз. Для уточнения анализа требовалось сделать анализ транзитивным, что не работает с текущей архитектурой компилятора, которая запрещает циклы запросов. Я связался с Давидом, и он сказал мне, что у lcnr есть идеи, как это можно исправить, и даже дал ссылки на наработки: 1, 2. Другое дело, что в текущем виде решение пока что неработоспособно, и последнее шевеление был в октябре этого года. Давид, впрочем, сказал, что это у него в списке дел на следующий год.
И ещё кое-что. Отсутствие полиморфизации позволяет написать код, в котором замыкание захватывает собственный тип и потому приводит к ошибке компиляции на этапе мономорфизации. Что совсем нехорошо, мономорфизация происходит по требованию, а потому то, компилируется код или нет, зависит от уровня оптимизации, точнее, от того, сможет ли оптимизация убрать мертвый путь исполнения, который триггерит бесконечную мономорфизацию.
Вот такая вот фигня.
P. S.: диссертацию советую прочитать, это неплохой экскурс во внутреннее устройство rustc, а в начале много ссылок на работ по оптимизации, связанные со специализацией и генерализацией кода.
GitHub
Instantiate fewer copies of a closure inside a generic function · Issue #46477 · rust-lang/rust
In serde-rs/json#386 we observed that a disproportionately large amount of serde_json lines of LLVM IR and compile time are due to a tiny closure inside a generic function. In fact this closure con...
Совсем забыл сказать, стали доступны (пока что не публично) записи с докладов #RustCon2021. Но, блин, ОЧЕНЬ ТИХО ВСЁ