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

lexa - 10/Апр/2012 17:19

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

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

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

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

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

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

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

Comments

_slw (not verified) - 10/Апр/2012 17:29

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

lexa - 10/Апр/2012 17:31

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

_slw (not verified) - 10/Апр/2012 17:40

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

lexa - 10/Апр/2012 17:47

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

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

_slw (not verified) - 10/Апр/2012 17:54

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

lexa - 10/Апр/2012 18:03

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

atemik (not verified) - 11/Апр/2012 01:24

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

lexa - 11/Апр/2012 07:29

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

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

atemik (not verified) - 11/Апр/2012 10:12

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

lexa - 11/Апр/2012 10:58

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

J0hn - 12/Апр/2012 01:55

Intel TBB клевый.

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

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

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

lexa - 12/Апр/2012 07:30

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

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

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

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

lexa - 12/Апр/2012 10:05

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

J0hn - 12/Апр/2012 19:25

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

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

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

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

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

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

lexa - 12/Апр/2012 19:38

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

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

J0hn - 12/Апр/2012 21:09

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

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

lexa - 12/Апр/2012 21:52

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

J0hn - 14/Апр/2012 00:20

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

lexa - 14/Апр/2012 09:07

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

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

J0hn - 14/Апр/2012 14:51

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

lexa - 14/Апр/2012 15:13

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

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

J0hn - 14/Апр/2012 15:39

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

lexa - 14/Апр/2012 15:50

У vtune бывает floating license.

J0hn - 14/Апр/2012 15:55

ну супер

lexa - 14/Апр/2012 10:24

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

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

J0hn - 14/Апр/2012 15:10

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

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

lexa - 14/Апр/2012 15:12

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

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

J0hn - 14/Апр/2012 15:54

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

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

J0hn - 14/Апр/2012 16:02

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

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

lexa - 14/Апр/2012 16:17

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

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

J0hn - 14/Апр/2012 21:31

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

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

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

lexa - 14/Апр/2012 21:50

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

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

J0hn - 15/Апр/2012 04:18

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

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

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

lexa - 15/Апр/2012 09:29

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

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

lexa - 18/Апр/2012 08:35

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

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

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

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

lexa - 14/Апр/2012 10:29

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

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

J0hn - 14/Апр/2012 14:48

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