The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Опубликован стандарт параллельного программирования OpenMP 4.5

29.11.2015 10:34

После двух с половиной лет разработки опубликован набор спецификаций OpenMP 4.5 (Open Multi-Processing), определяющих API и способы применения методов параллельного программирования для языков Си, Си++ и Фортран на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD). OpenMP 4.5 примечателен расширением средств для параллельного программирования на системах с аппаратными ускорителями и GPU, а также поддержкой распараллеливания циклов с хорошо структурированными зависимостями. Реализация OpenMP 4.5 уже почти завершена в GCC и будет представлена в выпуске GCC 6.0, а также уже началась в экспериментальной ветке Clang, в которой формируется выпуск 3.8.

Основные новшества OpenMP 4.5:

  • Значительно улучшена поддержка дополнительных аппаратных вычислительных устройств, таких как специализированные аппаратные ускорители. Реализованы механизмы для привязки к подобным устройствам операций с неструктурированными данными или асинхронного выполнения кода. Добавлены процедуры для управления памятью устройства, позволяющие выделять, копировать и высвобождать блоки памяти;
  • Представлен механизм "doacross loops", позволяющий организовать распараллеливание циклов с хорошо структурированными зависимостями;
  • Новая конструкция "taskloop", позволяющая разделять циклы на задачи, избегая необходимости выполнения всех потоков внутри цикла;
  • Поддержка сокращения (редукции) массивов С/С++;
  • Новые механизмы hint-ов, через которые можно задать параметры выставления задачам относительных приоритетов и выбора предпочтительных средств синхронизации;
  • Поддержка привязки (affinity) потоков к заданным вычислительным устройствам;
  • Возможность распараллеливания многих приложений, написанных в соответствии со спецификацией Fortran 2003;
  • Поддержка расширений SIMD, в том числе возможность указать точное число обработчиков в потоке (метрика SIMD Width) и дополнительные атрибуты при обращении к общим данным.


  1. Главная ссылка к новости (http://openmp.org/wp/2015/11/o...)
  2. OpenNews: В Clang обеспечена полноценная поддержка OpenMP
  3. OpenNews: В проект LLVM вошла разработанная в Intel runtime-библиотека OpenMP. Red Hat представил OpenMP 4.0 для GCC
  4. OpenNews: Выпущены спецификации OpenMP 4.0
  5. OpenNews: Опубликован стандарт OpenMP 3.1, определяющий API для параллельного программирования
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/43412-openmp
Ключевые слова: openmp, parallel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Илья (??), 11:45, 29/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне показалось, или дизайн подправили?
     
  • 1.2, Аноним (-), 12:13, 29/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С кем не общался, все упоминают OpenMP как костыль. И на практике вообще не встречал его применение, хотя много работаю с чужим кодом. Везде используют std::thread, pthread, qthread, qtconcurrent, но не openmp. Кто что думает вообще по этому стандарту? Кто работал с ним?
     
     
  • 2.3, KLIM (?), 12:40, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я пишу научное ПО с применением openmp. В научных вычислениях это станадрт наряду с MPI.
     
  • 2.5, Аноним (-), 13:07, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    OpenMP - адский костыль. Представьте, каково это, отлаживать код в котором существенная часть логики сидит в прагмах.
     
     
  • 3.18, ferux (ok), 17:22, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Кому не нравятся прагмы, есть подвижки к переходу на generalized attributes (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf).
    Да и существует много задач, для распараллеливание решения которых, достаточно прагрмы, вроде #pragma omp parallel for - никаких проблем с точки зрения читаемости кода и легкости его отладки.
     
  • 2.6, АнониМ (ok), 13:22, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Костыль, но попадаются приложения его использующие тот же imagemagick.
     
  • 2.7, Аноним (-), 14:21, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >С кем не общался, все упоминают OpenMP как костыль. И на практике вообще не встречал его применение, хотя много работаю с чужим кодом. Везде используют std::thread, pthread, qthread, qtconcurrent, но не openmp.

    Всё верно и добавить нечего.

     
  • 2.8, Аноним (-), 14:38, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Насколько я помню, изначальная идея была - быстро распараллелить старый код. Поэтому стандарт был построен на прагмах, т.е. по сути командах компилятору, которые сильно замусоривают код, но не требуют его правки. На, как это обычно бывает, реализация поперла дальше идеи.
    Лучше бы это всё реализовывывли в синтаксисе языка, не было бы таких проблем с отладкой. Да и поддержку видеокарт и других устройств уже давно пора вводить непосредственно в c++. Но получается тоже всё будет на прагмах.
     
  • 2.9, solardiz (ok), 15:38, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > Кто работал с ним?

    Мы используем в John the Ripper вот уже 5 лет. OpenMP может работать костылем (и наше применение как раз этому соответствует, т.к. прагмы добавлялись в том числе в старый код), но может и не (не более чем альтернативы) когда пишется новый код и OpenMP хорошо подходит для задачи (обычно это сколько-нибудь длительные вычисления, а не интерактив).

    Проблем с отладкой особо нет (не более чем для альтернатив - ну и что, что прагмы, как будто step-into в их реализации в библиотеке на уровне исходника бы чем-то помог). default(none) помогает избежать части багов в своем коде.

    Проблемы с производительностью есть при частой синхронизации потоков (тысячи раз в секунду) и/или на системах с посторонней загрузкой. Это цена за упрощение кода основной программы. Можно эту цену и не платить, а держать раскидывание частей задачи по потокам более под своим контролем, при этом всё равно используя OpenMP, но тогда смысла использовать именно OpenMP меньше. Зато, если отдать всё решать runtime-библиотеке, раскидыванием по потокам можно рулить (static vs. dynamic, affinity, ...) с помощью переменных окружения (и не только) не тратя на это свой код. При этом основная логика вычислений может быть более наглядно видна в исходнике, чем при явной многопоточности.

    К тому же, есть OpenMP offload, аналога которого в перечисленных альтернативах нет. Мы пока что его попробовали лишь чуть-чуть, с Xeon Phi. Производительность, как и ожидали, получается хорошая лишь для offload-а сколько-нибудь длительных вычислений (хотя бы сколько-то миллисекунд) и небольшого объема передаваемых данных. Тем не менее, в ряде случаев этого может быть достаточно, а исходник получается проще, чем если всё это делать вручную.

     
  • 2.10, pavlinux (ok), 15:46, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > С кем не общался, все упоминают OpenMP как костыль. И на практике вообще не встречал его
    > применение, хотя много работаю с чужим кодом. Везде используют std::thread, pthread,
    > qthread, qtconcurrent, но не openmp.

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


    > Кто работал с ним?

    Ааааа, ну понятно - не читал, но осуждаю.

     
     
  • 3.11, Аноним (-), 15:48, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    OpenMP прагмовая высокоуровневая обертка над тредами
     
     
  • 4.15, Трорвальдс (?), 16:36, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > OpenMP прагмовая высокоуровневая обертка над тредами

    Да-да, "настоящие пОцаны" сразу пишут на ассемблере, а не этих ваших "высокоуровневых обёртках". Cool story bro

     
     
  • 5.16, Аноним (-), 16:57, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Настоящие пацаны давно пишут на
    > std::thread, pthread, qthread, qtconcurrent

    и т.п.

     
  • 3.12, Аноним (-), 15:50, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ... не читал, но осуждаю.

    Не вижу нигде осуждений

     
  • 3.13, Аноним (-), 15:52, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А сравнивать с тредами все равно, что теплое с мягким.

    Раскроешь нам эту изюминку OpenMP? Ведь вопрос был как раз про это, и походу ты один здесь знаешь истину.

     
     
  • 4.21, Dark Amateur (?), 18:56, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хранение последовательной и параллельной программы в едином файле исходного кода. Получение соответствующих бинарников зависит от одного ключа. Как долго придётся корячиться с макросами, чтобы в случае чего, скомпилировать последовательную программу на pthreads?

    Кстати, OpenMP поддерживается MS Visual C++ Compiler, где, внезапно, нет pthreads. Привет, кроссплатформенность.

    Какие аналоги #pragma omp simd есть в pthreads?

     
     
  • 5.22, Аноним (-), 19:07, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Хранение последовательной и параллельной программы в едином файле исходного кода

    Это такая сверх необходимая вещь и всем очень нужная, да еще и не реализуемая на std::thread? Никогда бы не подумал. У всех моих программ простым ключиком можно свести количество потоков к нужному количеству. И это вообще не требует никаких усилий.

     
     
  • 6.23, Dark Amateur (?), 19:15, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это такая сверх необходимая вещь и всем очень нужная

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

    > не реализуемая на std::thread

    Естественно реализуемая. Вопрос в том, какими усилиями?

    > У всех моих программ простым ключиком можно свести количество потоков к нужному количеству

    OpenMP это умеет ещё и переменными окружения.

     
     
  • 7.27, Аноним (-), 19:48, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А в чем разница между отладкой однопоточного и многопоточного приложения? Или вам это нужно только чтобы отследить разницу в выводе соответствующих версий приложения? Честно говоря, на мой взгляд, этот аргумент в пользу OpenMP очень надуманный. И статистика использования openmp говорит не в его пользу.
     
     
  • 8.33, 10й Брейтовский переулок (?), 00:01, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Слив засчитан С ... текст свёрнут, показать
     
  • 5.24, mkarev (?), 19:25, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Какие аналоги #pragma omp simd есть в pthreads?

    Вопрос некорректен, Вы сравниваете теплое с мягким.
    pthreads - библиотека
    OpenMP - языковое расширение, поддержка, которого _необходима_ в компиляторе
    Но автовекторизация есть в любом современном компиляторе.
    Вообще ручной код на интринсиках под заданную архитектуру уделает #pragma omp simd (и любой другой автовекторизатор, включая icc) как стоячего.
    На банальных циклах типа a = a + b автовекторизатор, конечно, справляется, но как только делаем шаг в сторону - просим его, например, векторизовать КИХ фильтр, так внезапно на выходе получаем скалярный код.
    На сегодняшний день нет серебрянной пули для автоматической генерации качественного SIMD кода.

     
     
  • 6.25, Dark Amateur (?), 19:39, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Вопрос некорректен, Вы сравниваете теплое с мягким.

    Не-не-не, как раз тёплое с мягким и сравниваем, а посему вопрос уместен. Скажем спасибо Анониму.

    > OpenMP - языковое расширение, поддержка, которого _необходима_ в компиляторе

    Я-то об этом в курсе.

    > Вообще ручной код на интринсиках под заданную архитектуру уделает #pragma omp simd.

    Не факт. Например, в коде у вас SSE2-интринсики, а у пользователя компилятору строго прописано юзать AVX. Итого: в лучшем случае получите просадку в производительности (ЕМНИП из-за переупаковки данных между группами инструкций), в худшем - ошибку компиляции. С OpenMP такой проблемы не будет. Как и при переносе той же программы на ARM, например.

     
     
  • 7.26, mkarev (?), 19:46, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В худшем случае - Ваша программа упадет на машине без AVX.
    PS: раз уж сравнивать начали с SSE2, то ее старший брат AVX2, т.к. AVX - float point only.

    > С OpenMP такой проблемы не будет. Как и при переносе той же программы на ARM, например

    Ага, проблем не будет. Равно как и скорости ))
    Ну и на всех Ваших армовских компиляторах конечно же есть поддержка самой последне спеки  OpenMP ? Я Вас умаляю.

     
     
  • 8.28, Аноним (-), 19:54, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Начиная с Haswell это, вроде как, не так... текст свёрнут, показать
     
     
  • 9.29, mkarev (?), 19:57, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, потому что в хасвеле появился AVX2... текст свёрнут, показать
     
  • 8.30, Dark Amateur (?), 20:05, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нормальная программа не должна падать ни при каких обстоятельствах Особенно, ес... текст свёрнут, показать
     
     
  • 9.31, mkarev (ok), 21:06, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Согласен, для этого в нормальных программах обмазываются реализациями под кажд... текст свёрнут, показать
     
     
  • 10.32, Dark Amateur (?), 21:45, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    CPUBoss с Вами не согласен http cpuboss com cpu AMD-FX-8320 Кто сказал, что ... текст свёрнут, показать
     
     
  • 11.37, mkarev (ok), 09:03, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Простите, а что это тогда Да, конечно, вы намекаете компилятору, что тут можно... текст свёрнут, показать
     
     
  • 12.43, redwolf (ok), 21:14, 01/12/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я сталкивался с кодом, который использует OpenMP в подобных задачах https opu... текст свёрнут, показать
     
  • 5.39, bOOster (ok), 13:46, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот еслибы это было кроссплатформенностью уровня выполнения, а не компиляции, цены бы этому не было. А так костыль.
     
     
  • 6.44, redwolf (ok), 21:20, 01/12/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот еслибы это было кроссплатформенностью уровня выполнения, а не компиляции, цены бы
    > этому не было. А так костыль.

    По такой логике и Qt --  костыль. И вообще решения на C++ --  костыль.

    А Вы, случаем, не фанат Java?)

     
     
  • 7.45, bOOster (ok), 04:48, 02/12/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Отличная практика путать жопу с пальцем. Главное демагогией позаниматься...
     
  • 2.34, AAAAAAaaAAAAAA (?), 02:04, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я активно использую openMP в программах на Ansi C11 и очень доволен, согласен что для C++ подходит плохо. OpenMP не умеет исключения, STL контейнеров и смартпоинтеров не понимает, проблемы с контрукторами. OpenMP это для С и Fortran, в С++ лучше не стоит.
     
  • 2.47, Аноним (-), 18:20, 05/12/2015 [^] [^^] [^^^] [ответить]  
  • +/
    из НЕ-проприетарного - он пока безальтернативен для HPC, к сожалению.
    не на ICC-же ваять который с MP не дружит. распределенное решение реально работающее - иначе не написать.
     

  • 1.4, alexxy (ok), 12:42, 29/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    OpenMP распространен в научном и инженерном софте, примерно так же как MPI
     
     
  • 2.14, Трорвальдс (?), 16:27, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Только местные школьники-дурачки про это не в курсе :) Эти кловуны выдают бред уровня "pthreads хватит всем", сразу выдающий их "уровень".
     
     
  • 3.17, Аноним (-), 16:59, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • –5 +/
    OpenMP работает на pthreads, не?
     
     
  • 4.19, KLIM (?), 17:25, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://software.intel.com/en-us/articles/threading-models-for-high-performanc

    In 1997, a group of vendors came together under the aegis of hardware manufacturer, Silicon Graphics, to formulate a new threading interface. Their common problem was that the primary operating systems of the time all imposed drastically different ways of programming for threads. UNIX employed Pthreads, Sun used Solaris threads, Windows used its own API, and Linux used Linux threads (until its subsequent adoption of Pthreads). The committee wanted to design an API that would enable a codebase to run without changes equally well on Windows and UNIX/Linux. In 1998, it delivered the first API specification of what was called OpenMP (In those days, the term ‘open’ was associated with the concept of support from multiple vendors-as in open systems-rather than with today’s implication of open source.)

     
     
  • 5.38, dmitrmax (?), 09:58, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Нативно ни одна из этих ОС не поддерживает OpenMP. Таким образом, на Unix-like ОС OpenMP работает через pthread. В винде на WinAPI.
     
  • 4.35, Аноним (-), 02:22, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    OpenMP может работать с SIMD.
    OpenMPI еще и сетевым слоем для распределения по GRID/Hybrid-Cluster.

    Выбор в пользу OpenMPI, если не хотите  писать свои костыли для работы по сети.

     
     
  • 5.36, Аноним (-), 02:23, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > OpenMP может работать с SIMD.
    > OpenMPI еще и сетевым слоем для распределения по GRID/Hybrid-Cluster.
    > Выбор в пользу OpenMPI, если не хотите  писать свои костыли для
    > работы по сети.

    В догонку еще один http://www.mpich.org/


     
  • 2.20, Аноним (20), 18:32, 29/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    и прочая туфта распространена в научном и инженерном софте.
     

  • 1.40, Аноним (-), 14:17, 30/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как вручную рассадить потоки по ядрам?
    В pthread-ax разве есть такая возможность?
     
     
  • 2.41, Аноним (20), 15:56, 30/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    есть, написать свой планировщик
     

  • 1.42, Аноним (-), 18:00, 30/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну да, попросить у планировщика ядра(Линя) два ядра(проца) и раздать своим потокам. Знанит есть АПИ к планировщику(Линя), какое?
    Чет не попадалось, а libgomp как-то делает.
    И у ядер проца нет id-ов (вроде ?).
     
  • 1.46, Аноним (-), 18:18, 05/12/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    автору - SIMD это SIMD. а блоки векторизации - это блоки векторизации - не путаем. аналогично это и векторные процессоры(и подсистемы оных) - с первыми двумя.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру