The OpenNET Project / Index page

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

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

15.11.2024 09:44

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

Основные изменения в OpenMP 6.0:

  • Упрощён процесс программирования задач (task), определяющих независимые части программы, которые могут выполняться параллельно с другими частями.
    • Добавлена возможность выполнения задач в потоках free-agent, не привязанных к группам потоков (teams), выполняющих параллельные регионы (parallel region, блок кода, выполняемый в нескольких потоках).
    • Обеспечена поддержка сохранения графа задач (taskgraph), определяющего зависимости между задачами и порядок выполнения задач, для повышения эффективности последующего повторного воспроизведения.
    • Реализован механизм прозрачных задач ("transparent tasks") для упрощения управления зависимостями и автоматического управления выполнением дочерних задач.
  • Расширена поддержка вычислительных устройств, которые могут использоваться для выполнения параллельных задач (CPU, GPU, DSP и т.п.).
    • Добавлен новый синтаксис массивов, позволяющий использовать директиву "workdistribute" для разделения обработки массивов между разными единицами работы.
    • Расширены возможности управления выделением памяти, упрощающие управление переменными, для которых память выделяется динамически.
    • Расширена поддержка атрибутов, определяющих распределение данных между устройствами по умолчанию.
    • Упрощено написание кода для асинхронной передачами данных дополнительным вычислительным устройствам (GPU).
    • Улучшено управление памятью и её привязкой к вычислительным устройствам.
    • Добавлена директива "groupprivate" для закрепления памяти за группой потоков, выполняемых на определённом вычислительном устройстве.
  • Упрощено программирование некоторых видов трансформации циклов, таких как объединение нескольких циклов, изменение порядка вложенных циклов и реверсия циклов.
  • Добавлена новая операция индукции (induction) для организации распараллеливания в циклах простых арифметических вычислений и пользовательских операций, зависящих от предыдущих значений.
  • Добавлена полная поддержка распараллеливания программ, написанных с использованием стандартов C23 (включая синтаксис атрибутов), Fortran 2023 и C++23. Добавлены новые атрибуты для C/C++.
  • Расширены возможности управления хранилищем и памятью. Добавлены новые атрибуты для контроля над тем, как должна выделяться и использоваться память. Добавлен API для определения и запроса пространств памяти (memory space).
  • Удалены возможности, объявленные устаревшими в спецификациях OpenMP 5.0, 5.1 и 5.2.


  1. Главная ссылка к новости (https://www.openmp.org/home-ne...)
  2. OpenNews: Опубликован стандарт параллельного программирования OpenMP 5.1
  3. OpenNews: Опубликован стандарт параллельного программирования OpenMP 5.0
  4. OpenNews: В Clang обеспечена полноценная поддержка OpenMP
  5. OpenNews: Утверждён стандарт POSIX 1003.1-2024
  6. OpenNews: Релиз PoCL 6.0 с независимой реализацией стандарта OpenCL
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62236-openmp
Ключевые слова: openmp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:44, 15/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Существуют ли какие-то применения openmp на практике?
     
     
  • 2.4, Аноним (4), 11:12, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В Gentoo добавил, кроме всего прочего, в CFLAGS="... -fopenacc -fopenmp ..." Все собирается и работает без проблем.

    Увеличение производительности не тестировал.

     
     
  • 3.6, Аноним (1), 11:19, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Увеличение производительности не тестировал.

    Было ли это увеличение, скорее там уменьшение.

    У меня  для фортрана так с надеждой на лучшее (а гфортран очень тормозной код генерирует в целом) FCFLAGS="${COMMON_FLAGS} -fopenmp -fprefetch-loop-arrays -fexternal-blas -fblas-matmul-limit=15"

    Наверно какие-то применения на суперкомпах можно найти, но вот есть ли преимущества обычного софта?

     
     
  • 4.8, Аноним (8), 11:43, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Если в софте возможности OpenMP никак не использованы, то и пользы от добавления этих флагов никакой.
     
  • 3.18, Аноним (18), 15:56, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если софт использует OpenMP, то он без этих флагов не скомпилируется, как я понимаю. Нужные пакеты сами добавляли, а для остальных бесполезно.
     
  • 3.20, Аноним (20), 16:09, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    "... -fopenacc...

    гусары молчать!

     
     
  • 4.33, Аноним (33), 18:24, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У меня две дискретки AMD стоят, раньше и opencl включал, вдруг поможет производительности для пары пакетов.

    Или есть какие нюансы?

     
  • 2.9, Аноним (9), 11:47, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для консьюмерских приложений, вроде нет ничего современного...

    Проблема в архитектуре современных серверов. Сейчас нельзя просто так купить привычные для OpenMP SMP-систему, везде ccNUMA и всякие гетерогенные SoC.

    В этой ситуации сама концепция shared memory и модель fork-join летит псу под хвост.
    Да, безусловно OpenMP поддерживает NUMA в какой-то степени в какой-то из свежих спецификаций, что даёт понять приложению о топологии памяти (она же неравномерная).

    Вот только дальше начинается проблема с фиктивными ядрами на всяких современных amd64-процессорах. Ну знаете, когда в процессоре 48 "физических" ядер, а с DRAM-контроллером могут взаимодействовать только 12. При этом из них только 4 могут иметь один мультиплаер по частотам, а все остальные другой.

    То есть по идее можно все переписать на новые версии OpenMP, но кто бы это делал...
    Ну то есть масштабирование многопоточного приложения на системах с неравномерным доступом к памяти обычно требует реализации внутренненго планировщика, выполненного как супер-сервер. Таких реализаций на OpenMP я не знаю, возможно они есть, скиньте. Альтернатива - платформозависимые API для работы с потоками и процессами, которые умеют лучше и больше, но уже под конкретную ОС/планировщик.

    По-факту, никто не парится. Все эти высокопросизводительные многопоточные вычисления просто пихают в виртуалки, чтобы вышестоящая инфра разобралась со всем этим и выдала равномерную память UMA, где shared memory не деградирует за счёт того что часть тредов/физических устройств сидят за интерконнект-шинами.

     
     
  • 3.29, 123 (??), 17:48, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > По-факту, никто не парится. Все эти высокопросизводительные многопоточные вычисления просто пихают в виртуалки, чтобы вышестоящая инфра разобралась со всем этим и выдала равномерную память UMA

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

     
  • 2.12, Анонимов (?), 12:09, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не особо.
    Раньше можно было выйграть пару циклов в расчетном по для суперкластеров в связке OpenMP+MPI (HybridPP), но в последние лет 10 особо голову сношать себе не хочет и используют чистый MPI.
     
  • 2.13, Neon (??), 14:08, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для некоторых задач, типа решения систем диф.уравнений, работа с матрицами и т.д. дает значительное ускорение. Обычно такие задачи специализированные и самописные. Обычному софту openmp мало помогает, плохо автоматически он параллелиться.
     
     
  • 3.30, C2D Debian Xfce (?), 17:49, 15/11/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.26, Бывалый Смузихлёб (ok), 17:33, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    как задача на лабораторной
     
  • 2.32, Аноним (32), 18:05, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    да
     

  • 1.5, Аноним (5), 11:15, 15/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Извините, ничего производительнее, чем просто std::thread, мои эксперименты не нашли. Ни TBB, ни OpenMP.
     
     
  • 2.7, Анониматор (?), 11:26, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вряд ли оно имеет целью увеличение производительности. Скорее просто стандарт, чтоб программисту было легче пересаживаться с одного языка на другой
     
  • 2.10, Аноним (8), 11:47, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    std::thread, само по себе, никак не задействует DSP, если он емеется, и/или GPU.
     
     
  • 3.17, Аноним (17), 14:52, 15/11/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.11, Аноним (11), 12:07, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У него под капотом обычный pthread
     
     
  • 3.15, Аноним (17), 14:51, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, необязательно.
    Во-вторых, именно поэтому я pthread не упомянул. Это платформозависмое API, которое бесполезно почти. Обёртки вокруг него и winapi - zero cost, нет особых причин юзать платформозависимое API.
     
  • 2.14, Neon (??), 14:10, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так openmp делает тоже самое, только автоматически для некоторых задач. Выше физических ограничений платформы не прыгнешь
     
     
  • 3.16, Аноним (17), 14:52, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >только автоматически

    С OpenAI o1 не путайте. Кодить всё равно приходится. Причём то же самое, просто в другом виде.

     

  • 1.19, Аноним (19), 16:07, 15/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Все эти потоки и многопроцессорность не что иное как путь в никуда. Инженерам нужно увеличивать производительность в однопотоке, а не костылить. А то вон уже есть процы со 192 потоками, а скроллинг в хроме всё равно со статтерами и микрофризами.
     
     
  • 2.21, anonymous (??), 16:33, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Скроллинг со статтерами (кандидат на новый мем? вместо "как конпелять кде под фрибзд")? Из за натыканых везде особенно в ядре "сохранялок энергии". Как нубуки стали пиарить, с тех пор всё в этой коричневой "энергосохраняющей" субстанции.
     
     
  • 3.23, Аноним (19), 16:52, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да ты повідключай все энергосберегайки, так комп будет жрать как 4 пни во времена прескотов. И не факт что избавишься от статтеров, потому что они завязаны на 1 поток, на который разрабы куй ложили в угоду многопоточности. Даже в эппл не смогли побороть эту бяку, хотя вообще в отдельный поток вынесли отрисовку.
     
  • 2.27, Аноним (27), 17:43, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Все эти потоки и многопроцессорность не что иное как путь в никуда. Инженерам нужно увеличивать производительность в однопотоке, а не костылить.

    Удивительно, как такие комментарии набирают кучу плюсиков. 🤦 Это многое говорит об уровне компетенции большей части здешних комментаторов.

    Да, уважаемый эксперт, нужно в один поток. А заодно вырубить
    оптимизации на уровне компилятора, а на уровне CPU - предсказание ветвей, спекулятивное выполнение и остальной прогресс за последние 40 лет. Ну, чтобы инженеры булки не расслабляли, а оптимизациями занимались. Вот тогда в хроме скроллинг будет ого-го!

     
     
  • 3.28, C2D Debian Xfce (?), 17:47, 15/11/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.35, Аноним (-), 19:16, 15/11/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     

     ....ответы скрыты (5)

  • 1.25, Аноним (25), 17:30, 15/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Параллельное программирование это когда два программиста работают над одной задачей. Multy Processing - множественная обработка.
     
     
  • 2.31, 123 (??), 17:53, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Parallel Processing, Parallel Execution то же может применяться
     
  • 2.36, Аноним (36), 19:21, 15/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не поняли, это когда параллельно на программирование, но кипишь идёт.
     

  • 1.34, Аноним (-), 19:09, 15/11/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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