The OpenNET Project / Index page

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

В Clang обеспечена полноценная поддержка OpenMP

22.05.2015 20:39

Разработчики проекта LLVM объявили о реализации в компиляторе Clang полной поддержки стандарта OpenMP 3.1 (Open Multi-Processing), предоставляющего средства для применения методов параллельного программирования в программах на языках Си и Си++. OpenMP открывает перед пользователями Clang возможность использования всей мощи современных многоядерных процессоров с блоками векторизации.

Доступны как средства обеспечения параллелизма на уровне задач (распараллеливание функций и циклов), так и параллелизма на уровне данных (векторизация, распараллеливание типовых операций над массивами данных). В том числе реализованы комбинированные директивы, такие как "#pragma omp parallel for" и "#pragma omp parallel sections", а также элементы стандарта OpenMP 4.0. Частично реализованы атомарные операции ("#pragma omp atomic") и средства векторизации последовательных и параллелизированных циклов на процессорах с поддержкой инструкций SIMD ("#pragma omp simd").

Реализация OpenMP в Clang базируется на открытой компанией Intel runtime-библиотеке OpenMP, которая связывается с итоговыми OpenMP-приложениями и выполняет диспетчеризацию потоков в процессе выполнения OpenMP-программы. Из особенностей библиотеки отмечается поддержка различных аппаратных архитектур (x86, x86_64, PowerPC, ARM), высокая производительность и совместимость на уровне ABI с GCC и проприетарными OpenMP-компиляторами Intel.

Для сборки программы с задействованием OpenMP достаточно указать при компиляции опцию "-fopenmp", а также пути к заголовочному файлу ("-I путь к omp.h") и библиотеке ("-L путь к библиотеке openmp").

  1. Главная ссылка к новости (http://blog.llvm.org/2015/05/o...)
  2. OpenNews: В проект LLVM вошла разработанная в Intel runtime-библиотека OpenMP. Red Hat представил OpenMP 4.0 для GCC
  3. OpenNews: Выпущены спецификации OpenMP 4.0
  4. OpenNews: Проект по добавлению поддержки OpenMP в LLVM
  5. OpenNews: Опубликован стандарт OpenMP 3.1, определяющий API для параллельного программирования
  6. OpenNews: Для компилятора Clang реализована поддержка OpenMP
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/42283-openmp
Ключевые слова: openmp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, 3draven (ok), 21:30, 22/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Это получается теперь софт станет еще немного дальше от 386 компов и наконец то заметит, что на дворе 2015 год?
     
     
  • 2.3, ананим.orig (?), 21:48, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Это означает, что всякий крап (аля флэш) будет сжирать на 8-ядернике не 1х100%, а 8х100%.
     
     
  • 3.8, irinat (ok), 22:17, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > флэш

    Flash давно умеет рисовать в несколько потоков. Поэтому там где Chrome + JS + HTML5 canvas выдаёт 20 fps, упираясь в одно ядро, Flash вытягивает 60. Лимит у него в 60 fps. Конечно, выедает при этом 300%, от этого никуда денешься.

    http://www.craftymind.com/factory/guimark2/FlashChartingTest.html

    http://www.craftymind.com/factory/guimark2/HTML5ChartingTest.html

     
     
  • 4.16, ананим.orig (?), 00:38, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Поэтому там где Chrome + JS + HTML5 canvas выдаёт 20 fps, упираясь в одно ядро

    Сферичское ядро то? В сферическом же вакууме?
    Предупреждать надо.
    А то на своём 4к ниже 30фпс не видел.

    Зыж
    А поэтому, чтобы не было такого безобразия (когда без флэша низя. Ещё бывает):
    > Flash вытягивает 60. Лимит у него в 60 fps. Конечно, выедает при этом 300%, от этого никуда денешься.

    Предпочитаю фф. Ибо под линухом он со старым флэшем, который за 1 ядро не вылазит. VDPAU умеет и ладно.

     
     
  • 5.17, irinat (ok), 01:11, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Сферичское ядро то?

    А в чём смысл указывать конкретную модель? Свести всё к сравнению у кого проц круче?

    Видимо, ты не уловил суть: софт не становится быстрее только от того, что в компиляторе появилась поддержка OpenMP. От того, что ты Firefox пересоберёшь новым clang'ом, он не станет волшебным образом использовать несколько ядер. Для этого надо переосмыслить граф зависимостей.

    > Ибо под линухом он со старым флэшем, который за 1 ядро не вылазит.

    Проверил специально на 11.2, он тоже умеет в несколько потоков рисовать.

     
     
  • 6.21, ананим.orig (?), 03:12, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > А в чём смысл указывать конкретную модель? Свести всё к сравнению у кого проц круче?

    А в чём смысл выковыряных из носа 20фпс?
    У меня в 1 поток было всё зашибись, теперь дцать. Напуркуа?
    > Видимо, ты не уловил суть: софт не становится быстрее только от того, что в компиляторе появилась поддержка OpenMP.

    Видимо ты а) плохо воспитан(Ы), б) влез в обсуждение только для того, чтобы влесть, в) и дураку понятно (более того, речь идет как раз о том, что софт будет (суммарно) медленнее. Из-за того, что опенмп будут пихать куда попало, потому что стоимость вхождения резко падает), как результат — если флэш (как пример) стал жрать цпу больше, значит кому-то другому в этот же момент придется жрать меньше (например компиляция), а поскольку не факт кто в конкретный момент победит в конкуренции за порцию ресурсов, то и (например) тиринг не исключен.

    Зыж
    > Проверил специально на 11.2, он тоже умеет в несколько потоков рисовать.

    Х/з, у меня в один. И больше 100% (старый флэш в фф) не жрёт.
    Тот же контент на хроме (ну или хромиуме с хромовскими плагинами) запросто может сожрать 180% суммарно.

     
     
  • 7.31, irinat (ok), 13:37, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> А в чём смысл указывать конкретную модель? Свести всё к сравнению у кого проц круче?
    > А в чём смысл выковыряных из носа 20фпс?

    Вот и я про то же. Само по себе число 20 ничего не значит без указания условий получения результата. А вот сравнение чисел 20 и 60 уже вполне имеет значение, о чём я и писал.

    Ты сказал, что некоторый софт теперь будет есть больше CPU, приведя в пример Flash. А я говорю, что там _уже_ есть поддержка работы в несколько потоков. Там, где это было возможно, это делают и без OpenMP. Добавление поддержки OpenMP в компилятор не делает последовательный код параллельным. Что тебе ещё не понятно?

    > плохо воспитан

    Мне вот интересно, а не является ли указание на плохое воспитание признаком плохого воспитания?

    > влез в обсуждение только для того, чтобы влесть

    Можно сказать, что у тебя прямо была причина посерьёзнее. Ну и льстить я никому пока не собирался.

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

    OpenMP вызывает тиринг? Чудесные умозаключения.

    > Х/з, у меня в один

    Именно на том тесте проверял?

    > может сожрать 180%

    Какой смысл покупать процессор, если его не использовать? Мне больше нравится идея race to sleep, пусть на полной скорости сделает работу как можно быстрее, а потом отправляется спать.

    Терпеть лаги, когда можно не терпеть — глупо.

     
  • 7.49, Michael Shigorin (ok), 23:18, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Видимо ты а) плохо воспитан(Ы), б) влез в обсуждение только для того, чтобы влесть

    Очевидно, нет.

     
     
  • 8.51, ананим.orig (?), 04:55, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да И какова же была цель Хотя бы одну, для примера Про пункт а замну пока ... текст свёрнут, показать
     
     
  • 9.52, Michael Shigorin (ok), 11:39, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    За человека и его цель говорить не стану, но 8 как минимум для меня оказалось д... текст свёрнут, показать
     
  • 7.57, Vkni (ok), 02:09, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а поскольку не факт кто в конкретный момент победит в
    > конкуренции за порцию ресурсов, то и (например) тиринг не исключен.

    Это вопросы к планировщику ЦП. Хотя, конечно, если он фиговат, как в Уиндоуз, то лучше оставлять резерв ресурсов ЦП.

     
  • 5.59, Аноним (-), 11:45, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    20 фпс и там и там на моем ноуте)
     
  • 4.20, RNZ (ok), 02:25, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Chromium: 41.0.2272.76 (Developer Build) Ubuntu 15.04
    Revision: ff3293b421463d090f04f4d942d64af8cfd3b234
    OS: Linux
    Blink: 537.36 (@191030)
    JavaScript: V8 4.1.0.21
    Flash: 17.0.0.169

    http://www.craftymind.com/factory/guimark2/FlashChartingTest.html
    Test Average: 41.07 fps

    http://www.craftymind.com/factory/guimark2/HTML5ChartingTest.html:
    Test Average: 56.48 fps

    Что я делаю не так?

     
     
  • 5.22, Аноним (-), 03:42, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Флеш захлебнулся, гона-потоков (Race condition).
     
  • 5.39, irinat (ok), 18:03, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Что я делаю не так?

    Всё делаешь так. К сожалению, на моём железе Flash всё ещё выдаёт более плавную анимацию.

     
  • 5.56, Аноним (-), 16:34, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ubuntu 14.04, Firefox 38, Flash 11.2

    Flash
    Test Average: 59.82 fps

    HTML5
    Test Average: 13.78 fps

     
  • 4.60, systemd (?), 13:49, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    40 - html5

    50 -flash

     
  • 4.63, Анононим (?), 17:02, 27/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    html5 56-58 fps
     
  • 2.5, Куяврег (?), 21:56, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    openmp это далеко не единственный способ заметить, что на дворе 2015
     
     
  • 3.6, 3draven (ok), 22:00, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > openmp это далеко не единственный способ заметить, что на дворе 2015

    Да все равно какой способ У меня восьмипотоковый (гипертрейдинг и 4 ядра) и7 проц, а тормозила тормозит. Пусть случится чудо и она сожрет все 4 ядра. И все либы, дрова, прослойки и прочий ливер тоже. Я, за.

     
  • 3.10, Аноним (-), 22:28, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > openmp это далеко не единственный способ заметить, что на дворе 2015

    технически - один из лучших.
    для тех, кто никак с С и С++ не слезет в программировании.


     
  • 3.11, ы (?), 22:35, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >openmp это далеко не единственный способ заметить, что на дворе 2015
     
  • 2.26, Аноним (-), 12:30, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для пользователей mandala, собирающих всё clang - возможно. В нормальных дистрибутивах gcc это делает уже несколько лет.
     
  • 2.48, Grammar Narziss (?), 22:32, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    "наконец-то"
     

  • 1.4, Аноним (-), 21:51, 22/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Почему отдельной библиотекой? Почему всё на директивах? Почему нельзя было, например, развить сам язык в эту сторону?, сделать отдельные многопоточные циклы, отдельные векторые типы данных, как в том же GLSL? Это выгладит как подпорка-костыль для немощного языка...
     
     
  • 2.7, Аноним (-), 22:13, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    потому что стандарт
     
     
  • 3.29, Аноним (-), 13:06, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Только вот библиотека не оптимизирует это всё так, как мог бы компилятор -> явно упущенный потенциал. В расте распараллеливание реализовано найтивно. По этому пункту он скоро обойдет c++.
     
  • 2.13, Аноним (-), 23:45, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что добавить нужную функциональность прагмами проще, чем переделывать ядро языка, и это не ломает совместимость.
    Про немощный язык - это вообще пушка. Давайте DSL для разработки интернет-магазинов включим в С, чего уж там. А то немощно как-то.
     
     
  • 3.28, Аноним (-), 13:03, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В том то и дело что он не немощный, и можно было бы переписать ядро. Прагмы сильно усложняют код, делают его не читаемым и легко допустить ошибки в логике.
     
     
  • 4.33, Crazy Alex (ok), 14:03, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я сильно сомневаюсь, что сишники с восторгом восприняли бы идею такого усложнения синтаксиса. Вот в плюсах - да, самое место было бы. Но там, вроде, только футуры.
     
     
  • 5.43, Аноним (-), 18:31, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Си уже давно прекратил развитие, для этого есть с++. Но от тоже, по всей видимости, ступил на этот путь. Вообще не понятно куда всё катится, я лично не вижу сейчас языка на роль универсального современного инструмента. Нигде нет встроенной поддержки гибкой многопоточности типа openmp, поддержки гетерогенных вычислений типа opencl и работы с графикой типа glsl в самом коде программы. И развития в этом направлении никакого.
     
  • 2.54, 0xd34df00d (??), 15:18, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В пропозалах на C++17, ЕМНИП, есть поддержка векторных переменных и операций с ними, причём достаточно умная, чтобы быть портируемой на разную ширину регистров SIMD.

    Ну и есть Boost.SIMD.

     

  • 1.9, Аноним (-), 22:23, 22/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А что, в Clang до сих пор не было поддержки OpenMP? Я знал, что он отстаёт от GCC, но чтобы настолько...
     
     
  • 2.12, Developer1 (?), 22:51, 22/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кроме OpenMP в мире больше ничего не существует?
     
     
  • 3.15, Dark Amateur (?), 00:34, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, есть ещё Cilk, только вот GCC его тоже умеет.
     
     
  • 4.18, Developer1 (?), 01:15, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    GCC умеет Grand Central Dispatch?
     
     
  • 5.19, Аноним (-), 01:47, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эппловский форк GCC умеет. А в линуксе этой хрени нет в принципе, ни в GCC, ни в Clang.
     
     
  • 6.23, Аноним (-), 03:43, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Эппловский форк GCC умеет. А в линуксе этой хрени нет в принципе,
    > ни в GCC, ни в Clang.

    Не нужно, есть на OpenBSD

     
  • 6.27, Developer1 (?), 12:47, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Эта хрень в плане производительности и удобства разработки рвет по всем фронтам вышеупомянутый сабж.
     
     
  • 7.35, Куяврег (?), 16:27, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Эта хрень в плане производительности и удобства разработки рвет по всем фронтам
    > вышеупомянутый сабж.

    справедливости ради: рвать она может и рвёт, но давай посмотрим, у скольки проектов она в зависимости. опенмп в шланге - это плюс, как ни крути. что не делает openmp лучше или хуже других либ.

     
     
  • 8.47, Developer1 (?), 19:24, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Справедливости ради и сравнение что из них хуже или лучше достаточно бесполезно,... текст свёрнут, показать
     
     
  • 9.50, Michael Shigorin (ok), 23:23, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Технически говоря, 9 на которое отвечали в 12 таковым не было ... текст свёрнут, показать
     
     
  • 10.55, Developer1 (?), 16:04, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А что не так в 12 Вполне нейтрально и хренью ничего не называю, так что техни... текст свёрнут, показать
     
  • 4.45, Аноним (-), 19:07, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Только в отдельной ветви, причем, отстающей. Пока поддержка силка не будет обеспечена стабильно, толку от нее нет.
     

  • 1.14, Аноним (-), 00:10, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    С нетерпением жду бенчев на Фурониксе!
    1. Скорость копирования файлов утилитами, скомпилированными гцц и шлангом.
    2. Скорость загрузки убунты и <BSDя или открытая мандрива>
    Настоятельно советую эксперту-бенчмаркиру Михаилу запускать тесты с шлангом на любимом Xeone, а отсталый гцц влепить на старенький ноут (но не наоборот!)
     
  • 1.25, Аноним (25), 10:33, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    если головой или ручками нормально программу ненапишешь, никакие быблобиблиотеки непомогут тому, что в итоге получилось, работать качественно, а не забивать все ядра потоком разннобразного мусора и хлама, при мизерном результате на выхлопе.
     
  • 1.30, Аноним (-), 13:12, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    OpenMP - костыль для тех, кто сам не может написать нормальный параллельный код, или для тунеядцев, которые не хотят писать нормальный параллельный код.
    Распараллеливание множества мелких циклов через OpenMP вряд ли даст существенное ускорение, а вот энергопотребление увеличит на порядок.
     
     
  • 2.32, Crazy Alex (ok), 13:51, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А компьютер вообще сделан для тех, кто не может посчитать на бумажке. Но вам же неважно, что на бумажке долго и большой шанс ошибиться - главное, что не тунеядцы.

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

     
  • 2.34, Аноним (-), 15:44, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    то есть для 98% разработчиков.
    "паралельный" код в рамках С/С++ писать трудно В ПРИНЦИПЕ.
    а мигрировать на другое - никто почти не хочет или готов.
    OpenMP один из лучших. и уж точно среди комьюнити-пилимых - Самый.
     
     
  • 3.42, Аноним (-), 18:25, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > OpenMP один из лучших

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

     
  • 2.36, Куяврег (?), 16:29, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > OpenMP - костыль для тех, кто сам не может

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

     
     
  • 3.41, Аноним (-), 18:19, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это так, только не в таких фундаментальных вещах как многопоточность и гетерогенные вычисления. Всё это должно быть в ядре любого современного языка системного уровня.
     
     
  • 4.62, Куяврег (?), 23:41, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Это так, только не в таких фундаментальных вещах как многопоточность и гетерогенные
    > вычисления. Всё это должно быть в ядре любого современного языка системного
    > уровня.

    вопрос в удобстве, простоте и прочих весьма субьективных вещах. ну не запретишь ты писать 10 библиотек jpeg, png и прочих, вплоть до самых низкоуровневых.


     

  • 1.40, Аноним (-), 18:17, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В язык ничего добавлять больше не хотят? Теперь всё дополнительное будет на костылях? Значит пора делать новый Си с тремя плюсами, который будет найтивно поддерживать многопоточные циклы, векторные типы и найтивную работу с любым оборудованием, включая видео.
     
     
  • 2.46, Аноним (-), 19:11, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Скоро все на прагмах писать будут.
     

  • 1.44, Аноним (-), 19:04, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    OpenMP-ветвь Clang'а существует уже давно, в чем новость? Неужели его добавили в основную ветку? В какой версии он будет доступен?
     
  • 1.53, Аноним (-), 14:41, 24/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Надеюсь в следующем стандарте это всё реализуют непосредственно в языке
     
  • 1.58, Аноним (-), 05:11, 25/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    5 лет ждали, ну наконец-то.
     

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



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

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