Будущее OpenCL?

Парадигма программирования OpenCL обещает быть открытым стандартом для разнородных вычислений. Должны ли мы инвестировать наше время в разработку программного обеспечения на основе OpenCL? За и против?

Вопрос слишком широкий и расплывчатый, чтобы на него действительно можно было ответить. Тем не менее, я вижу одну заметную точку зрения на OpenCL с точки зрения научных вычислений, которая редко подчеркивается. До сих пор не было никаких усилий по созданию инфраструктурных библиотек с открытым исходным кодом для OpenCL, тогда как у CUDA есть несколько превосходных вариантов:

• CUBLAS , CUFFT , CUSPARSE
• Тяга , Cusp , OpenCurrent
• Поддержка PETSc

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

OpenCL против чего?

Если вопрос «OpenCL против CUDA», я вижу, что этот вопрос очень сложен, и он кажется мне безумным. Это не важно Честный. Ядра - куда уходят все тяжелые мысли - практически идентичны между двумя языками; Вы могли бы написать макросы для вашего любимого редактора, чтобы выполнить 99% работы по переброске между OpenCL и CUDA. Так должно быть; они низкоуровневое управление в конечном итоге довольно похожими аппаратными средствами. После того, как вы выяснили, как писать ваши важные ядра в {OpenCL, CUDA}, их тривиально портировать на {CUDA, OpenCL}.

Базовый код хоста, который вы должны написать, тоже похож, но CUDA упрощает простые случаи. Вот почему мы преподаем CUDA в нашем центре; вы можете сразу перейти к написанию кода ядра, в то время как нам пришлось бы потратить 1-2 часа нашего однодневного курса, просто объясняя, как запустить ядро ​​для OpenCL.

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

Если это OpenCL против подходов, основанных на директивах - OpenACC или HMPP или что-то еще - это, вероятно, (надеюсь?) Будет хорошим способом программирования таких архитектур в будущем, где вы сможете получить 90% производительности для 10% работы. Но какой выбор «победит», еще неизвестно, и я бы не советовал тратить на это много времени.

Поэтому я бы сказал, что между CUDA или OpenCL выберите язык, который вам удобен, и используйте его, и не беспокойтесь об этом. Ценная часть - выяснение того, как разбить вашу проблему на массивно-параллельный SIMD-код для небольших ядер с очень небольшим объемом памяти - будет довольно легко переносимой между моделями программирования.

Если вы используете аппаратное обеспечение NVIDIA - и, возможно, так и есть - тогда я обычно рекомендую CUDA - точка зрения Мэтта Кнепли о библиотеках абсолютно отсутствует. Если нет, тогда OpenCL.

Стоит ли тратить свое время на разработку программного обеспечения на основе OpenCL - вопрос, на который вы можете ответить только вы. Если кажется, что у него есть потенциал для решения проблем, с которыми вы сталкиваетесь сейчас, и никакое другое открытое решение этого не делает, ваш лучший способ действий, вероятно, состоит в том, чтобы рискнуть реализовать небольшой проект с ним.

Если все идет хорошо, вы можете попробовать его в более крупных проектах и ​​т. Д., Пока вы не наберете достаточно уверенности, чтобы стандартизировать его, или откажетесь от него в пользу какого-то другого решения (которое может быть вашим собственным проприетарным решением, другим открытым решением или даже другое фирменное решение).

Замечательная вещь в движении с открытым исходным кодом состоит в том, что, поскольку у вас есть источник, у вас есть все, что вам нужно, чтобы раскошелиться на проект в случае необходимости. Даже если само сообщество не предоставляет вам необходимые средства, ничто не мешает вам самим внедрять эти средства. Кроме того, если вам нужны эти средства, существует определенная вероятность того, что другие пользователи могут захотеть их, поэтому будем признательны, если вы внесете эти изменения обратно в основной проект.

Мало того, но если вы улучшите его с вашей точки зрения, это может улучшить его для других, побудить их представить свои собственные усовершенствования и в конечном итоге сделать программное обеспечение лучше для всех.

Наконец, да, это довольно общий ответ на довольно общий вопрос. Чтобы ответить более полно, нам нужно знать, каковы ваши опасения по поводу OpenCL. Это зрелость? Поддержка сообщества? Простота использования? Время, необходимое для обучения? Время развиваться? Менять свои процедуры? Когда вы спрашиваете о плюсах и минусах, с какими другими продуктами вы пытаетесь сравнить OpenCL ? Какие исследования вы уже сделали? Какие функции вам нужны для поддержки вашей гетерогенной вычислительной среды?

Один большой PRO - это количество поставщиков, стоящих за OpenCL. У меня есть некоторый анекдотический опыт по этому поводу, когда я встретился с исследовательской группой, которая потратила много времени и усилий на разработку довольно сложного кода CUDA для системы на базе NVIDIA. Спустя год после разработки кода исследовательская группа получила доступ к более крупной и быстрой системе на базе AMD, но они не смогли ее использовать, поскольку у них не было (человеческих) ресурсов для переноса кода.

Даже если базовый набор функций CUDA и OpenCL практически идентичен (как хорошо отметил @JonathanDursi), если первоначальный разработчик не является тем, кому поручена задача преобразования кода, весь проект переноса может занять довольно много времени.

Тем не менее, существуют некоторые официальные несовместимости между CUDA и OpenCL. Наиболее примечательно, что CUDA поддерживает шаблоны c ++, в то время как OpenCL официально не поддерживает их. Тем не менее, AMD прилагает усилия для разработки расширения для OpenCL с поддержкой шаблонов и других функций C ++, больше информации в этом посте от AMD dev central . Я надеюсь, что будущая версия OpenCL может добавить эту работу.

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

Для тех, кто изучает gpu-computing, я бы сказал, что OpenCL C может быть довольно сложным, так как есть много деталей, которые отвлекают ученика от основных идей, тогда как CUDA проще и понятнее. Тем не менее, существуют инструменты, которые делают OpenCL намного более простым в изучении и использовании, например PyOpenCL (оболочка Python для opencl), которая переносит весь сахар Python в OpenCL (обратите внимание, что есть также PyCUDA). Например, демонстрация PyOpenCL для добавления двух массивов составляет чуть менее 25 строк и включает в себя: создание массивов на хосте и устройстве, передачу данных, создание контекста и очереди, ядро, как собрать и выполнить ядро Получение результатов от GPU и сравнение их с NumPy (см. ссылки ниже).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Для опытных программистов GPU здесь я согласен с @JonathanDursi, CUDA и OpenCL в основном одинаковы, и на самом деле нет никаких различий между мэрами. Более того, кропотливая работа по разработке эффективного алгоритма для графических процессоров в значительной степени не зависит от языка, а поддержка OpenCL от поставщиков и документации теперь гораздо более зрелая, чем, скажем, 2 года назад. Единственное, что по-прежнему имеет значение, - это то, что NVIDIA действительно проделала большую работу, поддерживая сообщество CUDA.

OpenCL имеет дополнительное преимущество: он может работать на процессорах и уже поддерживается Intel и AMD. Таким образом, вам не нужно менять свою алгоритмическую структуру, если вы хотите использовать преимущества любых доступных процессорных ядер. Я не считаю, что OpenCL является лучшим решением для одного ориентированного на ЦП или многоядерного приложения, поскольку оптимизированное для ЦП ядро ​​может значительно отличаться от ядра, оптимизированного для графического процессора. Однако, по моему опыту, разработка CODE действительно выигрывает от возможности запуска на процессоре.

Я думаю, что OpenCL в настоящее время страдает от недостатка «чемпиона». Например, если вы посетите сайт NVIDIA прямо сейчас (16.12.2011), у вас есть несколько снимков в стиле «эффекта Кена Бернса» на заставке, посвященных научной / промышленной стороне вычислений на GPU, и ~ 1 / Четвёртый из ваших вариантов навигации указывает вам на вещи, которые, вероятно, в конечном итоге в CUDA. Производители, продающие серверы и рабочие станции с «GPU-вычислениями», продают решения NVIDIA.

Конкурирующие предложения от ATI смешиваются с общим сайтом AMD, их труднее найти, и они не так широко представлены в сторонних решениях. Эти решения и возможность выполнять программирование на основе OpenCL, безусловно, существуют, но это оставило представление - по крайней мере, в моих мыслях, но в умах некоторых других людей, с которыми я говорил - что крупные корпоративные спонсоры платформы OpenCL уже " выйти из поля ". Например, люди, использующие OS X, вероятно, слишком заняты рассуждениями о том, будет ли рабочая станция Apple вообще существовать через год, чтобы поверить в то, что они будут продвигать вычисления на OpenCL GPU.

Наиболее важным фактором является то, что CUDA будет по-прежнему поддерживаться только оборудованием NVIDIA.

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