Комментарии 8
Скажите, пожалуйста, вот вы пишите — «Если придумаете какие-то крутые правила оптимизации, смело высылайте». А нет ли какого-то правила, определяющего, можно ли добавлять данную оптимизацию в компилятор?
Почему спрашивюа. Новая оптимизация — это раздувание кодовой базы, усложнение проекта. А если оптимизация касается какого-то совсем маргинального кейса (например, если была бы возможность считать за одну инструкцию выражение вида: "a^34 + b^c"), то возможно имеет смысл не усложнять компилятор.
Новая оптимизация — это раздувание кодовой базы, усложнение проекта.
Да, но для новых SSA правил обычно порог принятия довольно низок. Если выглядит полезным — вливают. Уровень усложнения кодовой базы считается невысоким.
А нет ли какого-то правила, определяющего, можно ли добавлять данную оптимизацию в компилятор?
Каждый коммит в компилятор рекомендуется сопровождать бенчмарками и, если релевантно, статистикой изменения размера бинарников (тут помогают утилиты benchstat и bincmp). Самой ленивой проверкой является запуск ./make.bash с подсчётом срабатываний нового правила.
Если оптимизация именно на Go дистрибутиве не очень срабатывает, но выглядит полезной, стоит найти другой проект, где она срабатывает и даёт измеримый прирост.
Чем больше аргументов и статистики на руках — тем лучше.
При генерации кода из Rules можно передать параметр -log:
flag.Bool("log", false, "generate code that logs; for debugging only")Тогда при ./make.bash (и вообще любом компилировании) будут подсчитываться все срабатывания правил. Только осторожно, там между запусками будет append в файл, так что он может до нескольких гигабайт вырасти достаточно незаметно; не забудьте выключить. :)
А как дела обстоят с межпроцедурными оптимизациями в компиляторе?
Самый честный ответ: никак. Все оптимизации локальны для одной функции.
Только в случае встраивания вызываемой процедуры будет нормальная оптимизация.
В ближайшем будущем максимум, чего можно ожидать:
- Встраивание не только листовых функций (сейчас оно доступно, но не включено по умолчанию).
- Улучшение cost модели для принятия решений о встраиваемости функций (cmd/compile: improve inlining cost model).
Возможно если бы кто-то показал, что глобальная оптимизация Go программ имеет эти свойства:
- Может быть реализована без значительного замедления компиляции.
- Значительно ускоряет программы, которые чувствительны к производительности.
То со временем это бы вливали в мастер. Сначала в виде эксперимента, потом в виде поведения по умолчанию, если бы не было значительных недостатков.
Ну это либо действительно доказывать, либо надо смотреть публикации по теме компиляторов. Их, кстати, довольно много. Так что, думаю, найдутся и статьи со значительным приростом производительности.
Оно само собой, что лучше перенять опыт других компиляторов, но тут скорее вопрос насколько большой выигрыш именно для Go и наиболее типичных программ.
Если у кого-то HPC может стать на 30% быстрее, то это не настолько весомый аргумент, потому что всё равно будет медленнее, чем на некоторых других языках.
Если же каким-то образом из-за этого компилятор станет быстрее за счёт более оптимального его же кода, процентов на 5, то вот на это волосы сообщества будут резонировать.
Компилятор Go: язык описания правил SSA оптимизаций