среда, 3 декабря 2014 г.

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

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


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

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

суббота, 29 ноября 2014 г.

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

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



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

Такая тема взята потому как я являюсь автором 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, а рассмотрю только маленький примерчик.

понедельник, 4 августа 2014 г.

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

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

воскресенье, 3 августа 2014 г.

llvm vs. gcc - 2014

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

пятница, 4 июля 2014 г.

Не все перемещения на регистр одинаково полезны

Словил забавную багу (а может и не багу) оптимизатора на казалось бы простеньком примере:

$ cat t.c
#include <stdio.h>

typedef double t;

t a = 0.5;
t b = 0.23;
t c = 6.0;

int main (void)
{
  t e, f;

  e = a - b;
  f = e * c;

  printf ("%.30f\n", f);
  return 0;
}

$ gcc t.c -O2 && ./a.out && gcc t.c && ./a.out
1.619999999999999884536805438984
1.620000000000000106581410364015


Такой эффект наблюдается с совершенно бородатых времён (ещё по-моему gcc-2.x такое выдавал). И наблюдается он только на 32-битном x86.

Сначала я думал, что это вина gcc, особенно с учётом того что llvm отрабатывает нормально. Но я эту багу нашёл в багзилле, суть вот в чём. Без оптимизации компилятор хранит double переменные на стеке, там они занимают положенные 64 бита и всё хорошо. А при включённой оптимизации он перемещает значение на плавающий регистр, который имеет размер 80 бит.

На вики есть объяснение почему именно 80 бит. Это связано с тем, что для удвоения точности экспоненту нужно увеличить на 1 бит и получить 12 бит, а мантиссу до 77 вместо старых 55 бит. Решение довольно спорное, т.к. оно не портируемое. Т.е. программе для того чтобы результат в разных режимах на разных машинах выдавал одинаковый результат нужно весьма извращаться. Иногда помогает ключ -ffloat-store, который запрещает хранить плавающие значения на регистрах.

пятница, 23 мая 2014 г.

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

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

четверг, 1 мая 2014 г.

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

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

пятница, 28 марта 2014 г.

Эльбрусы. Новые и не очень.

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