Size: a a a

Compiler Development

2020 March 21

PS

Peter Sovietov in Compiler Development
А есть ли статистика по всему переднему плану, реализованному в rust? Там же никаких серьезных оптимизаций не наблюдается и работы на уровне SSA нет. Неужели столько усилий из-за проверки на ошибки и из-за легкого анализа потоков данных для заимствований и подобного? :)
источник

M

MaxGraey in Compiler Development
Peter Sovietov
Время разбора вполне может занимать и половину всего времени компиляции. Сужу по некоторым чужим и своим компиляторам. А у Вас откуда информация?
Иногда даже больше
источник

p

polunin.ai in Compiler Development
Peter Sovietov
А есть ли статистика по всему переднему плану, реализованному в rust? Там же никаких серьезных оптимизаций не наблюдается и работы на уровне SSA нет. Неужели столько усилий из-за проверки на ошибки и из-за легкого анализа потоков данных для заимствований и подобного? :)
ну из того что я видел большую часть времени занимает кодогенерация из макросов и генерация LLVM IR кода. Это в дебаге. А в релизной сборке там большую часть времени занимают как раз оптимизации. И эти оптимизации уже могуть занимать десятки минут и часов.
источник

p

polunin.ai in Compiler Development
но это не объективно, я просто пару раз игрался с профилировщиком. насчет есть ли статистика - хз
источник

p

polunin.ai in Compiler Development
ну или взять интерпретируемые языки. если бы парсинг у них занимал времени много, они были бы не нужны.
источник

M

MaxGraey in Compiler Development
polunin.ai
ну я пишу в основном на Rust сейчас, там парсинг 50к+ строк занимает 31 мс
Смотря каких строк. Если каждая строка будет содержать макросы то это легко может в n^2, n^3 асимпторику выродиться
источник

p

polunin.ai in Compiler Development
MaxGraey
Смотря каких строк. Если каждая строка будет содержать макросы то это легко может в n^2, n^3 асимпторику выродиться
макросы - это вынужденное зло, их стараются не использовать где это не надо
источник

PS

Peter Sovietov in Compiler Development
polunin.ai
ну или взять интерпретируемые языки. если бы парсинг у них занимал времени много, они были бы не нужны.
Речь в данном случае о доле разбора в общем времени компиляции. Для интерпретируемых языков 1/2 и даже более (как правильно уточнил @maxgraey ) — обычное явление.

А по поводу часов на оптимизации, это ведь уже этап LLVM, который мы договорились исключить из рассмотрения.
источник

M

MaxGraey in Compiler Development
polunin.ai
ну из того что я видел большую часть времени занимает кодогенерация из макросов и генерация LLVM IR кода. Это в дебаге. А в релизной сборке там большую часть времени занимают как раз оптимизации. И эти оптимизации уже могуть занимать десятки минут и часов.
На самом деле это просто LLVM IR пассы и последующая кодогенерация довольно медленные. Мы не используем LLVM и у нас токенизация и парсинг - это основное время даже с включенными оптимизациями на полную
источник

EZ

Evgeniy Zheltonozhskiy🇮🇱 in Compiler Development
источник

MB

Mikail Bagishov in Compiler Development
MaxGraey
Смотря каких строк. Если каждая строка будет содержать макросы то это легко может в n^2, n^3 асимпторику выродиться
По идее, с макросами несложно добиться и экспоненты
источник

M

MaxGraey in Compiler Development
Mikail Bagishov
По идее, с макросами несложно добиться и экспоненты
да
источник

PS

Peter Sovietov in Compiler Development
Mikail Bagishov
По идее, с макросами несложно добиться и экспоненты
источник

MB

Mikail Bagishov in Compiler Development
Там была не экспонента. Там был квадрат или куб, из-за дерева доминаторов.
источник

MB

Mikail Bagishov in Compiler Development
А, я вроде с чем-то путаю.
источник

PS

Peter Sovietov in Compiler Development
Да уж :)
источник

MB

Mikail Bagishov in Compiler Development
У кого-то была проблема, что у него была очень большая функция, в которой борроучекер находил очень много ошибок.
И для репорта каждой ошибки он считал на всей этой функции доминаторы.
источник

PS

Peter Sovietov in Compiler Development
Mikail Bagishov
У кого-то была проблема, что у него была очень большая функция, в которой борроучекер находил очень много ошибок.
И для репорта каждой ошибки он считал на всей этой функции доминаторы.
Тут надо учитывать, конечно, что "квадрат или куб" на практике могут означать не то, что ожидается в теории. У компиляторщиков особенной популярностью пользуется алгоритм нахождения доминаторов за O(n^2) от Купера и др.
Хотя это далеко не самый лучший теоретический результат, но см. http://www.hipersoft.rice.edu/grads/publications/dom14.pdf
источник

DP

Dmitry Ponyatov in Compiler Development
polunin.ai
это 0,07% от общего времени компиляции
для компиляторов скорость разбора не слишком важна, но вот для опдизайнеров сейчас модно грузить терабайтные JSONы,  и использовать многоступенчатую (де)сериализацию в ASCII форматы
источник

BD

Berkus Decker in Compiler Development
бага пофикшена уже
источник