Открытие Thread Building Blocks 2.0

я немного не понял, оно на отличных от Intel процессорах будет нормально работать?

что за нах? никаких исходников по сцылке скачать не дают, только бинарники и файлик "copying" содержащий в себе GPL v2. ОНИ ИЗДЕВАЮТСЯ?

Зачем оно нужно?

Чем оно луше OpenMP?

Еще один лисапед?

Пару ссылок по теме:

http://softwareblogs.intel.com/2006/12/18/threading-building-blocks-solution-...

http://softwareblogs.intel.com/2007/07/23/threadingbuildingblocksorg-essentia...

Исходники в разделе Dev Realeses Но, OpenMP всё равно лучьше

понты, а может сидят и на счётчики дивятся

Hardware - Minimum Requirements Microsoft* Windows* Systems Intel(R) Pentium(R) 4 processor Linux* Systems Intel(R) Pentium(R) 4 processor or Intel(R) Itanium(R) 2 processor Mac OS* Systems Intel(R) Core(TM) Solo processor 512 MB of RAM 300 MB of disk space

От таким огном пичкают линуск! :)

тестовые файлы с расширением exe это жесть ;)

Ща соберём и посмотрим кто есть ху

Warning: not running on genuine Intel hardware

Умная сцуко ...

Тесты красивые. Надо будет на 4-х ядернике попробовать.

Господа OpenMP это спецификация а не библиотека, что вы сравниваете соленое с красным?

имхо этим должна ось заниматься а не какая-то библиотека за редкими исключениями

>Господа OpenMP это спецификация а не библиотека, что вы сравниваете соленое с красным?

Сударь, реализацию можете сами выбрать любимого цвета ;)

>имхо этим должна ось заниматься а не какая-то библиотека за редкими исключениями

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

Ссылке на примеры сделаны через флеш? OMG....

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

Жалко что не LGPL :(

Хотя нет. Зря жалею. Оказывается GPL + runtime exception, так что всё ок.

>Оказывается GPL + runtime exception,

А эт чего такое? о_О GPL2 вроде бы не допускает добавления лишних ограничений. Может к послаблениям это не относится? :D

Народ, не искажайте творение великого Intel'а, правильное название - ThreadING Building Blocks. Модераторы, исправите?

Что касается OpenMP, то у него есть некоторые недостатки, например то, что программа распараллеливается по кусочкам (в основном параллелятся циклы) а между этими кусочками - последовательные участки.

С другой стороны, гораздо важнее, насколько хорошо программа будет распараллелена программистом, а не с использование какой технологии. А по легкости использования OMP очень хорош.

Тем не менее, чтобы уверенно судить, надо с помощью TBB написать пару тысяч строк, есть такие среди лоровцев? Сама Интел позиционирует OpenMP для распараллеливания существующих програм, в то время как TBB лучше всего подходит, по их мнению, для создания новых.

>А эт чего такое? о_О GPL2 вроде бы не допускает добавления лишних ограничений. Может к послаблениям это не относится? :D

Так лицензируется, например, stdc++. Это как раз послабление для использования GPL (аля LGPL).

<quote> As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. </quote>

Это как раз послабление для использования GPL (аля LGPL).

Дык это уже и будет LGPL, или нет?

И, кстати, что значит "русское" "аля"? =/

Анлг. As Long As..

>>И, кстати, что значит "русское" "аля"? =/

http://fr.wiktionary.org/wiki/à_la

>Что касается OpenMP, то у него есть некоторые недостатки, например то, что программа распараллеливается по кусочкам (в основном параллелятся циклы) а между этими кусочками - последовательные участки.

Это (последовательные участки) не свойство OpenMP а свойство распараллеливаемой программы. Внутри parallel секции исполняется сразу несколько потоков которым прагмами (for, single, critical, sections, etc.) даются указания обрабатывать те или иные куски кода специальным образом.

>А по легкости использования OMP очень хорош.

Ага. Если не стоит задача действительно получить хороший перфоманс

>Сама Интел позиционирует OpenMP для распараллеливания существующих програм,

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

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

И даже после переписывания такого кода OpenMP будет почти всегда проигрывать например современным реализациям MPI (MPI2) в перфомансе. Это расплата за удобство за счёт меньшей гибкостью данного инструмента.

TBB это еще один инструмент, насколько он гибкий/мощный/удобный/эффективный нужно смотреть. Некоторый его плюс в том что он слегка отвязан от реализации компилятора к которой например привязан тот же самый OpenMP

>Дык это уже и будет LGPL, или нет?

Почти:

A: The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there's no way to make that work with C++, where much of the library consists of inline functions and templates, which are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL.

>И, кстати, что значит "русское" "аля"? =/

Если это стёб, то это слово ничем не хуже чем "русское" ОК, а если нужно значение слова - http://en.wiktionary.org/wiki/%C3%A0_la (происх. франц. - см. выше ссылку еще давали).

>Чем оно луше OpenMP?

оно к нему перпендикулярно. например было бы интересно посмотреть как вы реализуете с помощью OpenMP классическую задачу типа producers/consumers.

Всем спасибо за конструктивные ответы. Иногда лор просто приятно удивляет! :D

>Это (последовательные участки) не свойство OpenMP а свойство распараллеливаемой программы.

Да, действительно, это всего лишь свойство 90% програм c OMP. Можно писать полностью параллельные программы, только в этом случае обычно лучше использовать какую-нибудь другую технологию.

>Просто расстановка прагм с очень большой долей вероятности даст не выигрыш а даже деградацию производительности.

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

>И даже после переписывания такого кода OpenMP будет почти всегда проигрывать например современным реализациям MPI (MPI2) в перфомансе. Это расплата за удобство за счёт меньшей гибкостью данного инструмента.

Вот с этим абсолютно не согласен. Во-первых, технология MPI служит для создания распределенных программ, и ее использование для обычных многопоточных - стрельба из ружья по воробьям (если сеть задействовать не нужно), а перегонка данных через сокеты в случае, когда достаточно использовать общую память - это лишний оверхед
Или реализации MPI при передаче данных между потоками одной машины не задействуют стек TCP/IP? если так, поделитесь
Во-вторых MPI-програму нужно запускать в свем окружении (на машине должна быть установлена MPI-реализация, программа запущена через mpiexec, или аналогичную программку).
Во всяком случае, ИМХО, за время написания и отладки MPI-программы, OMP версию можно не только написать, а и порядочно оптимизировать.
А если мы хотим достичь идеальной оптимизации, и гибкости OMP действительно не хватает (это проявляется не во всех задачах), то лучше уж заюзать TBB, или обычное многопоточное программирование.

>TBB это еще один инструмент, насколько он гибкий/мощный/удобный/эффективный нужно смотреть. Некоторый его плюс в том что он слегка отвязан от реализации компилятора к которой например привязан тот же самый OpenMP

+1, только похоже, он к процессору слегка привязан

Модеры, исправьте ошибку в заглавии! должно быть Threading Building Blocks

>Даже не надо беспокоится на сколько потоков OMP будет параллелить, а это удобно

Это _фундаментальная_ ошибка. Еще как надо. Мы же говорим о _эффективной_ параллелизации а не для той что галочки.

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

Через какие _сокеты_ ? Посмотрите на _современные_ реализации MPI.

Они порвут OpenMP код даже на 2-х ядрах.

>Во-вторых MPI-програму нужно запускать в свем окружении (на машине должна быть установлена MPI-реализация, программа запущена через mpiexec, или аналогичную программку

Это пожалуй единственный минус в сравнении этих 2-х технологий.

Разумеется если вся песочница, в которой вы гоняете потоки, влазит в кеш то там оверхед будет только на синхронизацию и конкурентный доступ к FSB. Как только вы ощутимо вылазите из кеша, omp без оптимизации под локальность доступа к данным убивает весь перфоманс и задача не просто перестаёт масштабироваться а просто заваливается по скорости в отрицательную область (чем больше конкурирующих потоков тем меньше скорость выборки данных при вроде бы свободных ресурсах).

> Через какие _сокеты_ ? Посмотрите на _современные_ реализации MPI.

Через самые обыкновенные. Это, конечно, зависит от реализации и от параметров, с которыми она собиралась, многие поддерживаю разные механизмы межпроцессного взаимодействия. Что можно получить в лучшем случае - так это общение между MPI-процессами через разделяемую область памяти, но это лишний memcpy, а вот в худшем случае будут именно сокеты. Ни о какой общей памяти как в случае OpenMP говорить не приходится.

>Через самые обыкновенные. Это, конечно, зависит от реализации и от параметров, с которыми она собиралась, многие поддерживаю разные механизмы межпроцессного взаимодействия. Что можно получить в лучшем случае - так это общение между MPI-процессами через разделяемую область памяти, но это лишний memcpy, а вот в худшем случае будут именно сокеты. Ни о какой общей памяти как в случае OpenMP говорить не приходится.

Ашшо один. Срочно всем читать что такое intracomm и с чем его едят.

Еще раз. Современные версии MPI/MPI2 (как пример MVAPICH 0.9.9) в интракоме рвут OpenMP как класс за счёт более гибкой оптимизации доступа к памяти. Речь разумеется идёт о больших реальных задачах а не о учебных примерах типа "Helo World".

>Что можно получить в лучшем случае - так это общение между MPI-процессами через разделяемую область памяти, но это лишний memcpy

Вы просто не представляете сколько "лишнего" неявного копирования между кешем и памятью заложено в неоптимизированном по локальности OpenMP ;)

> юЬЬН НДХМ. яПНВМН БЯЕЛ ВХРЮРЭ ВРН РЮЙНЕ intracomm Х Я ВЕЛ ЕЦН ЕДЪР.

бШ ХЛЕЕРЕ Б БХДС ХМРПЮЙНЛЛСМХЙЮРНПШ? нМХ РСР ЯНБЕПЬЕММН МЕ ОПХВЕЛ. аНКЕЕ РНЦН, МХЙРН ХГ ОНКЭГНБЮРЕКЕИ МХ Н ЙЮЙХУ ХМРПЮЙНЛЛСМХЙЮРНПЮУ Х НДМНЯРНПНММХУ ЙНЛЛСМХЙЮЖХЪУ (БНР НМХ РСР ДЕИЯРБХРЕКЭМН ╚ОПХВЕЛ╩!) ГМЮРЭ МЕ УНВЕР, Х ХЯОНКЭГНБЮРЭ МЕ ЯНАХПЮЕРЯЪ.

> еЫЕ ПЮГ. яНБПЕЛЕММШЕ БЕПЯХХ MPI/MPI2 (ЙЮЙ ОПХЛЕП MVAPICH 0.9.9) Б ХМРПЮЙНЛЕ ПБСР OpenMP ЙЮЙ ЙКЮЯЯ ГЮ ЯВ╦Р АНКЕЕ ЦХАЙНИ НОРХЛХГЮЖХХ ДНЯРСОЮ Й ОЮЛЪРХ.

оНД ╚АНКЕЕ ЦХАЙНИ НОРХЛХГЮЖХЕИ ДНЯРСОЮ Й ОЮЛЪРХ╩ ХЛЕЕРЯЪ Б БХДС ХЯОНКЭГНБЮМХЕ RDMA? еЯКХ МЕР, РН ОПХ ВЕЛ РСР MVAPICH ЯН БЯЕЛХ ЕЦН 17-Ч ОНКЭГНБЮРЕКЪЛХ?

По поводу MVAPICH

http://mvapich.cse.ohio-state.edu/overview/mvapich/features.shtml

Optimized intra-node communication support by taking advantage of shared-memory communication (NEW) Multi-core optimized scalable shared memory design Performance benefits of multi-core optimized support can be found here. Bus-based SMP systems NUMA-based SMP systems Processor Affinity

Про 17 пользователей смешно ;)

RDMA к интракоммуникациям вобщем-то прямого отношения не имеет (хотя я лично как раз её и использую и заметьте - никакого TCP и никаких сокетов)

Не нравится MVAPICH ? А что используете ? LAM ?

Ну тогда откройте для себя rpi модули sysv, usysv а такще coll модули smp и shmem.

А использовать tcp/crtcp модули в интракоме может только СЗЗБ.

Только мы как то от темы слегка отдалились.

Дабы поставить жирную точку в на теме производительности OpenMP vs MPI специально закину в галлерею картинку на тестик http://www.linux.org.ru/gallery/2055162.png

Чтобы долго не гонять машину взял тестик маленьким (60x60x60) из за чего задача масштабируется плохо (для обеих версий). Это с учётом того что OpenMP версия специально оптимизировалась под локальность.