Pull to refresh

Comments 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 программ имеет эти свойства:


  1. Может быть реализована без значительного замедления компиляции.
  2. Значительно ускоряет программы, которые чувствительны к производительности.

То со временем это бы вливали в мастер. Сначала в виде эксперимента, потом в виде поведения по умолчанию, если бы не было значительных недостатков.

Ну это либо действительно доказывать, либо надо смотреть публикации по теме компиляторов. Их, кстати, довольно много. Так что, думаю, найдутся и статьи со значительным приростом производительности.

Оно само собой, что лучше перенять опыт других компиляторов, но тут скорее вопрос насколько большой выигрыш именно для Go и наиболее типичных программ.


Если у кого-то HPC может стать на 30% быстрее, то это не настолько весомый аргумент, потому что всё равно будет медленнее, чем на некоторых других языках.


Если же каким-то образом из-за этого компилятор станет быстрее за счёт более оптимального его же кода, процентов на 5, то вот на это волосы сообщества будут резонировать.

Sign up to leave a comment.

Articles