Разработчики проекта LLVM объявили (http://blog.llvm.org/2015/05/openmp-support_22.html) о реализации в компиляторе Clang полной поддержки стандарта OpenMP 3.1 (http://ru.wikipedia.org/wiki/OpenMP) (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 (http://openmp.llvm.org/), которая связывается с итоговыми OpenMP-приложениями и выполняет диспетчеризацию потоков в процессе выполнения OpenMP-программы. Из особенностей библиотеки отмечается поддержка различных аппаратных архитектур (x86, x86_64, PowerPC, ARM), высокая производительность и совместимость на уровне ABI с GCC и проприетарными OpenMP-компиляторами (http://software.intel.com/en-us/intel-compilers) Intel.
Для сборки программы с задействованием OpenMP достаточно указать при компиляции опцию "-fopenmp", а также пути к заголовочному файлу ("-I путь к omp.h") и библиотеке ("-L путь к библиотеке openmp").URL: http://blog.llvm.org/2015/05/openmp-support_22.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42283
Это получается теперь софт станет еще немного дальше от 386 компов и наконец то заметит, что на дворе 2015 год?
Это означает, что всякий крап (аля флэш) будет сжирать на 8-ядернике не 1х100%, а 8х100%.
> флэшFlash давно умеет рисовать в несколько потоков. Поэтому там где Chrome + JS + HTML5 canvas выдаёт 20 fps, упираясь в одно ядро, Flash вытягивает 60. Лимит у него в 60 fps. Конечно, выедает при этом 300%, от этого никуда денешься.
http://www.craftymind.com/factory/guimark2/FlashChartingTest...
http://www.craftymind.com/factory/guimark2/HTML5ChartingTest...
> Поэтому там где Chrome + JS + HTML5 canvas выдаёт 20 fps, упираясь в одно ядроСферичское ядро то? В сферическом же вакууме?
Предупреждать надо.
А то на своём 4к ниже 30фпс не видел.Зыж
А поэтому, чтобы не было такого безобразия (когда без флэша низя. Ещё бывает):
> Flash вытягивает 60. Лимит у него в 60 fps. Конечно, выедает при этом 300%, от этого никуда денешься.Предпочитаю фф. Ибо под линухом он со старым флэшем, который за 1 ядро не вылазит. VDPAU умеет и ладно.
> Сферичское ядро то?А в чём смысл указывать конкретную модель? Свести всё к сравнению у кого проц круче?
Видимо, ты не уловил суть: софт не становится быстрее только от того, что в компиляторе появилась поддержка OpenMP. От того, что ты Firefox пересоберёшь новым clang'ом, он не станет волшебным образом использовать несколько ядер. Для этого надо переосмыслить граф зависимостей.
> Ибо под линухом он со старым флэшем, который за 1 ядро не вылазит.
Проверил специально на 11.2, он тоже умеет в несколько потоков рисовать.
> А в чём смысл указывать конкретную модель? Свести всё к сравнению у кого проц круче?А в чём смысл выковыряных из носа 20фпс?
У меня в 1 поток было всё зашибись, теперь дцать. Напуркуа?
> Видимо, ты не уловил суть: софт не становится быстрее только от того, что в компиляторе появилась поддержка OpenMP.Видимо ты а) плохо воспитан(Ы), б) влез в обсуждение только для того, чтобы влесть, в) и дураку понятно (более того, речь идет как раз о том, что софт будет (суммарно) медленнее. Из-за того, что опенмп будут пихать куда попало, потому что стоимость вхождения резко падает), как результат — если флэш (как пример) стал жрать цпу больше, значит кому-то другому в этот же момент придется жрать меньше (например компиляция), а поскольку не факт кто в конкретный момент победит в конкуренции за порцию ресурсов, то и (например) тиринг не исключен.
Зыж
> Проверил специально на 11.2, он тоже умеет в несколько потоков рисовать.Х/з, у меня в один. И больше 100% (старый флэш в фф) не жрёт.
Тот же контент на хроме (ну или хромиуме с хромовскими плагинами) запросто может сожрать 180% суммарно.
>> А в чём смысл указывать конкретную модель? Свести всё к сравнению у кого проц круче?
> А в чём смысл выковыряных из носа 20фпс?Вот и я про то же. Само по себе число 20 ничего не значит без указания условий получения результата. А вот сравнение чисел 20 и 60 уже вполне имеет значение, о чём я и писал.
Ты сказал, что некоторый софт теперь будет есть больше CPU, приведя в пример Flash. А я говорю, что там _уже_ есть поддержка работы в несколько потоков. Там, где это было возможно, это делают и без OpenMP. Добавление поддержки OpenMP в компилятор не делает последовательный код параллельным. Что тебе ещё не понятно?
> плохо воспитан
Мне вот интересно, а не является ли указание на плохое воспитание признаком плохого воспитания?
> влез в обсуждение только для того, чтобы влесть
Можно сказать, что у тебя прямо была причина посерьёзнее. Ну и льстить я никому пока не собирался.
> Из-за того, что опенмп будут пихать куда попало, потому что стоимость вхождения резко падает), как результат — если флэш (как пример) стал жрать цпу больше, значит кому-то другому в этот же момент придется жрать меньше (например компиляция), а поскольку не факт кто в конкретный момент победит в конкуренции за порцию ресурсов, то и (например) тиринг не исключен.
OpenMP вызывает тиринг? Чудесные умозаключения.
> Х/з, у меня в один
Именно на том тесте проверял?
> может сожрать 180%
Какой смысл покупать процессор, если его не использовать? Мне больше нравится идея race to sleep, пусть на полной скорости сделает работу как можно быстрее, а потом отправляется спать.
Терпеть лаги, когда можно не терпеть — глупо.
> Видимо ты а) плохо воспитан(Ы), б) влез в обсуждение только для того, чтобы влестьОчевидно, нет.
Да? И какова же была цель? Хотя бы одну, для примера.
(Про пункт а) замну пока. Не интересно)
> Да? И какова же была цель? Хотя бы одну, для примера.За человека и его цель говорить не стану, но #8 как минимум для меня оказалось довольно информативным (ну да, чайник я в этих ваших плейерах-веерах).
Давайте всё-таки не спешить подразумевать злонамерение -- на форуме не первый год порой наблюдаются вбросы, которые именно и нацелены людей разругать и рассорить, но нам на такое вестись совершенно ни к чему.
> а поскольку не факт кто в конкретный момент победит в
> конкуренции за порцию ресурсов, то и (например) тиринг не исключен.Это вопросы к планировщику ЦП. Хотя, конечно, если он фиговат, как в Уиндоуз, то лучше оставлять резерв ресурсов ЦП.
20 фпс и там и там на моем ноуте)
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.169http://www.craftymind.com/factory/guimark2/FlashChartingTest...
Test Average: 41.07 fpshttp://www.craftymind.com/factory/guimark2/HTML5ChartingTest...:
Test Average: 56.48 fpsЧто я делаю не так?
Флеш захлебнулся, гона-потоков (Race condition).
> Что я делаю не так?Всё делаешь так. К сожалению, на моём железе Flash всё ещё выдаёт более плавную анимацию.
Ubuntu 14.04, Firefox 38, Flash 11.2Flash
Test Average: 59.82 fpsHTML5
Test Average: 13.78 fps
40 - html550 -flash
html5 56-58 fps
openmp это далеко не единственный способ заметить, что на дворе 2015
> openmp это далеко не единственный способ заметить, что на дворе 2015Да все равно какой способ У меня восьмипотоковый (гипертрейдинг и 4 ядра) и7 проц, а тормозила тормозит. Пусть случится чудо и она сожрет все 4 ядра. И все либы, дрова, прослойки и прочий ливер тоже. Я, за.
> openmp это далеко не единственный способ заметить, что на дворе 2015технически - один из лучших.
для тех, кто никак с С и С++ не слезет в программировании.
>openmp это далеко не единственный способ заметить, что на дворе 2015
Для пользователей mandala, собирающих всё clang - возможно. В нормальных дистрибутивах gcc это делает уже несколько лет.
"наконец-то"
Почему отдельной библиотекой? Почему всё на директивах? Почему нельзя было, например, развить сам язык в эту сторону?, сделать отдельные многопоточные циклы, отдельные векторые типы данных, как в том же GLSL? Это выгладит как подпорка-костыль для немощного языка...
потому что стандарт
Только вот библиотека не оптимизирует это всё так, как мог бы компилятор -> явно упущенный потенциал. В расте распараллеливание реализовано найтивно. По этому пункту он скоро обойдет c++.
Потому что добавить нужную функциональность прагмами проще, чем переделывать ядро языка, и это не ломает совместимость.
Про немощный язык - это вообще пушка. Давайте DSL для разработки интернет-магазинов включим в С, чего уж там. А то немощно как-то.
В том то и дело что он не немощный, и можно было бы переписать ядро. Прагмы сильно усложняют код, делают его не читаемым и легко допустить ошибки в логике.
Я сильно сомневаюсь, что сишники с восторгом восприняли бы идею такого усложнения синтаксиса. Вот в плюсах - да, самое место было бы. Но там, вроде, только футуры.
Си уже давно прекратил развитие, для этого есть с++. Но от тоже, по всей видимости, ступил на этот путь. Вообще не понятно куда всё катится, я лично не вижу сейчас языка на роль универсального современного инструмента. Нигде нет встроенной поддержки гибкой многопоточности типа openmp, поддержки гетерогенных вычислений типа opencl и работы с графикой типа glsl в самом коде программы. И развития в этом направлении никакого.
В пропозалах на C++17, ЕМНИП, есть поддержка векторных переменных и операций с ними, причём достаточно умная, чтобы быть портируемой на разную ширину регистров SIMD.Ну и есть Boost.SIMD.
А что, в Clang до сих пор не было поддержки OpenMP? Я знал, что он отстаёт от GCC, но чтобы настолько...
Кроме OpenMP в мире больше ничего не существует?
Ну, есть ещё Cilk, только вот GCC его тоже умеет.
GCC умеет Grand Central Dispatch?
Эппловский форк GCC умеет. А в линуксе этой хрени нет в принципе, ни в GCC, ни в Clang.
> Эппловский форк GCC умеет. А в линуксе этой хрени нет в принципе,
> ни в GCC, ни в Clang.Не нужно, есть на OpenBSD
Эта хрень в плане производительности и удобства разработки рвет по всем фронтам вышеупомянутый сабж.
> Эта хрень в плане производительности и удобства разработки рвет по всем фронтам
> вышеупомянутый сабж.справедливости ради: рвать она может и рвёт, но давай посмотрим, у скольки проектов она в зависимости. опенмп в шланге - это плюс, как ни крути. что не делает openmp лучше или хуже других либ.
Справедливости ради и сравнение что из них хуже или лучше достаточно бесполезно, все таки инструмент выбирается в зависимости от задачи. Я лично ничего против OpenMP не имею и комментарии выше написал лишь как ответ анонимусу за нелестное высказывание в сторону GCD, а так я полностью согласен с вами.
> Я лично ничего против OpenMP не имею и комментарии выше написал лишь
> как ответ анонимусу за нелестное высказывание в сторону GCDТехнически говоря, #9 (на которое отвечали в #12) таковым не было.
А что не так в #12 ?
Вполне нейтрально и хренью ничего не называю, так что технически говоря там все нормально.
Я может чего-то не понимаю?
Только в отдельной ветви, причем, отстающей. Пока поддержка силка не будет обеспечена стабильно, толку от нее нет.
С нетерпением жду бенчев на Фурониксе!
1. Скорость копирования файлов утилитами, скомпилированными гцц и шлангом.
2. Скорость загрузки убунты и <BSDя или открытая мандрива>
Настоятельно советую эксперту-бенчмаркиру Михаилу запускать тесты с шлангом на любимом Xeone, а отсталый гцц влепить на старенький ноут (но не наоборот!)
если головой или ручками нормально программу ненапишешь, никакие быблобиблиотеки непомогут тому, что в итоге получилось, работать качественно, а не забивать все ядра потоком разннобразного мусора и хлама, при мизерном результате на выхлопе.
OpenMP - костыль для тех, кто сам не может написать нормальный параллельный код, или для тунеядцев, которые не хотят писать нормальный параллельный код.
Распараллеливание множества мелких циклов через OpenMP вряд ли даст существенное ускорение, а вот энергопотребление увеличит на порядок.
А компьютер вообще сделан для тех, кто не может посчитать на бумажке. Но вам же неважно, что на бумажке долго и большой шанс ошибиться - главное, что не тунеядцы.А так - оно в GCC сто лет как есть, в проприетарных компиляторах - тоже. Все, кому нужно - давно пользуются.
то есть для 98% разработчиков.
"паралельный" код в рамках С/С++ писать трудно В ПРИНЦИПЕ.
а мигрировать на другое - никто почти не хочет или готов.
OpenMP один из лучших. и уж точно среди комьюнити-пилимых - Самый.
> OpenMP один из лучшихЭто единственное средство быстро и просто распараллелить циклы. Только вот реализация библиотекой, а не в ядре языка, такой востребованной в наше время функции выглядит по меньшей мере странно. Они сразу усложняет дебаг и профилировку, а качество распараллеливания зависит уже не от компилятора, который постоянно усовершенствуется, а от какой-то библиотеки, которую надо ставит и обновлять, и которая не гарантирует правильную и оптимальную работу в любой системе на любом оборудовании.
> OpenMP - костыль для тех, кто сам не можетвсегда считал возможность использовать сторонние открытые библиотеки сильной стороной опенсорса. а оно вна как - каждый должен написать софт, начиная с загрузчика и заканчивая собственно прикладухой. вот это поворот (с)
Это так, только не в таких фундаментальных вещах как многопоточность и гетерогенные вычисления. Всё это должно быть в ядре любого современного языка системного уровня.
> Это так, только не в таких фундаментальных вещах как многопоточность и гетерогенные
> вычисления. Всё это должно быть в ядре любого современного языка системного
> уровня.вопрос в удобстве, простоте и прочих весьма субьективных вещах. ну не запретишь ты писать 10 библиотек jpeg, png и прочих, вплоть до самых низкоуровневых.
В язык ничего добавлять больше не хотят? Теперь всё дополнительное будет на костылях? Значит пора делать новый Си с тремя плюсами, который будет найтивно поддерживать многопоточные циклы, векторные типы и найтивную работу с любым оборудованием, включая видео.
Скоро все на прагмах писать будут.
OpenMP-ветвь Clang'а существует уже давно, в чем новость? Неужели его добавили в основную ветку? В какой версии он будет доступен?
Надеюсь в следующем стандарте это всё реализуют непосредственно в языке
5 лет ждали, ну наконец-то.