Математичні бібліотеки для OpenCL?


35

Я шукаю інформацію у всіх, хто намагався використовувати OpenCL у своєму науковому коді. Хтось пробував (нещодавно) ViennaCL ? Якщо так, то як вона порівнюється з кускою ?

Що з OCLTools ? Чи реалізується це обіцянка? Якщо це так, чи було б можливим способом почати писати математичні ядра в OpenCL?


1
Я надіслав коротку записку розробникам ViennaCL з проханням допомогти в цьому.
Арон Ахмадія

1
Ці питання також стосувалися одного з моїх публікацій scicomp.stackexchange.com/questions/366/future-of-opencl .
Аллан П. Енгсіг-Каруп

Відповіді:


26

Перш за все, я хочу подякувати Арону Ахмадію за те, що він вказав мені на цю тему.

Що стосується OpenCL в науковому коді: OpenCL має на увазі бути API низького рівня, тому важливо якось обернути цю функціональність для досягнення розумної продуктивності. Більше того, як тільки задіяно декілька обчислювальних ядер, код може ДУЖЕ забруднитися, якщо ядро ​​OpenCL та ручки пам'яті потрібно сильно пропускати навколо програми. Я не знаю OCLTools, тому не можу сказати, чи корисні вони в цьому плані.

Що стосується ViennaCL: я керівник ViennaCL, тому нещодавно працював з бібліотекою. :-) У наступному я розглядаю запит на порівняння з cusp у трохи більшому обсязі, а саме ViennaCL проти математичних бібліотек на основі CUDA cusp та MAGMA . Вважається лише теперішній стан, навіть незважаючи на те, що існує багато поточного розвитку (принаймні з нашого боку).

Функціональність . MAGMA забезпечує функцію BLAS для щільних матриць через звичайні функціональні інтерфейси. Більшу частину цієї функціональності також надає ViennaCL 1.2.0, використовуючи перевантаження оператора та інший синтаксичний цукор.

Ці ж три ітераційні розв'язувачі (CG, BiCGStab, GMRES) забезпечені за допомогою зубчастого покриття та ViennaCL. Набір попередніх кондиціонерів суттєво відрізняється: Cusp пропонує діагоналі, SA-AMG та різні кондиціонери Bridson. ViennaCL пропонує неповні фактори LU, діагональні попередні кондиціонери та останнім часом різні аромати AMG та розріджені приблизні зворотні кондиціонери. Наскільки мені відомо, всі попередні кондиціонери працюють повністю на графічному процесорі, тоді як ViennaCL особливо покладається на етапі налаштування на обчислення на базі процесора. Наразі кількість розріджених матричних форматів більша за розміром: COO, CSR, DIA, ELL, HYB, тоді як ViennaCL 1.2.0 надає COO та CSR.

Існує ряд додаткових функцій, наданих ViennaCL, які не є частиною ні MAGMA, ні кускою: структуровані матричні типи (Циркулянт, Хенкель тощо), швидке перетворення Фур'є, алгоритми переупорядкування (наприклад, Cuthill-McKee) та обгортки для лінійної алгебри типи з інших бібліотек.

Продуктивність. Більший набір функцій та апаратної підтримки у ViennaCL, як правило, коштує меншої продуктивності порівняно з реалізаціями на базі CUDA. Частково це також пояснюється тим, що CUDA адаптована до архітектури продуктів NVIDIA, тоді як OpenCL представляє в певному сенсі розумний компроміс між різними багатоядерними архітектурами.

Загалом, ViennaCL зараз повільніше, ніж MAGMA, особливо на рівні BLAS 3. Причинами є різний фокус ViennaCL (рідкісний замість щільної лінійної алгебри) і, таким чином, вищий ступінь оптимізації в MAGMA. Особливо операції рівня BLAS в даний час значно більш швидкі в MAGMA.

Аналогічно, зусилля забезпечують дещо кращі загальні показники роботи в цілому. Однак, оскільки операції з обмеженою матрицею зазвичай обмежені пропускною здатністю пам’яті, відмінності значно менші та часто незначні порівняно з налаштуваннями даних тощо. Вибір попереднього кондиціонера та його параметрів зазвичай має більший вплив на загальний час виконання, ніж будь-які відмінності в продуктивності множинних множин матриць-векторів.

Переносність . Що стосується апаратної портативності, ViennaCL може використовувати процесори та графічні процесори від усіх основних постачальників завдяки OpenCL. На противагу цьому, cusp та MAGMA покладаються на відповідний NVIDIA GPU.

ViennaCL призначений лише для заголовків, може бути компільований на широкому діапазоні компіляторів C ++ і його потрібно зв’язувати лише з бібліотекою OpenCL, якщо потрібна підтримка GPU. В принципі, загальні алгоритми у ViennaCL також можуть використовуватися без будь-яких зв'язків OpenCL, тоді як cusp та MAGMA вимагають для компіляції компілятор NVIDIA та бібліотека CUDA в цільовій системі. MAGMA також вимагає бібліотеку BLAS, яка іноді може бути клопотом, щоб знайти або встановити в новій системі.

API . MAGMA забезпечує функціональні інтерфейси у стилі BLAS для функціональності BLAS. Інтерфейс C ++ cusp також використовує деякі функції від BLAS, але жоден оператор не перевантажує. Оскільки більшість інтерфейсів у ViennaCL навмисно схожі на Boost.uBLAS і містять синтаксичний цукор, такий як перевантаження оператора, ViennaCL також призначений для використання, як Boost.uBLAS. Таким чином, крім просто виклику заздалегідь заданого набору операцій та алгоритмів, наш намір полягає в тому, щоб зробити перехід від чисто-базованого на процесорі виконання до коду GPU максимально простим, навіть якщо слід використовувати нестандартні алгоритми. У випадку, якщо потрібне виділене ядро ​​OpenCL, також існує рамка для інтеграції власних ядер OpenCL у ViennaCL. Таким чином, ViennaCL має на меті набагато більшевисока продуктивність в тому сенсі, що час, необхідний для впровадження нових алгоритмів на GPU, зведений до мінімуму . Ці заощадження можуть значно перевищувати будь-яку пеню за ефективність (якщо вона є) порівняно з першості та MAGMA. (У потоці на одиничному тестуванні також було зазначено, що час розробки коду є дорогоцінним ресурсом науки.)

Звичайно, існує ряд ідеологічних питань (наприклад, CUDA проти OpenCL, BLAS-інтерфейс проти перевантаження операторів) протягом мого порівняння, але їх обговорення виходить за рамки початкового питання.


3
Привіт Карл, ласкаво просимо до SciComp і дякуємо за інформацію!
Джек Поульсон

1
Я думаю, що важливо зазначити, що MAGMA не працює просто BLAS рівня 3, але вона також пропонує алгоритми гібридного процесора / графічного процесора для найпоширеніших декомпозицій, наприклад LU, QR і Cholesky, а також ряд розв'язувачів для Проблеми власного значення. На домашній сторінці MAGMA ( icl.cs.utk.edu/magma ) є більше деталей, а також приємний флаєр із усіма переліченими функціями.
Педро

2

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

Сьогодні CUDA є відправною точкою для програмування графічного процесора, і якщо це потрібно, нічого не заважає використовувати OpenCL як альтернативу, наприклад, щоб зробити код більш портативним. По суті, той самий код ядра може використовуватися і в CUDA, і в OpenCL, тому перехід від CUDA до OpenCL не повинен бути основною проблемою. Це підтверджується власним досвідом, що перевіряє це. З точки зору продуктивності можна використовувати ті самі методи оптимізації, а для тривіальних одночасних компіляторів коду слід виконувати роботу добре (наприклад, розкручування циклу тощо).


Аллан, я не думаю, що ти тут відповідаєш на питання Шона ... Він спеціально шукає приклади бібліотек OpenCL, а не порівняння між ними.
Арон Ахмадія

Задано п’ять питань. Моя відповідь - це загальна відповідь на перші 4 та більш пряма відповідь на останню.
Аллан П. Енгсіг-Каруп

Досить справедливо, дякую, що доклали певних зусиль, щоб відповісти на це питання!
Арон Ахмадія
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.