gcc

Об одном известном макроассемблере

lexa - 20/Май/2013 17:20
Вот есть такая dcraw.c, а в ней есть такие вот две строчки кода:
  unsigned int *data,pad[128],p;
  ...
  while (len--)
      *data++ ^= pad[p++ & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
И все было ничего в gcc 2.x...4.7, а вот 4.8 компилирует это место неправильно.

Я даже посмотрел генерируемые ассемблеры, увидел что разные, но за 30 секунд не разобрался (потому что константы 1 и 65 у 4.8 становятся 2 и 66 и надо внимательно смотреть в каком порядке там что инкрементится).

Переписал так:

  while (len--)
    {
      *data++ ^= pad[p & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
      p++;    
    }
Помогло. Но осадок - остался.

Вопросов у меня, собственно, два три:

  1. Куды жаловаться на gcc Действительно UB? Но ведь есть такое естественное знание, что сначала вычисление правой части, а потом уже присваивание к левой. Это ж поимеет в куче мест.
  2. Правильно ли я понимаю, что пересечение множеств "Linux с пакетами собранными 4.8" и "Фотограф в RAW" крайне мало отличается от пустого множества?
  3. А не отличается ли это место в C и в C++?
P.S. Помимо баланса белого, который поминается в в багрепорте, отваливается еще и декодирование файлов с Sony DSC-V3, Sony F828 и, возможно, еще каких-то (у меня таблички декодер - камера нету)

P.P.S. Если отвалится какая-нибудь криптуха или там MPEG-декодер - я совершенно не удивлюсь.

О векторных расширениях gcc/clang (2)

lexa - 06/Сен/2011 19:30

В комментариях к одному из предыдущих постов про оптимизацию матричного преобразования цвета нам предлагают немножко подумать над алгоритмом.

К сожалению, предложенное там решение (офигенно быстрое!) считает неправильно, но направление движение указано верно и мы приходим к такому варианту:

  1. транспонируем матрицу, на которую умножаем, дополним нулями правую колонку, чтобы вышло 4x4
  2. Каждое из (четырех) входных значений - размножим на вектор.
  3. Нужный нам результат - это SIMD-сумма SIMD-произведений вышеупомянутых векторов на строки вышеупомянутой транспонированной матрицы.
Короче, проще кодом:

О компиляторах и процессорах: AVX

lexa - 04/Сен/2011 19:22

Армянское радио Нас спрашивают:

Как измениться производительность intrinsic варианта на Core-i7, если поменять
_mm_dp_ps на _mm256_dp_ps
_mm_blend_ps на _mm_blend256_ps

То-есть насколько вырастить производительность если мы совсем на AVX переедем и будет обрабатывать по 8 float за проход? А то слухи разные ходят... от 0% до 200% роста.

Отвечаем:

О компиляторах и процессорах

lexa - 01/Сен/2011 15:48

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

Я обратил и сравнил, но в процессе получилась масса побочных результатов (разные архитектуры, разные компиляторы), которые жалко выкинуть, а хочется опубликовать.

Subscribe to gcc