Вы пишете (в разделе про FDO) "ускорение до 10%". Подскажите — это сравнение с режимом без профиля вообще, или с профилем, собранным perf’ом? Если первое, было ли сравнение того, как более высокая точность perforator’а влияет на результаты FDO (по сравнению с perf’ом)? И было ли сравнение с PGO?
И еще вопрос, если позволите: в начале статьи вы пишете "мы регулярно оптимизируем самые крупные сервисы в Яндексе… на десятки процентов". Речь идёт о ручной оптимизации (программист посмотрел в профиль, сказал "ага!" и соптимизировал) или автоматической (тот же FDO — или что-то другое?)
Есть флаг -S, который поддерживают абсолютно все компиляторы. И нет, он точно не "отсохнет". :-)
Что касается бинарного кода — не забывайте, что исполняемый файл создаёт не компилятор, а линкер. И он ещё как может поменять бинарий! — вплоть до замены инструкций (например, длинные переходы / вызовы на короткие).
Это при использовании достаточно старого clang (6.0). В новых версиях может быть всё по-другому. Как бы там ни было, полагаться на неопределённое поведение — ошибка!
Не совсем понятно, о какой инфре идёт речь?
То есть perforator не умеет работать с программами, обработанные BOLT’ом?
То есть собранный профиль можно скормить go компилятору?
Отличный проект и статья — спасибо!
Вы пишете (в разделе про FDO) "ускорение до 10%". Подскажите — это сравнение с режимом без профиля вообще, или с профилем, собранным perf’ом? Если первое, было ли сравнение того, как более высокая точность perforator’а влияет на результаты FDO (по сравнению с perf’ом)? И было ли сравнение с PGO?
И еще вопрос, если позволите: в начале статьи вы пишете "мы регулярно оптимизируем самые крупные сервисы в Яндексе… на десятки процентов". Речь идёт о ручной оптимизации (программист посмотрел в профиль, сказал "ага!" и соптимизировал) или автоматической (тот же FDO — или что-то другое?)
Ясно, спасибо!
quasilyte Спасибо за подробный анализ!
Подскажите, были ли оформлены результаты в виде тикетов для gc?
Да, имелось в виду второе.
Сорри, если не совсем понятно выразился. :(
Равно как и в LLVM community нужно делать всё перечисленное.
Конечно, если основатель community твой сотрудник, то делать это сильно проще.
Я бы не стал говорить, что Clang / Apache 2.0 "лучше" или "хуже" GCC / GPLv3.
Лицензии отталкиваются от разных философских принципов. Результат в мире компиляторов — такой, что я описал. К сожалению, GPL явно тормозит дальнейшее развитие GCC. "Принципы важнее"? © Ричард Столман — возможно, не берусь судить. Это уж точно вопрос политический.
Думаю, точные причины менеджеров Apple могут знать только они сами — да и то может забыли за давностью лет. :-)
То, что я написал (про "секретное железо") я лично слышал от людей из Apple на встрече по GCC в 2007 году. Так что я как чукча — что вижу, то и пою.
Есть флаг -S, который поддерживают абсолютно все компиляторы. И нет, он точно не "отсохнет". :-)
Что касается бинарного кода — не забывайте, что исполняемый файл создаёт не компилятор, а линкер. И он ещё как может поменять бинарий! — вплоть до замены инструкций (например, длинные переходы / вызовы на короткие).
Если честно, я немного затрудняюсь с ответом… Что именно нужно пояснить?
Про особенности GPL можно почитать здесь.
Вот про TensorFlow (есть и видео — поищите на youtube)
Проще всего внутри цикла сделать что-то полезное (а иначе зачем он вообще нужен?)
Если нужен пустой бесконечный цикл — действительно есть смысл прочитать хабрапост tyomitch.
На эту тему написаны тонны сообщений, но в общем-то не думаю.
Если использовать clang, то программа напечатает «begin» дважды (!) и дальше упадёт в кору. Не спрашивайте. Хорошо хоть демоны не появились…