Для ясности — директива pragma simd, с июля этого года часть стандарта OpenMP 4.0 (pragma omp simd), а значит никакой привязки к компилятору. Синтаксис для работы с массивами — так же часть этого стандарта (Array Sections).
Собственно, как мы видим, всё это весьма быстро переходит из частного для компилятора Intel в общее для всех, ввиду распространенности OpenMP и явного стремления того же gcc его поддерживать.
«начиная с Inte® Cilk™ Plus у вас появляется ситуация, когда программа есть, а запустить вы её не можете вообще.»
Это весьма странное утверждение, потому что мы всегда можем сгенерировать дефолтную ветку с поддерживаемыми инструкциями на всех и не «интеловских» процессорах. Хотелось бы понять, что вкладывается в «вообще»?
Так про то и разговор. А компилятор даёт более универсальное решение, и мы стараемся как можно сильнее минимизировать разницу между написанием кода на чистых интринсиках и тем, что выдаёт компилятор. Вот только речь не об автовекторизации, а о векторизации, контролируемой разработчиком. Кроме того, ещё и о специальном синтаксисе, при использовании которого вы гарантированно получите векторный код. Раньше таких гарантий компилятор не давал. Вот и вопрос встаёт, насколько вам критично получать дополнительный прирост производительности от более тонкого написания кода на интринсиках, и последующего его переписывания при выходе новых наборов инструкций, или же написать код, который точно будет векторизован сейчас и на всех последующих архитектурах. Скажу сразу, что есть организации, и их не так уж и мало, которые выбрали и выберут интринсики. Но для большинства это будет лишними «расходами».
Кстати, изменения эти будут затрагивать вас всё чаще и чаще, потому фокус и смещается от интринсиков к компилятору. Хотя до сих пор, чтобы получить максимальную производительность, лучше использовать интринсики, весь вопрос в целесообразности.
По поводу роста раз в 8 лет — это долго на SSE «топтались», уже значительно быстрее. Скажем, посмотрите на рост с 256 до 512. И, как уже было сказано, это не единственный плюс. Для каких то простых алгоритмов — возможно. Но речь то в целом не об этом. Давайте вы будете писать код на темплейтах с интринсиками, а я векторизую цикл через прагму, и сравним время, которое мы затратим на это. Кроме того, ещё и уровень опыта, предъявляемый к разработчику. Ну и будущие изменения в коде, которые так или иначе, затронут вас.
Григорий, отличный комментарий. Действительно, этого свойства почти нет у современных моделей параллельного программирования, у Силка же оно имеется исторически, с первых реализаций.
Всё несколько сложнее. В международной компании учитываются нормы не только Российского права. И если у нас в стране указывать данные знаки возможно не обязательно, то в других очень даже. И потом, я не думаю, что это уж так сильно раздражает. А если на кого-то и имеет такое влияние, так это тоже неплохо, по крайней мере, пост запомнится, ведь любая эмоция — это хорошо. Плохо когда её нет.
Ну это риторический вопрос. Они же получают за что-то зарплату. А если серьёзно, то есть набор правил (внутренних), которых нужно придерживаться при публикации с использованием брэнда Intel, и различных торговых марок. Cilk одна их них.
В последней версии Composer XE 2013 SP1 Update 1 (он же 14.0.1) уже ряд «фич», в частности pragma simd и поддержка директив для ускорителей. Но ещё не всё, над этим идёт работа. Есть интересная статья, которая ответит на то, что уже поддерживаем, причем относительно давно (с версии компилятора 13.1)
У меня где то был пример написания программы на OpenMP и OpenCL, так вот версия OpenCL раза в 3-4 больше. Собственно, то о чем уже написал 0serg. По поводу скорости, равно как и поддержки устройств, я думаю это вопрос времени. Много заинтереcованных сторон в OpenMP.
Спасибо за отличный вопрос! Нет, результат будет рандомный, атомарности нет. Кстати, приоритетов потоков тоже нет. Здесь речь о MPI процессах — копиях приложения. Для получения 4000, придётся самому вводить критическую секцию (тоже часть Coarray), примерно так:
critical
do x = 1, 1000
fact[1] = fact[1] + 1
end do
end critical
sync all
Да, всё верно. Сумбурный набор ключей был и в Интеловском компиляторе ранее, и часть из них осталась до сих пор. Но рекомендуется использовать именно fp-model. Кстати, совместимость компиляторов на уровне ключей есть (с Майкрософтом), но эффект несколько иной — нужно быть аккуратным.
Ну, так и есть. Две детали сами на картинке не появлялись… они всё чаще на дороге внезапно «рисуются» :) Но могу признаться, этим «чудом» со мной поделились коллеги, сам я никого не прилеплял.
Собственно, как мы видим, всё это весьма быстро переходит из частного для компилятора Intel в общее для всех, ввиду распространенности OpenMP и явного стремления того же gcc его поддерживать.
«начиная с Inte® Cilk™ Plus у вас появляется ситуация, когда программа есть, а запустить вы её не можете вообще.»
Это весьма странное утверждение, потому что мы всегда можем сгенерировать дефолтную ветку с поддерживаемыми инструкциями на всех и не «интеловских» процессорах. Хотелось бы понять, что вкладывается в «вообще»?
http://software.intel.com/en-us/articles/openmp-40-features-in-intel-fortran-composer-xe-2013
Сейчас поддержка только увеличилась.