Расскажу про один интересный проект, к которому имею некоторое отношение. Это антикафе GeekTime (не путать с сайтом, имеющим похожее название ;) ).
воскресенье, 29 марта 2015 г.
среда, 3 декабря 2014 г.
Наведённые эффекты от оптимизаций
При работе с оптимизациями могут возникать весьма забавные наведённые эффекты. Они не очевидным образом влияют на скорость исполнения программ. Возьмём, например, мой недавний strict-aliasing. Когда я его исследовал столкнулся со следующим явлением:
В таблице приведены опции компиляции теста и замеры при его исполнении. Видно, что применение strict-aliasing просаживает тест на 15%. Во-первых это очень много, а во-вторых совершенно непонятно почему. Ведь strict-aliasing это даже не оптимизация, а анализ, который разрывает зависимости между LOAD/STORE. Как можно замедлить программу разорвав несколько лишних зависимостей? Оказывается легко.
В Эльбрусах есть аппаратная поддержка технологии dam (memory access disambiguation). В двух словах она делает следующее. Если на этапе компиляции невозможно определить ни независимость, ни пересечение операций, а LOAD очень хочется закинуть за STORE, то это можно сделать, и ниже поставить проверку адресов, по которым работают эти операции. Если они не совпадают, то всё хорошо, если совпадают, то уходим на компенсирующий код и делаем всё по-старому.
Так вот, теперь как это связано со strict-aliasing. Внезапно на одном тесте strict-aliasing определил независимость операций, с которыми ранее работал dam. Из-за этого dam'у пришлось применяться к другим операциям, которые по факту оказались зависимыми. Из-за этого много времени ушло на компенсирующий код, и исполнение деградировало. Теперь смотрим без dam:
Видно, что тест более не деградирует, однако исполняется заметно медленнее.
А мораль отсюда такова: даже если в целом оптимизация ведёт себя хорошо - обязательно найдётся тест, который будет работать медленнее.
"-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Видно, что тест более не деградирует, однако исполняется заметно медленнее.
А мораль отсюда такова: даже если в целом оптимизация ведёт себя хорошо - обязательно найдётся тест, который будет работать медленнее.
суббота, 29 ноября 2014 г.
Слайды с доклада про strict-aliasing
Выступил на 57-ой научной конференции МФТИ с докладом про мой любимый strict-aliasing. Слайды можно посмотреть здесь:
Наверное стоит добавить пару комментариев по теме и вообще.
Такая тема взята потому как я являюсь автором strict-aliasing в компиляторе Эльбруса. Я когда-то уже переводил статью по данной теме, но в реальности ещё не видел ни одной нормальной публикации. Хочу сделать её сам, но пока не получается.
Сам strict-aliasing разрывает зависимости между load'ами и store'ами несовместимых типов. Что такое несовместимые типы долго объяснять, скажу только что совместимы только одни и те же типы с квалификаторами и типы, вложенные в агрегатные типы.
В компиляторах реализация strict-aliasing обычно делится на две (минимум) части - оптимизационный анализ и анализ нарушений. Последний в gcc реализован на редкость плохо, мне удалось сделать анализ дающий очень мало false-positive. Я пока не замерял как gcc'шный анализ влияет на производительность, но на компилятоое Эльбруса удалось добиться прироста до 8%. При том, что в реализации есть серьёзные загрубления.
Наверное стоит добавить пару комментариев по теме и вообще.
Такая тема взята потому как я являюсь автором strict-aliasing в компиляторе Эльбруса. Я когда-то уже переводил статью по данной теме, но в реальности ещё не видел ни одной нормальной публикации. Хочу сделать её сам, но пока не получается.
Сам strict-aliasing разрывает зависимости между load'ами и store'ами несовместимых типов. Что такое несовместимые типы долго объяснять, скажу только что совместимы только одни и те же типы с квалификаторами и типы, вложенные в агрегатные типы.
В компиляторах реализация strict-aliasing обычно делится на две (минимум) части - оптимизационный анализ и анализ нарушений. Последний в gcc реализован на редкость плохо, мне удалось сделать анализ дающий очень мало false-positive. Я пока не замерял как gcc'шный анализ влияет на производительность, но на компилятоое Эльбруса удалось добиться прироста до 8%. При том, что в реализации есть серьёзные загрубления.
пятница, 21 ноября 2014 г.
Эльбрус-8С
В МЦСТ постоянно идёт разработка новых процессоров, о которых предпочитается не заявлять публично. Но после получения хоть как-нибудь результатов разрешается что-нибудь рассказать. Относительно недавно появились инженерные образцы нового процессора Эльбрус-8С, о котором пойдёт речь.
пятница, 14 ноября 2014 г.
Новый блог о компиляторах: compileit.ru
Решил попробовать запустить один проект - блог о компиляторах и языках программирования http://compileit.ru. В данном блоге я публикую ссылки на различные статьи, публикации или просто интересные новости по данной тематике. Основной целью блога (помимо сбора интересующей меня информации, конечно) является организация вокруг него русскоязычного сообщества разработчиков компиляторов и людей, интересующихся языками программирования. Мне эта задача кажется важной в первую очередь потому что сейчас отсутствует нормальный обмен информацией между различными группами исследователей/разработчиков, и ни у кого нет общей картины направления движения индустрии. Более того может получаться ситуация, что исследование, проводимое в одной группе уже было проведено в другой, опубликовано где-то, где гугл не ищет, и получается, что часть работы была проделана зря. Я надеюсь, что если исследователи и разработчики будут обсуждать свои идеи в единой площадке, то это даст мощный толчок к развитию компиляторостроения и информатики в России.
понедельник, 20 октября 2014 г.
Сложности линковки
В очередной раз столкнулся с довольно забавным случаем из исходников. Что характерно это SPEC, и в нём обнаружилась ошибка (уже вторая с которой я столкнулся!). Причём для проявления ошибки должны были очень удачно сложиться звёзды.
/**
* Это вторая редакция поста с несколько расширенным разбором случая
*/
Я не буду показывать весь SPEC, а рассмотрю только маленький примерчик.
/**
* Это вторая редакция поста с несколько расширенным разбором случая
*/
Я не буду показывать весь SPEC, а рассмотрю только маленький примерчик.
понедельник, 4 августа 2014 г.
Реализация таблиц виртуальных функций в C++
Нашёл в архивах Сети хорошую статью про реализацию таблиц виртуальных функций в C++, поэтому решил перевести. Узнал несколько крайне интересных деталей. Например, что бывает до двух реализаций одного (!) конструктора и до трёх реализаций одного (!) деструктора. Ну и ещё про то что такое VTT (virtual table table), с чего я собственно на эту статью и вышел.
Подписаться на:
Комментарии (Atom)