OpenCL: хорошо ли он работает с OpenMP, могу ли я подключить к нему другие языки и т. Д.

Спецификация 1.0 для OpenCL только что вышла несколько дней назад (Spec здесь ), и я только начал ее читать. Я хочу знать, хорошо ли он работает с другими высокопроизводительными многопроцессорными API, такими как OpenMP ( spec ), и хочу узнать, что мне следует изучить. Итак, вот мои основные вопросы:

  1. Если я уже использую OpenMP, это сломает OpenCL или наоборот?
  2. Является ли OpenCL более мощным, чем OpenMP? Или они предназначены для дополнения?
  3. Существует ли стандартный способ подключения программы OpenCL к стандартной программе C99 (или любому другому языку)? Что это?
  4. Кто-нибудь знает, пишет ли кто-нибудь книгу OpenCL? Я читаю спецификацию, но нашел книги более полезными.
10.12.2008 14:50:55
4 ОТВЕТА
  1. ?
  2. ?
  3. OpenCL должен быть написан непосредственно на C99 afaik? В любом случае, для него теперь доступны заголовочные файлы.
  4. ?
0
19.12.2008 08:51:56

OpenMP и OpenCL различны, но могут быть настроены для совместной работы. Ни один из них не должен «сломать» другого.

В качестве аргумента давайте предположим, что существует компромисс между минимизацией изменений в существующей кодовой базе и производительностью или вычислительной мощностью. OMP «легок» в том смысле, что вы можете применить его «волшебным образом» к смущающе параллельным проблемам с быстрой прагмой или двумя.

OpenCL представляет совершенно новые концепции высокого уровня, выходящие за рамки типичных моделей потоков ОС. Хронос, вероятно, не хочет говорить это вслух, но его происхождение находится в CUDA от NVIDIA. Если вы хотите посмотреть, как это работает сегодня, загрузите CUDA SDK и начните играть. Если у вас нет графических процессоров NVIDIA, не волнуйтесь, есть вариант программного обеспечения для GPU-эмулятора. OpenCL - это удобная абстракция графического процессора, которая должна применяться к процессорам, DSP, «ускорителям» (псевдоним Khronos для IBM CellBE и, вероятно, Intel Larrabee).

OpenCL не должен быть «написан непосредственно на C99». Он называется расширением C99, поскольку его синтаксис аналогичен / идентичен C99 с некоторыми новыми ключевыми словами. Вы не можете вызвать libc (или любую другую библиотеку) из ядра.

Вы можете использовать и то и другое, но теоретически OpenCL должен быть «лучше» (в том смысле, что он переносим на большее количество вычислительных устройств), если вы хотите портировать свой код. Вы не можете использовать прагмы OpenMP в ядре OpenCL.

Смотрите также:

7
7.01.2009 05:40:30

По большей части OpenMP и OpenCL независимы друг от друга. Оба эти способа предоставляют разработчику доступ к параллелизму на их платформе.

OpenMP хорошо работает с несколькими (одинаковыми) процессорами, где примерно одинаковая работа может (почти) автоматически распределяться между ними.

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

Тем не менее, я предполагаю, что это будет несколько сложно, хотя определенно не невозможно заставить OpenMP и OpenCL работать вместе в одной и той же проблеме.

Первое, о чем нужно подумать, это то, что вы делаете для OpenCL. Это определенно тот случай, когда вы бы хотели, чтобы OpenCL работал только на GPU / Co-процессор ... не на других основных процессорах / ядрах, поскольку OpenMP уже использует их. Это не будет (не должно) вызывать ошибки приложения для запуска OpenCL и OpenMP на одном и том же главном процессоре, но это приведет к нежелательному планированию, когда и OpenMP, и OpenCL работают медленнее, потому что они тратят значительную часть своего времени на переключение обратно и четвертый между собой. Это также может произойти, если вы одновременно запустите любой процесс, требующий ресурсов процессора, на том же ядре.

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

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

Удачи!

4
23.03.2009 14:30:44

Кстати, есть работа с openMp для gpgpu с использованием CUDA.

0
21.06.2012 18:34:23