Intel® Graphics Technology. Часть II: «выгружаем» вычисления на графику

[Imp5]

Хотелось бы ещё узнать про накладные расходы.
Начиная с каких объёмов это будет быстрее чем на CPU?

[ivorobts]

Понятно что оверхед есть при копировании из памяти в память. При использовании общей памяти он не такой существенный, а распределение нагрузки возложено на планировщик от Cilk'а.
Здесь сложно дать конкретную оценку, но задача должна быть не очень «тяжелой» для графики.
Результаты по производительности у меня есть, они однозначно говорят о том, что работает с оффлоадом быстрее, причем в разы, но всё зависит от алгоритма и того, как написан код (попадание в кэши и т.д.). Возможно, я раскрою ещё больше деталей в дополнительном посте о том, как сделать именно эффективный оффлоад. Здесь я только знакомил с технологией.

[Jeditobe]

Это вообще быстрей чем на CPU? Особенно если учесть, что Интеловская графика не очень то и быстрая.

[ivorobts]

Это на ряде задач существенно быстрее чем только на CPU.

[vpolin]

Я советую посмотреть на пример NBODY, чтобы самому сравнить, что где быстрее.

[mezastel]

Когда Intel C++ начнет поддерживать C++ AMP?

[vpolin]

Я про планы не могу ничего сказать, но уже сейчас интеграция в студию достаточно хорошо дружит со студийным компилятором. У меня, например, есть тестовый пример, где весь проект, за исключением исходника с С++АМР кодом, компилируется Intel C++, а исходник с С++АМР кодом компилируется студийным компилятором. Поскольку студийный рантайм один, всё замечательно уживается.

[mezastel]

Это-то сработает, но что насчет запуска на Linux?

[vpolin]

Для кроссплатформенности у нас есть Cilk Plus. Он на линуксе тоже работает.

[vpolin]

Интересный момент заключается в том, что по умолчанию установленный компилятор найти gfx_rt.h не смог – пришлось прописать путь к его папочке (C:\Program Files (x86)\Intel\Composer XE 2015\compiler\include\gfx в моём случае) ручками в настройках проекта.

Надо не просто gfx_rt.h подключать, а gfx/gfx_rt.h. Тогда ничего прописывать не надо.