Программирование

О семантике C++ (продолжение)

Наши читатели подсказывают нам, что в рассмотренном ранее примере может быть алиасинг.

Действительно, если у нас такое вот:

class someShit{
        char *m_sBuffer;
        size_t m_iLimit;
        size_t m_iCounter;
};
то никто не может гарантировать, что где-то не написали:
 m_sBuffer = (char*)&m_iCounter;
И тогда даже в одном треде можно огрести полные штаны счастья.

Меняю объявление на такое:

class someShit{
        char m_sBuffer[10240];
        size_t m_iLimit;
        size_t m_iCounter;
};
И для интеловского компилятора получаю счастье, в данном примере в память лишний раз никто не лазит:
void someShit::try1()
{
        m_iCounter = 0;
        while (m_iCounter< m_iLimit && m_sBuffer[m_iCounter])
                m_iCounter++;
}
MSVC 2010 это, правда, не помогло. Так и ходит через память.

Исходный вопрос (как отключить) снимается, restrict/__restrict в помощь, ключи компиляции опять-же есть.

ISPC 1.10

ISPCшные примеры, понятно что подобранные со вкусом, дают повод задуматься:

C:\> deferred_shading.exe pp1920x1200.bin

[ispc static + tasks]:		[151.426] million cycles to render 1920 x 1200 image
[C++ serial dynamic, 1 core]:	[2883.776] million cycles to render image
				(19.04x speedup from ISPC)

C:\>mandelbrot_tasks.exe 
[mandelbrot ispc+tasks]:	[190.607] million cycles
[mandelbrot serial]:		[2133.784] millon cycles
				(11.19x speedup from ISPC)
C:\> mandelbrot.exe
[mandelbrot ispc]:		[102.830] million cycles
[mandelbrot serial]:		[276.757] millon cycles
				(2.69x speedup from ISPC)

О взаимном знании двух рук - 2

С удовлетворением спешу сообщить, что мучившая меня с апреля проблема с VTune - излечена.

Поставил C++ Studio XE 2011 SP1 (Vtune там 2011 XE Update 5) - и Hotspot Analysis (который через драйвер) - заработал. И полугода не прошло. А то так и жил на Lightweight Hotspot. И хрен с ним с Hotspot, работают Lock/Wait и Concurrency, которые раньше были удобными, а за полгода я отвык.

Это та проблема, которая could not find ClientIntC function in the tool

Инженеры Интела из двух подразделений наконец повстречались в курилке!

О семантике C++

В продолжение кулуарного разговора с Highload++, навеянного 26-м слайдом презентации Андрея Аксенова.

Вот такой вот код:

class someShit{
        char *m_sBuffer;
        size_t m_iLimit, m_iCounter;
};
void someShit::try1()
{
        m_iCounter = 0;
        while (m_iCounter< m_iLimit && m_sBuffer[m_iCounter])
                m_iCounter++;
}

void someShit::try2()
{
        size_t l_iCounter = 0;
        while (l_iCounter< m_iLimit && m_sBuffer[l_iCounter])
                l_iCounter++;
        m_iCounter = l_iCounter;
}
Компиляторы (смотрел gcc 4.6, Visual Studio 2010 и Intel 11.0, все с включенной стандартной оптимизацией -O3/O2 без тонких настроек) делают разное:
  • gcc и Visual Studio генерируют код с той семантикой, какой написано;
  • Intel C++ делает так же, если компилирует "библиотеку", но оптимизирует первый случай до второго, если все потроха (методы класса и вызывающий их main()) лежат в одном файле.

Про AVX и ISPC

Разработчики Intel SPMD Program Compiler, который в этом блоге уже несколько раз поминался, выпустили версию 1.0.9 в которой

=== v1.0.9 === (26 September 2011)

The binary release of v1.0.9 is the first that supports AVX code generation. Two targets are provided: "avx", which runs with a programCount of 8, and "avx-x2" which runs 16 program instances simultaneously.

Честь им за это и хвала, мои попытки (не слишком настойчивые) самостоятельно собрать ISPC с LLVM3 так и не увенчались успехом, то какие-то ошибки в LLVM-овских H-файлах, то не линкуется, не больно то и хотелось.

Так как предыдущие тесты никуда не делись, я их переделал с новым ISPC, как с SSE4, так и с AVX.

Про AVX и OpenCL

Вчера вышел Intel OpenCL SDK 1.5 с соответствующим анонсом: Increase OpenCL application performance with the new Intel OpenCL SDK 1.5

Пытаюсь enlarge increase эту самую performance, сую в бензопилу лом туда AMD-шные примеры, которые на предыдущей версии работали очень бодренько (и временами почти догоняли AMD-шную видеокарту) и вижу замедление в 2-3 раза для половины примеров.

Начинаю читать код и не вижу там 256-битности. Ну, почти не вижу. Кое-где есть 256-битные load/store, нашел даже один vandps ymm1,ymm1,[memory], но в подавляющем большинстве код - 128-битный.

Он и в прошлой версии был 128-битный, но какой-то более человеческий.

Зато есть пошаговый отладчик, если бы не он, я бы версию 1.5 сразу бы снес, а так - еще подумаю.

Ну то есть понятно, производительность не переносится, но 2-3 раза просадки - это беспредел.

Единственный пример, который стал быстрее, называется Histogram. Но его и старая версия отказывалась векторизовать (немудрено) и новая тоже не хочет.

О языке ++C

Нашелся тут чудесный баг в KDE-шном DNG-конвертере. Вдруг, внезапно, перестал конвертировать, получаются совершенно ЧОРНЫЕ DNG.

Понятно, пишут в багрепорты digiKam-у, а дальше стрелки переводятся по кругу, ко мне (но LibRaw не менялась, в KDE все еще 0.13), к автору DNG Converter, все отпираются т.к. test cases работают.

И наконец виновник найден

Было:

  *output = ...some value...;
  *output++;
стало
  *output = ... some value...;
  ++(*output);
И комментарий к коммиту: use prefix operator

А я подозреваю, что исходно там было и вовсе:

  *output++ = ... some value...;
Проверять не стал, но предсказываю это.

Потом один доброжелатель разбил операцию на две, как умел, а второй, из ненависти к суффиксным инкрементам (или из желания подавить compiler warning), поменял на префиксный. Тоже, как умел.

Всех люблю: опенсорс, коллаборативную разработку по схеме "у семи нянек....", язык C/C++ тоже люблю.

О векторном умножении: нет гигапикселя в секунду

Тема матричного цветопреобразования не отпускает нас.

Наш читатель maratyszcza намекает нам, что haddps - тоже хорошая инструкция.

Его вариант вы найдете по вышеуказанной ссылке, а я потестировал вариант попроще, без unroll, без префетча, без одновременной обработки половинок данных. Исключительно для совместимости с прошлыми тестами:

О векторном умножении - финал

Исключительно в режиме записок для себя, вижу что интерес к теме у читателей потерялся, продолжаем тему скалярного произведения и матричного цветового преобразования.

Ассемблерные упражнения на тему векторных расширений.

Опять про movntps

Читал комментарии к прошлому посту про movntps, много думал. Вспоминал, что на i7-920 выигрыш от movntps был и значительный.

Пришлось потратить час-полтора на очередной набор микробенчмарок. Картинка получилась куда сложнее, чем я сначала подумал.

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

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

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

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

Одной строкой: mov[a|nt]ps

Не могу молчать:

Есть такие вот "ассемблерные" макросы:

  • _mm_store_ps(указатель, XMM-регистр) - писать в память.
  • _mm_stream_ps(те же параметры) - писать в память мимо кэша.

Для первого из них генерируется инструкция movaps (Intel C++ в некоторых условиях генерирует movntps, чему я удивлялся всегда). Для второго - всегда movntps ("писать мимо кэша"). В теории, при обработке больших потоков данных вторая быстрее.

Я неопытный сварщик SSE-ассемблером занялся не так давно, на рабочей станции был уже Core I7 и на Core2 я свои изделия (которые пока для internal use) - не запускал почти. А тут - запустил. Удивился тормозам. Помикробенчмаркал. На коротком цикле, вроде поминаемых тут скалярных умножений, получил разницу в четыре раза.

В том смысле, что movntps - в 4 раза медленнее. 40 мегапикселей вместо 160. Устойчиво, от компилятора не зависит, и на gcc так и на Clang.

В-принципе, от mm_stream выигрыша большого на i7 не было. Похоже, лучше про нее вообще забыть.

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

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

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

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

Отвечаем:

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

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

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

О legacy и форматах данных

Есть устоявшееся мнение, дескать обработка (изображений) в целых (16-битных) числах - это быстро, а делать то же самое в плавучке - медленно.

А я вот тут читаю ассемблер, порожденный компилятором из C-шного кода обработки изображения. Много думаю.

Имею сказать, что распространенный в настоящее время формат "16-битное целое на компонент" - это максимально неудачный способ с точки зрения эффективности обработки:

  • от малейшего чиха переполняется или превращается в тыкву обнуляется, нужно постоянно следить за диапазоном;
  • векторные (SSE,AVX) операции с этим типом - очень ограничены, да и не векторные - тоже.
В результате, сплошные мучения компилятору, а результат - медленно работает. Скажем, вот такой вот код (из dcraw), который делает преобразование по матричному профилю для 3-4 входных каналов (цветов) и трех выходных:
out[0] = out[1] = out[2] = 0;
for (сc=0;сc<colors;сc++) {
  out[0] += out_cam[0][сc] * img[сc];
  out[1] += out_cam[1][сc] * img[сc];
  out[2] += out_cam[2][сc] * img[сc];
}
for(cс=0;сc<3;сc++) img[сc] = CLIP((int) out[cс]);
img[] - unsigned short, out[] - int, out_cam[] - float.

Смотрю на код, который порождает интеловский компилятор. Ну код, да. (три-)четыре load по 2 байта (количество loads зависит от colors /количества цветов/), дальше "вручную" выписанный dot product (нормальный, насколько это возможно), ну и обрезание до диапазона 0-65к и store.

Скорость работы этого кода - 100 мегапикселей в секунду на Sandy Bridge 4.5Ghz (в один поток, понятно что параллелится это на ура). Как-то не очень....

Да, считаем в мегапикселях т.к. в unsigned short у нас 8 байт на (4-компонентный) пиксель, а для float/int - 16 байт.

I like to move it, move it

Мониторю всяческие новости про OpenCL, CUDA и прочие GPGPU и в последние дни просто засыпан новостью про то, что GEGL is getting GPU-based image rendering and processing.

Довеском к этой новости идет ссылка на OpenCL on GEGL: Results up to now, где сравнивается реализация brightness-contrast фильтра на CPU и на GPU (и не каком-то, а Tesla 2050 ценой 2 килобакса) и получается для 1-мегапиксельного изображения:

  • 526 msec на CPU
  • 483 msec на GPU
Просто гигантский выигрыш, почти 10% !!! Притом, как я понял (может быть и неправильно), во время исполнения на GPU не посчитана пересылка "обратно", с карты в RAM.

При этом, заметим, на CPU оно работает на одном ядре (хоть и на SSE2), а значит на 4 ядрах оно банально будет быстрее разика в три.

Причина тривиальна и прямо в том блог-посте описана, весь пар ушел в свисток, а все время исполнения - на пересылку данных. Собственно исполнение обработки на GPU занимает около 1/10 всего времени.

При этом, само время исполнения - чудовищно. Полсекунды на 1 мегапиксель, даже если пиксели 16-байтные (4 float) - это 32 мегабайта в секунду. Э.... По PCIe обычно ходит 4-5 гигабайт/сек..... Проблема, судя по всему, кроется в тайлововой организации картинки в GEGL, тайл при этом мелкий (128x64) и даже на CPU обрабатывать их эффективно не получается, что уж говорить про GPU, где под каждый тайл аллоцируется текстура.

На эту тему имею рассказать следующую историю:

Visual Studio .sln/.vcproj generator?

По многочисленным просьбам трудящихся, я поставляю вместе с LibRaw еще и .sln/.vcproj файлы для MS Visual Studio.

Генерирую я их с помощью Qmake и все более-менее работает, но:

  • Иногда (когда Юпитер в Рыбах?) в sln-файле вместо относительных путей оказываются полные, приходится ручками чистить.
  • Проекты содержат AdditionalIncludeDirectories указывающие (абсолютным путем) на mkspecs от моего Qmake.
  • Можно сгенерировать проект для 32-бит, вроде бы можно (хотя не пробовал) для 64 бит, а вот под две платформы сразу - не умеет.
  • Была еще проблема с зависимостями (exe - dll), ибо зависимости ловятся искуственным интеллектом, но вроде я научился добиваться от него счастья.
  • Достали win32:/unix: конструкции в .pro-файлах, блин.
Короче, неаккуратненько, неровно висят.

Попробовал CMake и счастья еще меньше, проекты ALL_BUILD и ZERO_CHECK раздражают мое эстетическое чувство. При этом проблема абсолютных путей не решена, а дальше я копать не стал и CMake снес.

Что я упустил? Какой еще есть варез, который нагенерирует мне sln/vcproj из простых текстовых файлов?

LibRaw 0.14 Alpha

По сложившейся традиции, анонсирую тут новую major версию LibRaw, которая пока существует в альфа-варианте.

Скачать ее можно в обычном месте, почитать формальный Changelog там же, а тут хочется рассказать об изменениях человеческим языком.

До сего момента жизнь в LibRaw была устроена просто: открыл файл (LibRaw::open()), распаковал (LibRaw::unpack()), если своего постпроцессинга нет, то попользовался нашим (LibRaw::dcraw_process()). Если какие-то параметры поменялись, то все сначала, open, unpack и так далее.

Плюс этого подхода в том, что все варится в одном буфере, и распаковывается сразу куда надо и демозаика сразу in-place и все остальное - тоже.

Минус - тоже понятно какой: поменял ББ, даже в интерактивной программе и .... опять надо распаковывать RAW, а скажем в кэноновских CR2 тамошний Хаффман (lossless JPEG) устроен так, что хрен распараллелишь его распаковку. И секунда-две только на 30-мегабайтный CR2 - просто в природе вещей.

Что делаем? Правильно, меняем память на скорость.

Начиная с 0.14 байеровские данные распаковываются в один буфер, а весь постпроцессинг идет в другом. Для байеровских камер это penalty по памяти в 25% (40Mb для 20-мегапиксельной камеры), зато счастье велико есть. Для не-байеровских камер потери больше (вдвое), но там и кадры, как правило, небольшие (sRaw - 3-10 мегапикселов, фовеоны - 4Mpix), а владельцы Sigma SD1 или multi-shot задников могут и пару гигабайт памяти докупить.

О консистентности

Чтобы на времени компиляции убедиться в том, что у нас MS Visual C++ 2008 SP1+, нужно забабахать вот такое вот:
#if defined(_MSC_VER) && _MSC_VER == 1500 && _MSC_FULL_VER >= 150030729

Ну ладно, ну вот лично я бы две старших цифры в _MSC_VER занял бы под major версию, а две младших - под minor (сервис-паки, то-се), ну ладно, пусть будет два макроса.

Опять-таки, ладно, что MS Visual C++ 2008 это на самом деле Visual C++ 9.0, а _MSC_VER у него 1500. Ну логично же, да?

Но покажите мне пожалуйста табличку в официальной документации (на MSDN, например), где были бы перечислены версии компиляторов и против каждой версии было бы написано значение _MSC_VER и прочих макросов, важных для определения версии компилятора. blogs.msdn и social.msdn не принимаются, я хочу именно что документацию

А если эта табличка там есть (я не нашел), то какой осмысленный запрос надо вфигачить в поиск по MSDN, чтобы искомый документ оказался в первой тройке.

P.S. Нет, я не привередничаю. OpenMP в нужном мне виде правильно работает в VC++ 2010 и в 2008SP1, я и хочу чтобы оно собиралось бы с OpenMP на вышеуказанных версиях, а на более старых - и не думало бы. Аналогичный случай имеется с C++ TR1, который, вроде бы, человеческим тоже стал в 2008SP1.

P.P.S. В blogs.msdn.com, в каментах, сотрудник MS пишет что надо делать вот так:

#if defined(_MSC_VER) && (_MSC_FULL_VER > 150021022 || _MSC_FULL_VER == 150021022 && _MSC_BUILD >= 8)
       cout << "This is VC9 RTM or above." << endl;
#endif

#if defined(_MSC_VER) && (_MSC_FULL_VER > 150030729 || _MSC_FULL_VER == 150030729 && _MSC_BUILD >= 1)
cout << "This is VC9 SP1 or above." << endl;
#endif
У меня нет слов. Еще и _MSC_BUILD (которого нету в VC8/2005 и более старых).

Об автоматической векторизации

Провел на поминавшемся вчера ISPC еще один тест, на применимость ровно в том месте, куда он лучше всего приспособлен.

Есть такое ужасное место в обработке изображений (уже поминавшееся в этом блоге): преобразование из линейной гаммы в sRGB-гамму или в Lab. Там в формуле сначала линейный участок, а потом степенной. Вот как это выглядит, если делать в лоб для плавающей точки:

void linear2srgb(float *in, float *out)
{
   for(int i = 0; i< DATA_SIZE; i++)
        out[i] = ((in[i]<=0.0031308f)? 12.92f*in[i] : (1+0.055f)*powf(in[i],1/2.4f)-0.055f);
}

Ну, понятно, для (целочисленных) 8-16-битных данных составляют лукап-таблицу, а дальше фигачат по ней, а вот для большей битности таблица получается изрядно большой. Вычислять эту штуку в лоб мешают две вещи:

  • ветвление на каждое входное данное;
  • возведение в степень, которое тоже очень медленное: на SSE/AVX такой функции нет, на FP87 есть, но безобразно медленная.
К примеру, при обработке плавающих данных LCMS (преобразование в Lab, преобразование по матричному профилю в sRGB) процентов 90 времени уходит именно на вышепоказанную операцию (правда в LCMS это место еще сделано потрясающе неудачно с точки зрения производительности).

Как я уже писал, правильное решение заключается в замене вышепоказанной функции чем-то приличным, скажем для кубических сплайнов с таблицей в 4к строк максимальная ошибка по всему диапазону не превышает 10-6, что для всех применений достаточно, при скорости порядка 1.2-1.5Gb/sec на одно процессорное ядро. Но одна строчка кода превращается в несколько десятков, таблицу коэффициентов сплайнов надо еще построить, что мучительно.

Посмотрим, что можно сделать с помощью ISPC и можно ли вообще что-то.

Pages

Subscribe to Программирование