В наши дни для параллельного программирования есть две основные аппаратные среды: один - многопоточный процессор, а другой - графические карты, которые могут выполнять параллельные операции с массивами данных.
Вопрос: учитывая, что существуют две разные аппаратные среды, как я могу написать программу, которая является параллельной, но независимой от этих двух разных аппаратных сред. Я хочу сказать, что я хотел бы написать программу, и независимо от того, есть ли у меня видеокарта или многопоточный процессор или и то, и другое, система должна автоматически выбирать, на что ее можно запускать, либо на обеих графических картах, либо на многопоточном процессоре.Существуют ли какие-либо программные библиотеки/языковые конструкции, которые позволяют это?
Я знаю, что есть способы настроить таргетинг на графическую карту напрямую, чтобы запустить код, но мой вопрос в том, как мы можем программисты писать параллельный код, не зная ничего о аппаратном обеспечении, и система программного обеспечения должна планировать ее либо на графической карте, либо на ЦП.
Если вы хотите, чтобы я был более конкретным относительно платформы/языка, я бы хотел, чтобы ответ был о С++ или Scala или Java.
Спасибо
Исследовательская группа Martin Odersky в EPFL недавно получила грант Европейского исследовательского гранта на миллион евро, чтобы ответить именно на этот вопрос. (Статья содержит несколько ссылок на документы с более подробной информацией.)
Через несколько лет программы будут перезаписываться с нуля во время выполнения (эй, почему бы и нет?)...
... по состоянию на данный момент (насколько мне известно) он может быть нацелен только на целевые группы параллельных систем с заданными парадигмами, а графический процессор ( "смущающий параллель" ) существенно отличается от "обычного" ЦП ( 2-8 "нитей" ) существенно отличается от суперкомпьютера процессора 20 тыс..
Фактически существуют параллельные промежутки времени/библиотеки/протоколы, такие как Charm ++ или MPI (думаю, "Актеры" ), которые могут масштабироваться - с помощью специально спроектированных алгоритмов для определенных задач - от одного процессора до десятков тысяч процессоров, поэтому выше это немного гипербола. Однако существуют огромные фундаментальные различия между графическим процессором или даже Cell microrocessor - и гораздо более универсальным процессором.
Иногда квадратная привязка просто не вписывается в круглое отверстие.
Счастливое кодирование.
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).
Недавно анонсированный MS С++ AMP выглядит так, как вы. Кажется (от чтения новостных статей), что вначале он нацелен на использование графических процессоров, но долгосрочная цель, похоже, состоит в том, чтобы включать многоядерные ядра.
Конечно. См. ScalaCL для примера, хотя он все еще является альфа-кодом на данный момент. Также обратите внимание, что он использует некоторые библиотеки Java, которые выполняют одно и то же.
Я расскажу о более теоретическом ответе.
Различные параллельные аппаратные архитектуры реализуют различные модели вычислений. Мосты между ними сложны.
В последовательном мире мы с радостью взломали в основном одну и ту же единую модель вычислений: машину произвольного доступа. Это создает хороший общий язык между разработчиками программного обеспечения и разработчиками программного обеспечения.
Нет такой единой оптимальной модели для параллельных вычислений. С самого начала современных компьютеров было исследовано большое пространство для проектирования; текущие многоядерные процессоры и графические процессоры покрывают небольшую часть этого пространства.
Преодоление этих моделей сложно, потому что параллельное программирование в основном связано с производительностью. Обычно вы делаете что-то по двум различным моделям или системам, добавляя слой абстракции, чтобы скрыть специфику. Однако редко бывает, что абстракция не связана с производительностью. Это, как правило, приземляет вас с более низким общим знаменателем обеих моделей.
И теперь отвечая на ваш реальный вопрос. Наличие вычислительной модели (языка, ОС, библиотеки,...), которая не зависит от процессора или графического процессора, обычно не будет абстрагироваться по сравнению с обоими, сохраняя при этом полную мощность, с которой вы привыкли с вашим ЦП, из-за штрафов за производительность. Чтобы все было относительно эффективно, модель будет склоняться к графическим процессорам, ограничивая то, что вы можете делать.
Серебряная подкладка:
Что происходит, так это гибридные вычисления. Некоторые вычисления более подходят для других архитектур. Вы также редко выполняете только один тип вычислений, так что "достаточно умный компилятор/время выполнения" сможет различать, какая часть ваших вычислений должна выполняться в какой архитектуре.