О новых технологиях

Было (это результат профайлера, разложенный по тредам):

Через два дня работы и ~800 строк кода стало (естественно, на тех же параметрах и входных данных):

Реально постобработка маленьких картинок ускорилась в 6 раз, больших - в 4. Почему маленькие быстрее - Х.З. Может быть кэши рулят. Это без учета распаковки, которая в профиль включена (и, увы, она для LJPEG не параллелится, если оный LJPEG не порезан на кусочки, как в DNG).

Имею сказать:

  • Intel TBB клевый.
  • Hyperthreading, как выясняется, тоже клевый. Если его запретить, в 6 раз на мелких картинках не получается, а дальше не стал присматриваться.
  • Обработка в 16-bit int чудовищно неэффективна. 16 бит легко переполняются, а значит взял значение, сконвертировал (в int или float), посчитал что-то, законвертировал обратно.

    Всю систему менять надо, конвертировать сходу в float, там и считать. Но это не сейчас.

Результаты этого упражнения вы увидите в следующей версии RawDigger, на кнопку Apply оно будет реагировать сильно быстрее. Чем больше горшков в процессоре, тем быстрее.

Comments

гипертрениг или smt?
а клевый когда у тебя есть float или всегда?

4 ядра, HT можно выключить/включить (я делал в BIOS, c affinity не развлекался). 8 потоков быстрее 4-х.
Делал это на целочисленной части, с плавучкой - не делал.

так какой ht?
старый или новый (который SMT)?

Я в них не разбираюсь.

Но наверное новый, процессор то новый (i7-2600)

а, это SMT. это как минимум улучшенные HT. может почти настоящие.
а сколько разов получается вместо 6, если их запретить?

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

Хм. Для десктопа рулит. Но вообще любопытно - вместо 11.8сек было съедено суммарно 18.8сек. Ничо так накладные расходы. Или я неправильно считаю?

Это чистое время (wall clock), а не CPU time. Т.е. если какое-то ядро ждет соседей в состоянии idle - на графике это тоже считается.
Но, конечно, накладные расходы есть:
- на синхронизации между потоками
- на reduce т.е. на объединении результатов расчетов в параллель (скажем, для гистограммы).

Что касается десктопа/сервера, то достаточно легко представить случай, когда рулит и на сервере тоже. Ну, например, обработка одного "запроса" в параллель влезает в кэш (L2 или L3), а 16 или 32 запроса (по числу ядер) - туда не влезают и вынуждены работать с памятью. Аналогично с диском (но тут просто выигрыш от сериализации)

А ради интереса - именно CPU time замерить возможно?

Оно посчитано: есть графики загрузки по core.
Но вот проинтегрировать по этим графикам я не умею. Так, на глазок, суммарная загрузка там где 8 threads работают - процентов 60. Но это для HT (SMT), что это на самом деле значит - для меня не вполне понятно.

Intel TBB клевый.

http://www.gpgpu.ru/node/933#comment-3087

фишка в том, что сложный код пишется один раз, и выносится в библиотеки, типа TBB.

Кстати, а как там с exception's из thread'ов?

Ну так на C++ писать - так и делать.

Чтобы сделать ~5 parallel_for и один parallel_reduce понадобилось 800 строк кода. Из коих половина - копипаста из рабочего serial-кода (с изменениями), а вторая половина - объекты-обертки. Ну может обертки чуть поменьше.

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

Что с исключениями - не знаю. Быстро нагуглил вот это, но с тех пор 4 года прошло, может и полечили как-то. По счастью, мне не надо.

Нагуглил больше: есть tbb::exception (и производные). Хватает, не пущает, делает rethrow.
Жить можно.

Чтобы сделать ~5 parallel_for и один parallel_reduce понадобилось 800 строк кода. Из коих половина - копипаста из рабочего serial-кода (с изменениями), а вторая половина - объекты-обертки. Ну может обертки чуть поменьше.

интересно посмотреть на эти обвёртки. не ради критики, а чтобы мозг поломать, как их можно сократить. У вас эти изменения уже под version control?

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

А что за проблемы? Я думал что всё должно норм работать - GCC'же.
У меня у самого есть проект который и на OS X работает, и OpenMP там есть, но я его не тестировал ещё(флаг в конфиге для openmp не включал)

Нагуглил больше: есть tbb::exception (и производные). Хватает, не пущает, делает rethrow.
Жить можно.

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

Там обертки простые как пробка: запомнить параметры (два конструктора), operator (), функция join() там где надо. Исходников этого дела в public нет и не планируется.

А с Маком и OpenMP - если программа использующая это сама мультитредная (например, на Qt), то оно просто может валиться с грохотом.
Возможно, это только под 10.5 так, я уже не помню (натыкался на это очень давно), но от этого не легче при раздаче бинарников (и нежелании печь отдельно под 10.5).

Исходников этого дела в public нет и не планируется.
ок. я подумал, что это libraw..

А с Маком и OpenMP - если программа использующая это сама мультитредная (например, на Qt), то оно просто может валиться с грохотом.
вот и у меня есть QT приложение. правда 10.5 не поддерживается, только начиная от 10.6.
В общем ясно, буду осторожно, спасибо за наводку.

Не, это не libraw впрямую, а производный класс (C++ в этом месте рулит). Публиковать пока планов нет.

А я вот думаю тоже TBB использовать, но вот какая проблема:
разработчиков много, иметь лицензию на TBB есть смысл только для нескольких человек (для сборки installer'ов, и для непосредственно использования TBB) - что делать с другими?
Использовать наследование (или аналоги) - не очень, придётся дублировать код (TBB/не TBB). (я так понял, у вас как раз так и есть)
Естественным кажется написание своих заглушек parallel_for и т.п. - но может есть более Intel-way решение?

Ну у них же коммерческие и опенсорсные версии вроде бы in sync.

Т.е. 300-баксовую версию использовать для сборки публичных релизов, а так жить на опенсорсе, нет?

если это не легально - то нет (см.ниже)

С чего бы это было нелегально?

Вопрос про легальность начинается в момент распространения ПО. Пока все тильки для себе - и вопроса нет.

о, ну тогда вообще супер.
(а вот VTune, как я понимаю на разработчика - ну по другому по-идеи быть не может, он то только одному разработчику и нужен)

У vtune бывает floating license.

ну супер

На самом деле, для map-reduce есть еще qtconcurrent и я его в ближайшие дни опробую.

Именно что из лицензионных соображений, платить по $300 за платформу раздавая бесплатный варез как-то обидно. А про TBB-шный Runtime Exception я не вполне понимаю.

мне параллелизм нужен в библиотеке, которая не линкуется к QT. На QT просто одна из оболочек для библиотеки. то есть, мне это не подойдёт..

А про TBB-шный Runtime Exception я не вполне понимаю.
а что это такое? это те которые throw? или там в лицензии какой-то exception?

Не, это лицензионное послабление относительно GPL2.
Дескать те .h-файлы, которые нужны для компиляции - используйте на здоровье.

Почему при этом лицензия не LGPL - для меня загадка.

http://stackoverflow.com/questions/362694/intels-threading-building-bloc...
http://stackoverflow.com/questions/3157720/intel-tbb-license

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

http://software.intel.com/en-us/forums/showthread.php?t=64297#

короче, эта лицензия не такая уж очевидная..

Неочевидная, однако если читать внимательно, то все написано: http://threadingbuildingblocks.org/wiki/index.php?title=Licensing

В самом хвосте: если не нужна поддержка и ваши адвокаты не возражают, то можете использовать опенсорс.

читал я это.
но за "ваши адвокаты не возражают", может скрываться что угодно, включая и :
"если ваши адвокаты не возражают против открытия всех ваших исходников"

то есть там буквально написано - rtfm.

а в этом rtfm'е, меня конкретно смущает слово free - "As a special exception, you may use this file as part of a free software library without restriction", которое может (??) относится к library по любую сторону баррикады. и главное, такие сомнения не только у меня.

Во многих местах ссылаются на "аналогично libstdc++" (от коей и взят runtime exception), а с ней все банально - все ее просто используют и не парятся.

При этом, в отличие от libstdc++, которая бывает только GPL2, с TBB есть банальный вариант "купить за $300". При том, что эти $300 - это зарплата за 1-3 дня, грубо говоря, можно и на всех купить.

аналогично libstdc++
ну да, читал.

можно и на всех купить

и ведь это не только покупка, это ещё и обновление потом..
а если библиотека популярная, можно попытаться нагуглить быстрый ответ - но мне быстрый ответ не попался. но тем не менее - лицензия только для распространяемой сборки, мне кажется оптимальным вариантом.

Я вот, начитавшись всего этого, теперь считаю, что лицензия просто необязательна.

Хотя, конечно, если вдруг чего, то на лойеров потратишь больше, чем на лицензии всем девелоперам (не говоря про одну).

мне параллелизм нужен в библиотеке, которая не линкуется к QT. На QT просто одна из оболочек для библиотеки. то есть, мне это не подойдёт..

Велика ли проблема слинковать с QtCore?

QtConcurrent::blockingMap (и подобные) не требуют наличия QApplication, я проверил. Ну то есть там на выходе ругань что 'threads still waiting', ну так можно рекомендовать QCoreApplication создать и удавить.

По результатам экспериментов - я не вижу разницы в эффективности между TBB и QTConcurrent, разве что для второй работы программиста на полкопейки больше, на таски надо руками все напилить.

Ну и еще момент - из переписки на интеловских форумах следует, что при использовании gcc (а не интеловских компиляторов) лицензия на библиотеку не проверяется никак.

Т.е. лицензионность ее важна только в смысле получить претензии по лицензии у финального продукта.

ну у нас в какой-то лицензии, то ли iso9001, то ли в приложении, то ли в другом сертификате, есть требование чтобы мы были джентльменами, и левое ПО не использовали.
Я так понимаю что использовать бесплатный TBB для коммерческих целей наверняка не разрешено.

Add new comment