Что такое opencl и cuda

CUDA vs OpenCL: Which to Use for GPU Programming

Graphic Processing Units or GPUs have become an essential part of providing processing power for high performance computing applications over the recent years. GPGPU Programming is general purpose computing with the use of a Graphic Processing Unit (GPU). This is done by using a GPU together with a Central Processing Unit (CPU) to accelerate the computations in applications that are traditionally handled by just the CPU only. GPU programming is now included in virtually every industry, from accelerating video, digital image, audio signal processing, and gaming to manufacturing, neural networks and deep learning.

GPGPU programming essentially entails dividing multiple processes or a single process among different processors to accelerate the time needed for completion. GPGPU’s take advantage of software frameworks such as OpenCL and CUDA to accelerate certain functions in a software with the end goal of making your work quicker and easier. GPU’s make parallel computing possible by use of hundreds of on-chip processor cores which simultaneously communicate and cooperate to solve complex computing problems.

CUDA vs OpenCL – two interfaces used in GPU computing and while they both present some similar features, they do so using different programming interfaces.

Why CUDA?

CUDA which stands for Compute Unified Device Architecture, is a parallel programming paradigm which was released in 2007 by NVIDIA. CUDA while using a language which is similar to the C language is used to develop software for graphic processors and a vast array of general-purpose applications for GPU’s which are highly parallel in nature.

CUDA is a proprietary API and as such is only supported on NVIDIA’s GPUs that are based on Tesla Architecture. The graphics cards which support CUDA are the GeForce 8 series, Tesla and Quadro. The CUDA programming paradigm is a combination of both serial and parallel executions and contains a special C function called the kernel, which is in simple terms a C code that is executed on a graphics card on a fixed number of threads concurrently (learn more about what is CUDA).

Why OpenCL?

OpenCL an acronym for the Open Computing Language was launched by Apple and the Khronos group as a way to provide a benchmark for heterogeneous computing that was not restricted to only NVIDIA GPU’s. OpenCL offers a portable language for GPU programming that uses CPU’s, GPU’s, Digital Signal Processors and other types of processors. This portable language is used to design programs or applications that are general enough to run on considerably different architectures while still being adaptable enough to allow each hardware platform achieve high performance.

OpenCL provides portable, device- and vendor-independent programs which are capable of being accelerated on various different hardware platforms. OpenCL C language is a restricted version of the C99 language that has extensions which are appropriate for executing data-parallel codes on various devices.

CUDA vs OpenCL Comparison

Performance

OpenCL assures a portable language for GPU programming, which is adept at targeting very unrelated parallel processing devices. This in no way means that a code is guaranteed to run on all devices if at a all due to the fact that most have very different feature sets. Some extra effort has to be put in to make the code run on multiple devices while avoiding vendor-specific extension. Unlike the CUDA kernel, an OpenCL kernel can be compiled at runtime, which would add up to an OpenCL’s running time. However, On the other hand, this just-in-time compile could allow the compiler to generate code that will make better use of the target GPU.

CUDA, is developed by the same company that develops the hardware on which it executes its functions, which is why one may expect it to better match the computing characteristics of the GPU, and therefore offering more access to features and better performance.

However, performance wise, the compiler (and ultimately the programmer) is what makes each interface faster as both can fully utilize hardware. The performance will be dependent on some variables, including code quality, algorithm type and hardware type.

Implementation by Vendors

As of the time of this writing there is only one vendor for CUDA implementation and that is its proprietor, NVIDIA.

OpenCL, however, has been implemented by a vast array of vendors including but not limited to:

Portability

This is likely the most recognized difference between the two as CUDA runs on only NVIDIA GPUs while OpenCL is an open industry standard and runs on NVIDIA, AMD, Intel, and other hardware devices. Also OpenCL provides for CPU fallback and as such code maintenance is easier while on the other hand CUDA does not provide CPU fallback, which makes developers put if-statements in their codes that help to distinguish between the presence of a GPU device at runtime or its absence.

Open-source vs commercial

Another highly recognized difference between CUDA and OpenCL is that OpenCL is Open-source and CUDA is a proprietary framework of NVIDIA. This difference brings its own pros and cons and the general decision on this has to do with your app of choice.

Generally if the app of your choice supports both CUDA and OpenCL, going with CUDA is the best option as it generates better performance results in this scenario. This is because NVIDIA provides top quality support. If some apps are CUDA based and others have OpenCL support, a recent NVIDIA card will help you get the most out of CUDA enabled apps while having good compatibility in non-CUDA apps.

However, if all your apps of choice are OpenCL supported then the decision is already made for you.

Multiple OS Support

CUDA is able to run on Windows, Linux, and MacOS, but only using NVIDIA hardware. However, OpenCL is available to run on almost any operating system and most hardware varieties. When it comes to the OS support comparison the chief deciding factor still remains the hardware as CUDA is able to run on the leading operating systems while OpenCL runs on almost all.

The hardware distinction is what really sets the comparison. With CUDA having a requirement of only the use of NVIDIA hardware, while with OpenCL the hardware is so not specified. This distinction has its own pros and cons.

Libraries

Libraries are key to GPU Computing, because they give access to a set of functions which have already been finetuned to take advantage of data-parallelism. CUDA comes in very strong in this category as it has support for templates and free raw math libraries which embody high performance math routines:

OpenCL has alternatives which can be easily built and have matured in recent times, however nothing like the CUDA libraries. An example of which is the ViennaCL. AMD’s OpenCL libraries also have an added bonus of not only running on AMD devices but additionally on all OpenCL compliant devices

Community

This is a part of the comparison that encompasses the support, longevity, commitment, etc of each framework. While these things could be hard to measure, a look at forums give a measure of how large a community is. The number of topics on NVIDIA’s CUDA forums are staggeringly larger than AMD’s OpenCL forums. However, the OpenCL forums have been increasing in topics in recent years and one ought to also note that CUDA has been around for a larger amount of time.

Technicalities

CUDA allows for developers to write their software in C or C++ because it is only a platform and programming model not a language or API. Parallelization is achieved by the employment of CUDA keywords.

On the other hand OpenCl does not permit for writing code in C++, however it provides an environment resembling the C programming language for work and permits for work with GPU resources directly.

Comparison Table

How To Choose

When GPU is supported it brings huge great benefits to computing power and apps. With CUDA and OpenCL being the leading frameworks as at the time of writing. CUDA being a proprietary NVIDIA framework is not supported in as many applications as OpenCL, but where it is supported, the support makes for unparalleled performance. While the OpenCL which is supported in more applications does not give the same performance boosts where supported as CUDA does.

NVIDIA GPUs (newer ones) while being CUDA supported have strong OpenCL performance for the instances CUDA is not supported. The general rule of thumb being that if on the instance a great majority your choice of apps and hardware are all OpenCL supported then OpenCL should be the choice for you.

No matter what you decide on Incredibuild can help you turbocharge your compilations and tests leading to better computing, be it in content creation, machine learning, signal processing, and tons of other computer-intensive workloads. A look at our case study with MediaPro is an example of how we can accelerate your compilations and tests to a fraction of the time (in this case more than 6 times faster).

Источник

OpenCL. Что это такое и зачем он нужен? (если есть CUDA)

Здравствуй, уважаемое хабра-сообщество.

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

Предпосылки появления OpenCL

Стоит отметить, что подобные программы создавались и раньше, но именно NVidiaа CUDA обеспечила рост популярности GPGPU за счет облегчения процесса создания GPGPU приложений. Первые GPGPU приложения в качестве ядер (kernel в CUDA и OpenCL) использовали шейдеры, а данные запаковывались в текстуры. Таким образом необходимо было быть хорошо знакомым OpenGL или DirectX. Чуть позже появился язык Brook, который немного упрощал жизнь программиста (на основе этого языка создавалась AMD Stream (в ней используется Brook+) ).

CUDA стала набирать обороты, а между тем (а точнее несколько ранее) в кузнице, расположенной глубоко под землей, у подножия горы Фуджи (Fuji), японскими инженерами был выкован процессор всевластия Cell (родился он в сотрудничестве IBM, Sony и Toshiba). В настоящее время Cell используется во всех суперкомпьютерах, поставляемых IBM, на его основе постоены самые производительные в мире суперкомпьютеры (по данным top500). Чуть менее года назад компания Toshiba объявила о выпуске платы расширения SpursEngine для PC для ускорения декодирования видео и прочих ресурсоемких операций, используя вычислительные блоки (SPE), разработанные для Cell. В википедии есть статья, в кратце описывающая SpursEngine и его отличия от Cell.
Примерно в то же время (около года назад) оживилась и S3 Graphics (на самом деле VIA), представив на суд общественности свой новый графический адаптер S3 Graphics Chrome 500. По заявлениям самой компании этот адаптер так же умеет ускорять всяческие вычисления. В комплекте с ним поставляется программный продукт (графический редактор), который использует все прелести такого ускорения. Описание технологии на сайте производителя.

Итак, что мы имеем: машина, на которой проводятся вычисления может содержать процессоры x86, x86-64, Itanium, SpursEngine (Cell), NVidia GPU, AMD GPU, VIA (S3 Graphics) GPU. Для каждого из этих типов процессов существует свой SDK (ну кроме разве что VIA), свой язык программирования и программная модель. То есть если Вы захотите чтобы ваш движок рендеринга или программа расчета нагрузок на крыло боинга 787 работала на простой рабочей станции, суперкомпьютере BlueGene, или компьютере оборудованном двумя ускорителями NVidia Tesla – Вам будет необходимо переписывать достаточно большую часть программы, так как каждая из платформ в силу своей архитектуры имеет набор жестких ограничений.
Так как программисты – народ ленивый, и не хотят писать одно и то же для 5 различных платформ с учетом всех особенностей и учиться использовать разные программные средства и модели, а заказчики – народ жадный и не хотят платить за программу для каждой платформы как за отдельный продукт и оплачивать курсы обучения для программистов, было решено создать некий единый стандарт для программ, исполняющихся в гетерогенной среде. Это означает, что программа, вообще говоря, должна быть способна исполняться на компьютере, в котором установлены одновременно GPU NVidia и AMD, Toshiba SpursEngine итд.

Решение проблемы

Для разработки открытого стандарта решили привлечь людей, у которых уже есть опыт (весьма успешный) в разработке подобного стандарта: Khronos Group, на чьей совести уже OpenGL и OpenML и еще много всего. OpenCL является торговой маркой Apple Inc., как сказано на сайте Khronos Group: «OpenCL is a trademark of Apple Inc., and is used under license by Khronos. The OpenCL logo and guidelines for its usage in association with Conformant products can be found here:
http://developer.apple.com/softwarelicensing/agreements/opencl.html». В разработке (и финансировании, конечно же), кроме Apple, участвовали такие воротилы IT как AMD, IBM, Activision Blizzard, Intel, NVidia итд. (полный список тут).
Компания NVidia особо не афишировала свое участие в проекте, и быстрыми темпами наращивала функциональность и производительность CUDA. Тем временем несколько ведущих инженеров NVidia участвовали в создании OpenCL. Вероятно, именно участие NVidia в большой мере определило синтаксическую и идеологическую схожесть OpenCL и CUDA. Впрочем программисты от этого только выиграли – проще будет перейти от CUDA к OpenCL при необходимости.

Первая версия стандарта была опубликована в конце 2008 года и с тех пор уже успела претерпеть несколько ревизий.

Почти сразу после того как стандарт был опубликован, компания NVidia заявила что поддержка OpenCL не составит никакой сложности для нее и в скором времени будет реализована в рамках GPU Computing SDK поверх CUDA Driver API. Ничего подобного от главного конкурента NVidia – AMD слышно не было.
Драйвер для OpenCL был выпущен NVidia и прошел проверку на совместимость со стандартом, но все еще доступен только для ограниченного круга людей – зарегистрированных разработчиков (заявку на регистрацию подать может любой желающий, в моем случае рассмотрение заняло 2 недели, после чего по почте пришло приглашение). Ограничения доступа к SDK и драйверам заставляют задуматься о том, что на данный момент существуют какие-то проблемы или ошибки, которые пока не удается исправить, то есть продукт все еще находится в стадии бета-тестирования.
Реализация OpenCL для NVidia была достаточно легкой задачей, так как основные идеи сходны: и CUDA и OpenCL – некоторые расширения языка С, со сходным синтаксисом, использующие одинаковую программную модель в качестве основной: Data Parallel (SIMD), так же OpenCL поддерживает Task Parallel programming model – модель, когда одновременно могут выполняться различные kernel (work-group содержит один элемент). О схожести двух технологий говорит даже то что NVidia выпустила специальный документ о том как писать для CUDA так, чтобы потом легко перейти на OpenCL.

Как обстоят дела на настоящий момент

Основной проблемой реализации OpenCL от NVidia является низкая производительность по сравнению с CUDA, но с каждым новым релизом драйверов производительность OpenCL под управлением CUDA все ближе подбирается к производительности CUDA приложений. По заявлениям разработчиков такой же путь проделала и производительность самих CUDA приложений – от сравнительно невысокой на ранний версиях драйверов до впечатляющей в настоящее время.

А что же делала в этот момент AMD? Ведь именно AMD (как сторонник открытых стандартов – закрытый PhysX vs. открытый Havoc; дорогой Intel Thread Profiler vs. бесплатный AMD CodeAnalyst) делала большие ставки на новую технологию, учитывая что AMD Stream не удавалось хоть сколь-нибудь соревноваться в популярности с NVidia CUDA – виною тому отставание Stream от CUDA в техническом плане.
Летом 2009 года компания AMD сделала заявление о поддержке и соответствии стандарту OpenCL в новой версии Stream SDK. На деле же оказалось, что поддержка была реализована только для CPU. Да, именно так, это ничему не противоречит – OpenCL стандарт для гетерогенных систем и ничего не мешает Вам запустить kernel на CPU, более того – это очень удобно в случае если в системе нет другого OpenCL устройства. В таком случае программа будет продолжать работать, только медленнее. Или же вы можете задействовать все вычислительные мощности, которые есть в компьютере – как GPU так и CPU, хотя на практике это не имеет особого смысла, так как время исполнения kernel’ов которые исполняются на CPU будет намного больше тех что исполняются на GPU – скорость процессора станет узким местом. Зато для отладки приложений это более чем удобно.
Поддержка OpenCL для графических адаптеров AMD так же не заставила себя долго ждать – по последним сообщениям компании версия для графических чипов сейчас находится на стадии подтверждения соответствия спецификациям стандарта. После чего она станет доступна всем желающим.
Так как OpenCL должен работать поверх некоторой специфической для железа оболочки, а значит для того чтобы можно этот стандарт действительно стал единым для различных гетерогенных систем – надо чтобы соответствующие оболочки (драйверы) были выпущены и для IBM Cell и для Intel Larrabie. Пока от этих гигантов IT ничего не слышно, таким образом OpenCL остается еще одним средством разработки для GPU на ряду с CUDA, Stream и DirectX Compute.

Заключение

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

В будущем я планирую более подробную статью о самом OpenCL, описывающую что из себя представляет эта технология, ее особенности, достоинства и недостатки.
Спасибо за внимание.

Источник

OpenCL в повседневных задачах

Недавно мы рассказывали про HSA и в ходе обсуждения преимуществ нового подхода к построению ПК затронули такую интересную тему, как GPGPU — вычисления общего назначения на графическом ускорителе. Сегодня видеоускорители AMD предоставляют доступ к своим ресурсам с помощью OpenCL — фреймворка, обеспечивающего сравнительно простое и понятное программированое высокопараллельной системы.

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

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

GPGPU, OpenCL и немного истории

Само собой, OpenCL — не единственный способ реализовывать общие вычисления на GPU. Помимо OpenCL на рынке присутствуют CUDA, OpenACC и C++AMP, но по-настоящему популярными и находящимися на слуху являются первые две технологии.

Разработкой стандарта OpenCL занимались те же люди, которые подарили миру технологии OpenGL и OpenAM: Khronos Group. Сама торговая марка OpenCL принадлежит компании Apple, но, к счастью для программистов и пользователей по всему миру, данная технология не является закрытой или привязанной к продукции «яблочной» компании. Помимо Apple в Khronos Goup входят такие гиганты рынка, как Activision Blizzard, AMD, IBM, Intel, NVidia и ещё с десяток компаний (в основном, производителей ARM-решений), которые присоединились к консорциуму позже.

В определённой мере OpenCL и CUDA идеологически и синтаксически схожи, от чего сообщество только выиграло. Программистам (в силу схожести определённых методов и подходов) проще использовать обе технологии, переходить от «закрытой» и привязанной к железу NVidia CUDA к универсальному и работающему везде (в том числе и на обычных многоядерных CPU, и на суперкомпьютерах на базе архитектуры CELL) OpenCL.

OpenCL в повседневном использовании

Сейчас вы подумаете «ага, будут говорить про игры и фотошоп». Нет, OpenCL способен ускорить вычисления не только связанные с графикой. Одним из самых популярных приложений, использующих возможности GPGPU является… кроссплатформенный офисный пакет LibreOffice. Поддержка OpenCL появилась в нём в 2014 году и применяется для ускорения расчётов в табличном менеджере Calc.

Вот наглядное видеосравнение производительности системы с AMD A10-7850K с графическим ядром R7 и Intel Core I5 с HD4600 на борту:

В синтетических тестах тот же AMD A10-7850K по гетерогенным вычислениям с применением OpenCL обгоняет почти вдвое более дорогой i5-4670K / 4690:

К слову, в науке и её прикладных направлениях есть масса задач, которые отлично перекладываются на векторные процессоры видеоускорителей и позволяют выполнять расчёты в десятки и сотни раз быстрее, чем на CPU.

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

Сюда же относятся и быстрое преобразование Фурье, и всё, что с ним связано: решение сложных дифференциальных уравнений различными методами. Отдельно можно выделить гравитационные задачи N-тел которые применяются для расчёта аэро- и гидродинамики, моделировании жидкостей и плазмы. Сложность расчётов заключается в том, что каждая частица взаимодействует с другими, законы взаимодействия достаточно сложны, а вычисления требуется проводить параллельно. Для таких задач OpenCL и возможности GPU AMD подходят как нельзя лучше, т.к. параллельные вычисления с множеством объектов и так успешно решаются на процессорах такого типа каждый день: в пиксельный шейдерах.

Структурированные решётки часто применяются в растровой графике. Неструктурированные — в вычислениях в области гидродинамики и при различных вычислениях с элементами, чьи графы имеют разный вес. Отличия структурированных решёток от неструктурированных в количестве «соседей» каждого элемента: у структурированных оно равное, у неструктурированных — разное, но и те и те отлично ложатся на возможности OpenCL по ускорению вычислений. Сложности по переносу вычислений, в основном, математические. То есть основная задача у программиста — не только «написать» работу системы, но и разработать математическое описание, которое переложит данные на аппаратные возможности с помощью OpenCL.

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

Что ещё можно ускорить с помощью OpenCL и мощных GPU?

Поиск обратного пути. Вычисления графов и динамическое программирование: сортировки, обнаружение коллизий (соприкосновений, пересечений), генерацию регулярных структур, различные алгоритмы выборки и поиска. С некоторыми ограничениями, но поддаются оптимизации и ускорению работы нейронных сетей и связанных с ними структур, но здесь, скорее, проблемы в том, что нейронные структуры просто «дорого» виртуализировать, выгоднее использовать FPGA-решения. Отлично показывают себя работы конечных автоматов (которые и так применяются в работе с GPU, например, когда речь идёт о компрессии / декомпресии видеосигнала или работе по поиску повторяющихся элементов).

OpenCL vs CUDA

Сравнивать напрямую производительность OpenCL и CUDA практически не имеет смысла. Во-первых, если мы будем сравнивать их на видеокартах AMD и NVidia, то в грубой гонке вычислительных возможностей победят видеоадаптеры AMD: современные ускорители NVidia имеют ряд ограничений по производительности в формате FP64, внедрённые самой NVidia для того, чтобы продавать «профессиональные» видеокарты для вычислений (серии Tesla и Titan Z). Их цена несоизмеримо выше, чем у аналогов по FLOPS на базе решений AMD и их «родственных» карт в номерной линейке NVidia, что делает сравнение достаточно сложным. Можно учитывать производительность-на-Ватт или производительность-на-доллар, но к чистому сравнению вычислительной мощности это не имеет практически никакого отношения: «FLOPS’ы любой ценой» слабо вяжутся с текущей финансовой обстановкой, а по производительности-на-доллар «старушка» 7970 GHz Edition (она же R9 280X) до сих пор является одной из самых выгодных видеокарт.

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

С другой стороны, если брать во внимание не только производительность, то кое-какой анализ провести всё же можно.

OpenCL работает на куда большем списке железа, чем NVidia CUDA. Практически все CPU, поддерживающие набор инструкций SSE 3, видеоускорители начиная с Radeon HD5xxx и NVidia GT8600 заканчивая новейшими Fury / Fury-X и 980Ti / Titan X, APU от AMD, встроенная графика Intel — в общем, практически любое современное железо с несколькими ядрами может воспользоваться преимуществанми данной технологии.

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

Например, у OpenCL имеются некоторые проблемы с распределением памяти в силу «The OpenCL documentation is very unclear here».

Вместе с тем, CUDA уступает OpenCL в области синхронизации потоков — данных, инструкций, памяти, чего угодно. К тому же с помощью OpenCL можно использовать внеочередное исполнение потоков (out-of-order queues) и инструкций, а CUDA до сих пор умеет только in-order. На практике это позволяет избежать простоев процессора в ожидании данных, и эффект тем заметнее, чем длиннее ковейер процессора и больше разница между скоростью работы памяти и скоростью работы вычислительных модулей. В двух словах: чем больше мощности вы выделите под OpenCL, тем больше будет отрыв в производительности. CUDA для достижения сравнимых результатов потребует написание куда более сложного кода.

Инструменты для разработки (Дебаггер, профилер, компилятор) CUDA несколько лучше, чем аналогичные у OpenCL, но CUDA реализует API через язык C, а OpenCL — через С++, упрощая работу с объектно-ориентированным программированием, при этом оба фреймворка изобилуют «локальными» хитростями, ограничениями и особенностями.

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

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

Источник