Ничто так не поднимает самооценку, как расписывание рекрутёру своей экспертизы в 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. Но, блин, ОЧЕНЬ ТИХО ВСЁ