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

При работе с оптимизациями могут возникать весьма забавные наведённые эффекты. Они не очевидным образом влияют на скорость исполнения программ. Возьмём, например, мой недавний 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%. При том, что в реализации есть серьёзные загрубления.

Эльбрус-8С

В МЦСТ постоянно идёт разработка новых процессоров, о которых предпочитается не заявлять публично. Но после получения хоть как-нибудь результатов разрешается что-нибудь рассказать. Относительно недавно появились инженерные образцы нового процессора Эльбрус-8С, о котором пойдёт речь.

Новый блог о компиляторах: compileit.ru

Решил попробовать запустить один проект - блог о компиляторах и языках программирования http://compileit.ru. В данном блоге я публикую ссылки на различные статьи, публикации или просто интересные новости по данной тематике. Основной целью блога (помимо сбора интересующей меня информации, конечно) является организация вокруг него русскоязычного сообщества разработчиков компиляторов и людей, интересующихся языками программирования. Мне эта задача кажется важной в первую очередь потому что сейчас отсутствует нормальный обмен информацией между различными группами исследователей/разработчиков, и ни у кого нет общей картины направления движения индустрии. Более того может получаться ситуация, что исследование, проводимое в одной группе уже было проведено в другой, опубликовано где-то, где гугл не ищет, и получается, что часть работы была проделана зря. Я надеюсь, что если исследователи и разработчики будут обсуждать свои идеи в единой площадке, то это даст мощный толчок к развитию компиляторостроения и информатики в России.

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

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

Реализация таблиц виртуальных функций в C++

Нашёл в архивах Сети хорошую статью про реализацию таблиц виртуальных функций в C++, поэтому решил перевести. Узнал несколько крайне интересных деталей. Например, что бывает до двух реализаций одного (!) конструктора и до трёх реализаций одного (!) деструктора. Ну и ещё про то что такое VTT (virtual table table), с чего я собственно на эту статью и вышел.

llvm vs. gcc - 2014

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