Майбутнє OpenCL?

Парадигма програмування OpenCL обіцяє бути безоплатним відкритим стандартом для гетерогенних обчислень. Чи варто вкладати свій час у розробку програмного забезпечення на базі OpenCL? Плюси мінуси?

Питання занадто широке і розпливчасте, щоб реально відповісти на нього. Однак я бачу один помітний пункт проти OpenCL з точки зору наукових обчислень, на що наголошують рідко. Поки що не було зусиль для створення відкритих джерел, інфраструктурних бібліотек для OpenCL, тоді як CUDA має кілька чудових варіантів:

• CUBLAS , CUFFT , CUSPARSE
• Тяга , Привід , OpenCurrent
• Підтримка PETSc

Я вважаю, що це дійсно зашкодить OpenCL, оскільки головним фасилітатором прийняття є висока якість, відкриті бібліотеки.

OpenCL проти чого?

Якщо питання OpenCL проти CUDA, я бачу багато рукоятки над цим питанням, і мені це здається божевільним. Це не має значення. Чесний. Ядра - куди треба піти все важке мислення - практично однакові між двома мовами; ви можете написати макроси для свого улюбленого редактора, щоб виконати 99% роботи, щоб перейти між OpenCL та CUDA. Це повинно бути таким; вони контролюють низький рівень в кінцевому рахунку досить схожих видів обладнання. Після того, як ви зрозуміли, як записати важливі ядра в {OpenCL, CUDA}, тривіально перенести їх на {CUDA, OpenCL}.

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

Але навіть там різниця не така важлива; як тільки ви почнете робити більш складні речі (асинхронні ядра на декількох gpus), вони є однаково складними, і знову ж таки, ви можете значною мірою зробити почерговий переклад з одного на інший.

Якщо це 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-обчислення, я б сказав, що OpenCL C може бути досить важким, оскільки є багато деталей, які відволікають учня від основних ідей, тоді як CUDA - простіший і прямий вперед. Однак є інструменти, які роблять OpenCL набагато простішим у вивченні та використанні, як PyOpenCL (обгортка python для opencl), який приносить увесь цукор пітона до 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 не є найкращим рішенням для однієї програми, орієнтованої на процесор / багатоядерність, оскільки ядро, оптимізоване під процесор, може виглядати значно інакше, ніж ядро, оптимізоване під GPU. Однак, на мій досвід, розробка CODE має користь від можливості працювати на процесорі.

Я думаю, що OpenCL зараз страждає від нестачі "чемпіона". Наприклад, якщо ви зараз завітаєте на сайт NVIDIA (16.12.2011), на екрані сторінки з'являються кілька знімків стилю "Кена Бернса", що зосереджуються на науковій / промисловій стороні обчислень GPU та ~ 1 / Четверте з ваших варіантів навігації спрямовує вас на речі, які, ймовірно, закінчаться у CUDA. Виробники, що продають сервери та робочі станції "GPU computing", продають рішення NVIDIA.

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

Найважливішим фактором є те, що CUDA залишатиметься підтримкою лише апаратного забезпечення NVIDIA.

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