Для каких типов доменов кода подходит OpenCL?

Я прочитал обзор OpenCL, и в нем говорится, что он подходит для кода, который работает на процессорах, GPGPU, DSP и т. Д. Однако, просматривая справочник по командам, кажется, что это все математические операции и операции с изображениями. Я не видел ничего для строк.

Это заставляет меня задаться вопросом, что будет работать на процессоре через OpenCL?

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

РЕДАКТИРОВАТЬ Я заметил, что грядущий Intel Ivy Bridge рекламируется как «совместимый с OpenCL» со ссылкой на его графические блоки. Означает ли это, что ядра ЦП несовместимы с OpenCL, или такого вывода нет?

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


parallel-processing cpu opencl gpgpu heterogeneous
person IamIC    schedule 30.01.2012    source источник
comment
Кто говорит, что графический процессор Intel Ivy Bridge совместим с OpenCL, и что означает совместимость с OpenCL? Процессоры Intel поддерживают OpenCL с помощью Intel OpenCL SDK.   -  person vocaro    schedule 31.01.2012

Ответы (3)


arrow_upward
1
arrow_downward

Вы можете думать об OpenCL как о комбинации среды выполнения (для обнаружения устройств, постановки в очередь) и языка программирования на основе C. Этот язык программирования имеет собственные векторные типы и встроенные функции и операции для выполнения всевозможных забавных действий с этими векторами. Это хорошо тем, что вы можете написать векторизованное ядро ​​​​в OpenCL, и реализация отвечает за сопоставление этого с фактическим векторным ISA вашего оборудования.

Из этого 4/2011 статья, которая может исчезнуть:

Существуют две основные архитектуры ЦП, x86 и ARM, обе из которых вскоре должны запускать код OpenCL.

Если вы пишете приложение OpenCL, предназначенное для обеих этих архитектур, вам не придется беспокоиться о написании двух версий, одной SSE и одной NEON. Просто напишите OpenCL C и покончим с этим. Да, я знаю. Это предполагает, что поставщик выполнил свою работу и написал надежную реализацию, которая полностью использует лежащую в основе ISA. Но если он этого не сделает, жалуйтесь!

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

person James    schedule 31.01.2012

arrow_upward
1
arrow_downward

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

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

person onit    schedule 30.01.2012
comment
Это имеет смысл. Вы хоть представляете, какой код OpenCL можно было бы запустить на процессоре? Мне это кажется непрактичной идеей. - person IamIC; 30.01.2012
comment
Мой опыт работы с GPGPU обычно связан с CUDA. Насколько я понимаю, OpenCL просто пытается предоставить платформу, которая упрощает написание многопоточного кода, независимо от архитектуры. Некоторые многопоточные приложения, такие как алгоритм веб-сервера, создающий страницы с динамическим контентом, могут не подходить для GPGPU по причинам, которые я изложил в своем посте. Хотя я понятия не имею, на какой тип проектов в настоящее время нацелен OpenCL. - person onit; 30.01.2012
comment
OpenCL не является способом реализации многопоточности. В OpenCL есть рабочие элементы, которые должны выполнять одни и те же вычисления с разными фрагментами данных, но не могут обмениваться данными, и, вероятно, не все они выполняются одновременно. - person Steve Blackwell; 31.01.2012
comment
@SteveBlackwell Возможно, слово «многопоточность» было неправильным, поскольку оно может подразумевать традиционную модель многопоточности ЦП. Из того, что я видел в OpenCL, он копирует многие модели потоков CUDA и идею, что каждая задача выполняется в отдельном потоке в ядре, что я и имел в виду. Я мог бы сказать, что он выполняет многопроцессорную обработку, чтобы быть более точным, но лично я думаю, что это сбивает с толку, потому что CUDA относится к единицам работы как к потокам. Насколько я понимаю, рабочий элемент OpenCL - это то же самое, что и поток CUDA. - person onit; 31.01.2012
comment
@onit Эти две концепции очень похожи, но я думаю, что рабочие элементы OpenCL немного урезаны. Например, CUDA может вызывать глобальный барьер для синхронизации всех потоков, а OpenCL не может. CUDA также позволяет динамическое выделение памяти в ядре, а OpenCL — нет. Так что да, это просто вопрос терминологии SIMD (OpenCL мог бы также называть их потоками), но я думаю, что это некоторые важные различия, когда дело доходит до написания ядра. - person Steve Blackwell; 31.01.2012
comment
@SteveBlackwell В CUDA нет глобального барьера для синхронизации всех потоков. Вы можете синхронизировать все потоки в блоке, что будет синхронизировать все потоки, работающие на одном процессоре (т. е. все потоки, работающие в блоке, выполняются на одном ядре графического процессора). Однако синхронизация всех потоков в ядре невозможна, если вы не выйдете из ядра и не выполните внешнюю синхронизацию, что также возможно в OpenCL. Кроме того, динамическое выделение памяти является относительно новой функцией CUDA и может быть реализовано в OpenCL в будущем, хотя на обеих платформах это приведет к снижению производительности. - person onit; 31.01.2012

arrow_upward
1
arrow_downward

Это заставляет меня задаться вопросом, что бы вы запускали на процессоре через OpenCL?

Я предпочитаю использовать ocl для переноса работы с процессора на графическое оборудование. Иногда у моей видеокарты есть ограничения, поэтому мне нравится иметь резервное ядро ​​для использования процессором. Такими ограничениями могут быть размер памяти, узкое место в памяти, низкая тактовая частота или когда мешает шина PCI-E.

Я говорю, что мне нравится использовать отдельное ядро ​​для процессора, потому что я думаю, что все ядра должны быть настроены для работы на целевом оборудовании. Мне даже нравится иметь план резервного копирования openmp, так как большинство алгоритмов, которые я использую, тестируются таким образом заранее.

Я полагаю, что лучше всего протестировать ядро ​​​​gpu на процессоре, чтобы убедиться, что оно работает должным образом. Если у пользователя вашего программного обеспечения установлен opencl, но только процессор (или младшая видеокарта), приятно иметь возможность выполнять один и тот же код на разных устройствах.

person mfa    schedule 31.01.2012