Анонсировано (http://openmp.org/wp/2011/07/openmp-31-specification-released/) принятие финального варианта открытой спецификации OpenMP 3.1 (http://openmp.org/wp/openmp-specifications/), выступающей в роли стандарта, определяющего API и способы задействования методов параллельного программирования для языков Си, Си++ и Фортран. Прошлый вариант спецификации OpenMP 3.0 был выпущен три года назад.
Выпуск OpenMP 3.1 в основном носит корректирующих характер и устраняет всплывшие за последние годы недоработки. Тем не менее в обновленном вариант спецификации представлено несколько полезных новшеств, добавленных в угоду пожеланий представителей сообщества. Например, в спецификацию включена реализация предопределенных операторов редукции min и max, а также добавлены расширения для атомарных конструкций (блок atomic), позволяющих захватить или вывести значение совместно используемой переменной, которая обновляется внутри конструкции, без её предварительного чтения. Из других расширений отме...URL: http://software.intel.com/en-us/blogs/2011/07/10/openmp-31-a.../
Новость: http://www.opennet.me/opennews/art.shtml?num=31153
"Что касается будущего стандарта OpenMP 4.0, наиболее привлекательными новшествами в нем станет поддержка ускорения за счет привлечения мощностей GPU, значительные улучшения в модели выполнения задач, добавление механизмов обработки ошибок и поддержка определенных пользователем редукций."Интересно каким образом?
Какая, каким интересует?
- Поддержка ускорения за счет привлечения мощностей GPU ?
- улучшения в модели выполнения задач?
- добавление механизмов обработки ошибок?
- поддержка определенных пользователем редукций?
> Какая, каким интересует?
> - Поддержка ускорения за счет привлечения мощностей GPU ?
> - улучшения в модели выполнения задач?
> - добавление механизмов обработки ошибок?
> - поддержка определенных пользователем редукций?скорее
- Поддержка ускорения за счет привлечения мощностей GPUчерез какое место это они обеспечат? через стандарт на бумаге или всех в кучу опять грести начнут...
вот-вот еле OpenCL сбили в купу с вытекающими глюками, то у одних (ATI) как-то не так работает, то у других (Nvidia) за третьих (Intel) я вообще молчу...вот и возник вопрос "как?"
у эпловцев там еще одно чудо GCD в этом же направлении (распараллеливания) короче расплодили, что для прикладных задач оно не годно, разве только для академических...
короче кругом одни нестыковочки между стандартами...
Ну а почему бы не объединить OpenCL и OpenMP.
Ведь эти обе хреновины всего лишь API, т.е. некий стандарт.
Программить-то все равно придётся человеку.
> Ну а почему бы не объединить OpenCL и OpenMP.
> Ведь эти обе хреновины всего лишь API, т.е. некий стандарт.
> Программить-то все равно придётся человеку.я это понимаю, но обеспечивать это (в соответствии стандарта) должны: ядро ОС (как минимум)+компилятор и драйвер для GPU (как максимум)
первое уже давно вродь как делает это, даже не на уровне алгоритма, а на уровне опций компилятора (как пример http://gcc.gnu.org/wiki/Graphite -floop-parallelize-all -ftree-parallelize-loops=n) может распараллелить в воответствии с целью параллелизма выполнения...
а вот дрова за столько лет так и не наблизились к этому на достаточном для повседневного использования уровне... всё заканяивается только демками на ютубе... а уже на моей памяти лет 5 прошло так точно...как-то так... :(
> почему бы не объединить OpenCL и OpenMPНеплохо было бы! А то OpenMP был для CPU, а хотят добавить GPU. А OpenCL с прицелом для GPU, но и CPU может исплользовать. Этак можно написать одну прогу, которая через OopenMPI разбросается по хостам, а там мат. рассчёты через OpenMP по ядрам CPU&GPU, а мат.рассчёты для визуализации через OpenCL по граф.чипам, чтобы напрямую выводить в OpenGL. А если построить кластер на APU..... Эх, заживут фаны числодробления!
OpenCL и GCD вообще разного поля ягоды и предназначены для разного.