Комментарии 9
Раст это мой основной язык, но черт возьми, почему компилятор раста такой медленный и скорость не очень скейлится от числа процессоров?
Мономорфизация генериков. Чем больше вложенных типов в ваших угловых скобках, тем сложнее выводить тип финальной функции, не говоря уже о проблемах параллелизации этого процесса.
Вторая замедляющая компиляцию штука - активное наваливание макросов на всё что можно. Макрос генерирует больше кода. Больше кода - больше компилировать. А уж если макрос генерирует вызовы генериков, то добавляется ещё и первый пункт. Вот и получается не быстро.
Особнячком стоит процесс финальной кодогенерации для некоторых таргетов. Генерация кода под wasm, например, не сказать чтобы быстрая и даже демка из wasm-pack будет генерировать wasm бинарь довольно заметное время. Поэтому, если вам сложилось заниматься вебнёй, то мои вам соболезнования, вам придётся биться на мечах с соседом. Впрочем, пока не изобрели языка, где аналогичные действия происходили бы быстрее.
Всегда есть возможность выбросить комбайн и скрафтить собственный специализированнй пайплайн, который почти наверняка окажется быстрее, но большинство не станут этим заниматься.
попробуйте написать свой простенький компилятор, и запустите цикл с принтом до 1000000 и замерьте время, благо щас можно компилятор заточить на такое, и там всё станет очевидно, понятно, что компилятор будет медленнее или не совсем если оставить только принт до 1000000, но там будут моменты где вы увидите почему так, раст вроде на окамл или на С++, но сути не меняет, скан генерация, дерево, и машинный код
кстати, что на llvm писать парсер, что свой даже не знаю из плюшек только как я понял это машинный код и IR, из '-' толстая зависимость
многие примеры по компиляторам это либо бейсик либо лсп, либо на питоне, либо С++, как я понял голд версия это ansi, с прямой прокидкой в машинный код, но это уровень gcc ), вот попробуйте написать С на С, через байткод и там будет всё очевидно
парсинг - время, вставки, и генерация машинного кода с оптимизациями, или генерация jit
Хорошее изложение, но пропущен этап семантического анализа, разрешающий имена идентификаторов - когда синтаксическое дерево превращается в семантический граф.
В этом графе узлы описания (с возможной инициализацией) и использования переменной в изначальном дереве могут ссылаться на структуру содержащую её имя и тип, которую можно представить тоже как узел. Или же можно ссылаться от узла использования переменной к узлу её описания. То же самое для функций, типов и других идентификаторов.
Раньше компиляторы описывали как конвейер из 5 стадий: лексический анализ, синтаксический анализ, семантический анализ, оптимизация, кодогенерация. Первые три стадии постепенно всё меньшую часть компилятора занимают, поэтому о них меньше пишут и меньше внимания уделяют. Сейчас просто выделяют бэкенд и фронтенд компилятора. Мне так видится причина.
Да, наверное так. Основная моя претензия именно к наименованию структуры, когда продолжают использовать в подобных статьях термин дерево (AST) вместо графа (ASG - уже семантического) после разрешения идентификаторов - возможно, это вызвано либо непониманием, либо наименованием структуры в коде, где дерево трансформируется в граф "на месте" и т.о. наименование остаётся прежним.
Что происходит после fn main() в Rust?