Об Intel ISPC

Интел выкатил в опенсорс такую вот игрушку: Intel SPMD Program Compiler.

Это очередная попытка придумать параллельный язык C: пишете некую функцию, к примеру, обрабатывающую элемент данных, варез сам строит SIMD-представление (SSE, AVX), которое обрабатывает 4(8) элементов за раз. Ну как-то так:

И оно у вас пойдет фигачить шириной programCount, ну там дальше надо будет элементы out просуммировать уже снаружи.

Примеры (из поставки), надо сказать, впечатляют, там действительно генерируется код, который быстрее компиляторного (из того же C++ кода) в разы. Ну и собственноручно сделанные простые примеры тоже вполне внушают оптимизм, сгенерированный код всяко не хуже ручного SSE (там, где работает логика параллельного исполнения нескольких копий функции; скалярное произведение до соответствующей встроенной команды оно оптимизировать не смогло).

Но возникает сразу много мелких но, которые сильно уменьшают полезность:

• Авторам тулзы пришлось делать спецификаторы "постоянства" переменной между разных инстансов SIMD-программы. Да, все понятно, без этого при параллельном исполнении никак не выйдет, только эта фишка тут же бъет по пальцам:
• Встроенные типы - только 32- и 64-битные int и float. Работа с 16-битными целыми данными (а у меня картинки, да) превращается в ужоснах: вроде есть встроенные функции загрузки 8- и 16-битных данных, но выясняется что дать им varying-адрес (т.е. разный в каждом SIMD-потоке) не получится т.е. загрузить свое значение в каждом потоке просто нельзя. Что-то по константному адресу прочитать - это пожалуйста.
• Вся конструкция очень хрупкая, пока я преодолевал (безуспешно) предыдущее ограничение - у меня компилятор чаще падал, чем работал. Ну, пофиксят со временем.
• Ну и все это - только на одном ядре. Для распараллеливания по ядрам нужен какой-то внешний планировщик (в примерах - есть такой пример). Делать это через OpenMP я не пробовал, попробую.

Вместе с тем, результат на родных примерах отличный: в один поток получается в 3-4 раза быстрее, чем то что интеловский компилятор генерирует из примерно того же кода. На всех ядрах Mandelbrot в 13 раз быстрее, чем однопоточный код из компилятора.

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

• На видеокарте пойдет (с какой скоростью - вопрос, но пойдет).
• На многих ядрах - тоже пойдет.

Получается, место ISPC - точечные оптимизации в достаточно тривиальных местах (где, к примеру, не нужно скалярного произведения или транспонирования матрицы 4x4 сделанной на 4-х XMM-регистрах), там где я до этого использовал OpenMP + ручной SSE-код. Возможно, писать на этом псевдо-C будет быстрее. Особенно в случаях, когда есть ветвления, выписывать их вручную всегда мучительно, а тут оно как-то само. А вот там, где объем работы большой и может окупить пересылку на GPU и обратно - там лучше, наверное, OpenCL.

P.S. AVX-кодогенератора пока нет, обещают.