Skip to Content

Июнь 2011

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

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

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

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

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

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

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

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

Об Intel ISPC

Интел выкатил в опенсорс такую вот игрушку: Intel SPMD Program Compiler.

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

  1. void vector_sum(uniform float in[], uniform int count, reference uniform float out[]) {
  2.     float sum = 0.0;
  3.     for (uniform int i = 0; i < count; i += programCount) {
  4.         int index = i + programIndex;
  5.         sum+= in[index];
  6.     }
  7.     out[programIndex] = sum;
  8. }
И оно у вас пойдет фигачить шириной programCount, ну там дальше надо будет элементы out просуммировать уже снаружи.

Об Intel OpenCL

Щупаю тут за вымя Intel OpenCL (для CPU) и эта игрушка мне все больше нравится.

Помимо оффлайн-компилятора (который выдает ассемблер или LLVM-код) эту хреновину можно профайлить при помощи VTune (нужно пару переменных окружения поставить, см. доку).

Беру я, значит, прямо тамошний пример MedianFilter и начинаю профайлить. Он содержит "CPU"-реализацию (в том смысле, что компилятор C++ ее превратит в обычный код) и OpenCL-вариант (который будет скомпилирован на лету). Обе реализации имеют настолько одинаковый C/C++ код внутри, насколько это вообще возможно (OpenCL-ядро - это обработка одной строки изображения, а CPU-код имеет еще цикл по всем строкам). Код, собственно, простой как пробка: берем пикселы из окрестности +-1, слегка сортируем (unrolled), вот и медиана.

И вот что я вижу:

  • CPU-вариант при компиляции Visual C++ 2008: 389 msec на исполнение. Это без processor-specific оптимизаций и без распараллеливания.
  • OpenCL-вариант: 15 msec.
В 26 раз быстрее, однако.

Ну ладно, VC++2008 - не самый новый, да и процессора моего не знает. Переключаю компилятор на Intel C++ 12-й версии (который Composer XE), включаю оптимизацию для AVX, уже лучше: 151 msec. Но тоже в 10 раз.

Об SSD

Чумовой мужик

Watch live streaming video from oreillyconfs at livestream.com

Сперто отсюда: It's the Fraking IOPS - 1 SSD is 44,000 IOPS, Hard Drive is 180

Про винду

А вот, к примеру, есть Windows7, где хитрым хаком пользовательские каталоги и ProgramData унесены на другой диск. Хак работает, я проверил.

А теперь я хочу переставить винду, оставив Users от старой.

Возможно ли сие?

О походных гаджетах

Кратко, для интересующихся.

GPSMAP 62 вообще и растровые карты в частности
Растровые карты оказались счастьем, бумажные, хоть и были напечатаны, вообще ни разу не использовались, мелкого экранчика с зумом - достаточно.

По питанию: NiMh 2700 (по факту 2500) кормят прибор 2.5 ходовых дня в реальном режиме (с картой, альтиметром, трип-компьютером, подсветкой, но практически без компаса). "Дни" абстрактные, когда 5-6 ходовых часов, а когда и все 13. Правда индикация разряда NiMh хреновая, от момента "не все палки" до полного выключения проходит очень мало, запасные батареи надо всегда под рукой иметь.

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

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

Thuraya
Слышно откровенно хреново, даже если сигнал сильный. Более того, сигнал плавает: вроде бы открытый на юг берег большого озера, никаких проблем быть не должно, однако на три метра в сторону отошел и вообще куку.

SMS-ки ходят на ура, 100 штук за 350, обмана нет. Сто SMS - это дохрена, вшестером вытратить удалось половину где-то со всеми постами в твиттер и всем таким.

Полста SMS и несколько коротких разговоров (в сумме за все время минут на 15) разрядили девайс на одну "палку" из четырех, но насколько у него этот индикатор линеен - неясно.

Как средство экстренной связи имеет понятные ограничения, на северном склоне хоть чего - не работает. В лесотундре (но на южном склоне) - работает. Сильно лучше, чем ничего.

Солнечная зарядка
Странная оказалась штука. Вроде и работает, турайю удалось за пару часов зарядить обратно на 100%, но штука скорее геморойная, солнца ей надо, дымки - не надо. Пока, по ощущениям, с базовым лагерем - скорее да, а с постоянным движением - скорее нет, лучше лития набрать по доллару за батарейку.
Такие дела.

О диссипации энергии

Заряженных аккумуляторов в поездку было взято с запасом, поэтому представился случай померять саморазряд:

  • Свежезаряженные мои Varta Professional 2700 имеют емкость 2450-2500 mA*h при разрядке током 500 миллиампер (разряжаю Maha-9000, емкость - по показаниям этого прибора). Причем, как недавно купленные, так и двухлетней давности имеют примерно одну емкость.
  • После двухнедельной выдержки (реально 15-16 дней т.к. заряжал не в день отъезда): 2250+-40 mA*h (разрядка в том же режиме) т.е. за две недели теряется около 10%
  • Для сравнения, единственный имеющийся у меня Eneloop имеет емкость 1900-1950 cразу после зарядки, а на саморазряд я его не тестировал.

Мораль: для 2-недельных выездов "обычные" Eneloop смысла не имеют, а те которые на 2500 я еще не пробовал, там смысл может быть.

Естественно, это все для летней температуры и невысокого потребления (GPS, рация на приеме), ибо для низких температур и высоких токов у Eneloop вроде как есть отдельные достоинства.

Поездка контрастов

Сначала была идея: стать первыми парусными туристами в Монголии (звучит, да?).

Ну и вообще, совершить горно-парусный поход: обойти за неделю-полторы Хубсугул, а потом зайти на Мунка-Сардык с монгольской стороны (без катамарана).

Жизнь оказалась богаче, Хубсугул встретил нас льдами:

Правда открытую воду мы тоже нашли и первыми парусными туристами в Монголии - стали.



.