Межъязыковые тесты производительности

Недавно попался на глаза сайт, идеей которого является сравнение производительности разных языков. Посмотрел на этот сайт и решил подумать над тем какие вообще есть подобные проекты, какие у них проблемы и как вообще следовало бы делать измерения производительности.

Answer to "Is software prefetching (__builtin_prefetch) useful for performance?"

Recently I've read a short note where an author tells that software prefetch is useless for performance. I think that it would be interesting to listen to another point of view.

Выступил в SDCast

Недавно поучаствовал в двух выпусках подкаста SDCast. Если кто не в курсе, подкаст - это что-то вроде радиопередачи, только по интернету :)

Как бы я изменил язык Си в 2017 году

В этом посте мне хотелось бы порассуждать на тему того что я бы поменял/убрал/добавил в язык Си. Си является моим основным языком, более того уже больше 4 лет я занимаюсь разработкой оптимизирующего компилятора Си, который пишется на Си. За это время у меня накопились некоторые мысли на тему того что должен и чего не должен современный язык, какие проблемы есть в Си, как их можно было бы решить.

Список учебных курсов по оптимизирующим компиляторам

Как вы помните, я читаю курс по оптимизирующим компиляторам. В процессе подготовки к лекциям приходится искать много материала по теме, часто бывает что какой-то информации нету в книгах, и гугл выбрасывает меня на лекции с других ВУЗов или публикации. В этом посте поделюсь ссылками на другие курсы лекций, относящиеся к компиляторам, из которых я брал информацию.

Профиль программы и его предсказание

Сегодня хотел бы рассказать про то как в компиляторе представлена профильная информация и как она предсказывается. Студентам и просто людям часто выносит мозг тот факт что компилятор статически (т.е. без реального исполнения) может предсказывать такие вещи как количество итераций у цикла или просто вероятности переходов, поэтому расскажу об этом по подробнее.

Опасность вызова функций без объявленного прототипа в C

Ещё один пост про тонкости линковки. Предыдущий лежит здесь. На этот раз речь пойдёт преимущественно о старых исходниках, переносе их в 64-х битный режим, ну и немного про режим сборки "вся программа". Пример основан на реальных событиях исходниках.

Лекции по оптимизирующим компиляторам

В последние несколько месяцев занимался довольно новым для себя делом - читал лекции по курсу "Оптимизирующие компиляторы". Раньше мне не приходилось читать лекции (ну или почти не приходилось), да и предмет не самый распространённый. В общем о том что получилось, что хочется дополнить и исправить расскажу ниже.

Наведённые эффекты от оптимизаций

При работе с оптимизациями могут возникать весьма забавные наведённые эффекты. Они не очевидным образом влияют на скорость исполнения программ. Возьмём, например, мой недавний strict-aliasing. Когда я его исследовал столкнулся со следующим явлением:

"-O3"                               :442.34:real:438.46:user:0.51:sys
"-O3 -fno-strict-aliasing"          :376.43:real:374.28:user:0.39:sys

В таблице приведены опции компиляции теста и замеры при его исполнении. Видно, что применение strict-aliasing просаживает тест на 15%. Во-первых это очень много, а во-вторых совершенно непонятно почему. Ведь strict-aliasing это даже не оптимизация, а анализ, который разрывает зависимости между LOAD/STORE. Как можно замедлить программу разорвав несколько лишних зависимостей? Оказывается легко.

В Эльбрусах есть аппаратная поддержка технологии dam (memory access disambiguation). В двух словах она делает следующее. Если на этапе компиляции невозможно определить ни независимость, ни пересечение операций, а LOAD очень хочется закинуть за STORE, то это можно сделать, и ниже поставить проверку адресов, по которым работают эти операции. Если они не совпадают, то всё хорошо, если совпадают, то уходим на компенсирующий код и делаем всё по-старому.

Так вот, теперь как это связано со strict-aliasing. Внезапно на одном тесте strict-aliasing определил независимость операций, с которыми ранее работал dam. Из-за этого dam'у пришлось применяться к другим операциям, которые по факту оказались зависимыми. Из-за этого много времени ушло на компенсирующий код, и исполнение деградировало. Теперь смотрим без dam:

"-O3 -fno-dam"                      :471.28:real:468.70:user:0.39:sys
"-O3 -fno-dam -fno-strict-aliasing" :473.76:real:470.96:user:0.36:sys

Видно, что тест более не деградирует, однако исполняется заметно медленнее.

А мораль отсюда такова: даже если в целом оптимизация ведёт себя хорошо - обязательно найдётся тест, который будет работать медленнее.

Слайды с доклада про strict-aliasing

Выступил на 57-ой научной конференции МФТИ с докладом про мой любимый strict-aliasing. Слайды можно посмотреть здесь:

Правила перекрытия объектов в памяти from Alex Markin

Наверное стоит добавить пару комментариев по теме и вообще.

Такая тема взята потому как я являюсь автором strict-aliasing в компиляторе Эльбруса. Я когда-то уже переводил статью по данной теме, но в реальности ещё не видел ни одной нормальной публикации. Хочу сделать её сам, но пока не получается.

Сам strict-aliasing разрывает зависимости между load'ами и store'ами несовместимых типов. Что такое несовместимые типы долго объяснять, скажу только что совместимы только одни и те же типы с квалификаторами и типы, вложенные в агрегатные типы.

В компиляторах реализация strict-aliasing обычно делится на две (минимум) части - оптимизационный анализ и анализ нарушений. Последний в gcc реализован на редкость плохо, мне удалось сделать анализ дающий очень мало false-positive. Я пока не замерял как gcc'шный анализ влияет на производительность, но на компилятоое Эльбруса удалось добиться прироста до 8%. При том, что в реализации есть серьёзные загрубления.

Сложности линковки

В очередной раз столкнулся с довольно забавным случаем из исходников. Что характерно это SPEC, и в нём обнаружилась ошибка (уже вторая с которой я столкнулся!). Причём для проявления ошибки должны были очень удачно сложиться звёзды.
/**
 * Это вторая редакция поста с несколько расширенным разбором случая
*/
Я не буду показывать весь SPEC, а рассмотрю только маленький примерчик.

llvm vs. gcc - 2014

Я уже писал про сравнение gcc и llvm в 2013 году, и вот недавно вышло сравнение свежих версий. Сравнение претерпело некоторые изменения, и разумеется, хотелось бы об этом написать.

Векторизация в компиляторе Эльбруса

Наткнулся на старый пост про автовекторизацию. Если в кратце, то автор жаловался на то, что компиляторы не могут ничего сделать даже на простейших примерах. Я просто не мог не проверить как те простейшие примеры отработают на Эльбрусе :)

Про оптимизации, безопасность и "нормальные языки".

В конце 2013 года вышла довольно интересная статья "Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior" про то как компиляторы, применяя различные агрессивные оптимизации убирают проверки безопасности. Хочу поделиться своими мыслями на этот счёт.

Ошибка в комментарии

На старых фронтэндах был простой способ получить ошибку в плохо написанном комментарии. Связано это с триграфами. Сам столкнулся с такой на старой версии edg - фронтэнда, который используется в компиляторе intel.

$ cat test.c

/**
 * ??!
 */

int main(){}


$ lcc_i test.c
lcc: "test.c", line 2: error: support for trigraphs is disabled
          [-Werror=trigraphs]
   * ??!
     ^

1 error detected in the compilation of "test.c".


Подробней о проблемах с триграфами можно почитать на вики. Тут интересен вопрос "а почему вообще возникает такая проблема?". Фишка кроется в стандарте, раздел 5.1.1.2 Translation phases. Грубо говоря препроцессирование делится на 6 стадий. При этом триграфы разворачиваются на первой стадии, а комментарии удаляются только на 3-ей.

На современных компиляторах такой проблемы замечено не было.

LLVM vs. GCC

Кто круче Шварценеггер или Сталлоне GCC или LLVM? Этот вопрос уже давно мучает многих людей на форумах. На эту тему можно много рассуждать, рассматривая с разных сторон. Но существуют относительно объективные критерии оценки.

Будни компиляторщика

Сравнение двух CFG функции "до" и "после"

CFG до применения фазы оптимизации

CFG после применения фазы оптимизации

Обычно такие бяки генерируются flex'ом