Как сделать аппаратное независимое параллельное программирование?

В наши дни для параллельного программирования есть две основные аппаратные среды: один - многопоточный процессор, а другой - графические карты, которые могут выполнять параллельные операции с массивами данных.

Вопрос: учитывая, что существуют две разные аппаратные среды, как я могу написать программу, которая является параллельной, но независимой от этих двух разных аппаратных сред. Я хочу сказать, что я хотел бы написать программу, и независимо от того, есть ли у меня видеокарта или многопоточный процессор или и то, и другое, система должна автоматически выбирать, на что ее можно запускать, либо на обеих графических картах, либо на многопоточном процессоре.

Существуют ли какие-либо программные библиотеки/языковые конструкции, которые позволяют это?

Я знаю, что есть способы настроить таргетинг на графическую карту напрямую, чтобы запустить код, но мой вопрос в том, как мы можем программисты писать параллельный код, не зная ничего о аппаратном обеспечении, и система программного обеспечения должна планировать ее либо на графической карте, либо на ЦП.

Если вы хотите, чтобы я был более конкретным относительно платформы/языка, я бы хотел, чтобы ответ был о С++ или Scala или Java.

Спасибо

Ответ 1

Исследовательская группа Martin Odersky в EPFL недавно получила грант Европейского исследовательского гранта на миллион евро, чтобы ответить именно на этот вопрос. (Статья содержит несколько ссылок на документы с более подробной информацией.)

Ответ 2

Через несколько лет программы будут перезаписываться с нуля во время выполнения (эй, почему бы и нет?)...

... по состоянию на данный момент (насколько мне известно) он может быть нацелен только на целевые группы параллельных систем с заданными парадигмами, а графический процессор ( "смущающий параллель" ) существенно отличается от "обычного" ЦП ( 2-8 "нитей" ) существенно отличается от суперкомпьютера процессора 20 тыс..

Фактически существуют параллельные промежутки времени/библиотеки/протоколы, такие как Charm ++ или MPI (думаю, "Актеры" ), которые могут масштабироваться - с помощью специально спроектированных алгоритмов для определенных задач - от одного процессора до десятков тысяч процессоров, поэтому выше это немного гипербола. Однако существуют огромные фундаментальные различия между графическим процессором или даже Cell microrocessor - и гораздо более универсальным процессором.

Иногда квадратная привязка просто не вписывается в круглое отверстие.

Счастливое кодирование.

Ответ 3

OpenCL - это точно о том, как работать с одним и тем же кодом на процессорах и графических процессорах на любой платформе (Cell, Mac, PC...).

Из Java вы можете использовать JavaCL, который представляет собой объектно-ориентированную оболочку вокруг API OpenCL C, которая сэкономит вам много времени и усилие (обрабатывает распределение памяти и нагрузку на преобразование и поставляется с некоторыми дополнительными функциями).

Из Scala, ScalaCL, который основывается на JavaCL, чтобы полностью скрыть язык OpenCL: он преобразует некоторые части вашего Scala в код OpenCL во время компиляции (для этого требуется плагин компилятора).

Обратите внимание, что Scala содержит параллельные коллекции как часть стандартной библиотеки с 2.9.0, которые можно использовать довольно похожим образом на параллельные коллекции ScalaCL OpenCL (Scala параллельные коллекции могут быть созданы из регулярных коллекций с .par, а параллельные коллекции ScalaCL создаются с помощью .cl).

Ответ 4

Недавно анонсированный MS С++ AMP выглядит так, как вы. Кажется (от чтения новостных статей), что вначале он нацелен на использование графических процессоров, но долгосрочная цель, похоже, состоит в том, чтобы включать многоядерные ядра.

Ответ 5

Конечно. См. ScalaCL для примера, хотя он все еще является альфа-кодом на данный момент. Также обратите внимание, что он использует некоторые библиотеки Java, которые выполняют одно и то же.

Ответ 6

Я расскажу о более теоретическом ответе.

Различные параллельные аппаратные архитектуры реализуют различные модели вычислений. Мосты между ними сложны.

В последовательном мире мы с радостью взломали в основном одну и ту же единую модель вычислений: машину произвольного доступа. Это создает хороший общий язык между разработчиками программного обеспечения и разработчиками программного обеспечения.

Нет такой единой оптимальной модели для параллельных вычислений. С самого начала современных компьютеров было исследовано большое пространство для проектирования; текущие многоядерные процессоры и графические процессоры покрывают небольшую часть этого пространства.

Преодоление этих моделей сложно, потому что параллельное программирование в основном связано с производительностью. Обычно вы делаете что-то по двум различным моделям или системам, добавляя слой абстракции, чтобы скрыть специфику. Однако редко бывает, что абстракция не связана с производительностью. Это, как правило, приземляет вас с более низким общим знаменателем обеих моделей.

И теперь отвечая на ваш реальный вопрос. Наличие вычислительной модели (языка, ОС, библиотеки,...), которая не зависит от процессора или графического процессора, обычно не будет абстрагироваться по сравнению с обоими, сохраняя при этом полную мощность, с которой вы привыкли с вашим ЦП, из-за штрафов за производительность. Чтобы все было относительно эффективно, модель будет склоняться к графическим процессорам, ограничивая то, что вы можете делать.

Серебряная подкладка:
Что происходит, так это гибридные вычисления. Некоторые вычисления более подходят для других архитектур. Вы также редко выполняете только один тип вычислений, так что "достаточно умный компилятор/время выполнения" сможет различать, какая часть ваших вычислений должна выполняться в какой архитектуре.