Тяга для програмування GPU

Я дуже новачок у програмуванні GPGPU, тому, будь ласка, вибачте мене, якщо питання не є особливо підходящим. Як я розумію, програмування графічного процесора є дуже складною інженерною роботою порівняно зі звичайним програмуванням процесора. Потрібно бути дуже обережним щодо питань розбіжності, плитки, закріпленої пам’яті пам’яті та обчислення комунікаційних пристроїв / пристроїв, що перекриваються.

Провівши трохи досліджень, я знайшов бібліотеку тяги, яка, схоже, намагається імітувати C ++ STL. Це досить приємно. Однак, виходячи з мого дуже обмеженого досвіду та побачивши всі мікроуправління, необхідні для отримання хорошої продуктивності, я трохи скептично ставлюсь до виступу. Чи може тяга ефективно керувати внутрішньою складною частиною програмування? Деякі дуже відомі бібліотеки, такі як PETSc, схоже, використовують цей пакет, що змушує мене вважати, що це якось слід.

Мені було цікаво, чи зможуть люди з більшим досвідом роботи на CUDA та тязі сказати слово чи два про ефективність пакету порівняно з програмуванням CUDA низького рівня. Коли я можу використовувати тягу і коли я повинен перейти на CUDA?

У мене немає особистого досвіду роботи з тягою, але я використовую ViennaCL, що є ще однією бібліотекою високого рівня GPU, яка приховує майже всі деталі. З мого особистого бенчмаркінгу я бачу прискорення 2x - 40x на фактичних обчисленнях, якщо ви ігноруєте час, необхідний для переміщення по пам'яті.

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

Я використовував тягу у своєму проекті з розширенням кластера. Залежно від ситуації, Thrust може виконувати так само, як і краще, ніж реалізація на низькому рівні, яку ви робите самі (зокрема, reduceядро працює для мене досить добре). Однак загальна природа та гнучкість Thrust означає, що іноді доводиться робити багато додаткових копіювання, прокладки масивів тощо, що може уповільнити це в декількох неприємних випадках. Минулого разу я використовував sortце досить повільно порівняно з іншими бібліотеками, такими як b40c або mgpu. Однак NVIDIA працює над вдосконаленням алгоритмічної продуктивності Thrust, щоб в майбутньому виникнути проблеми.

Спробуйте написати свій код, використовуючи як Thrust, так і CUDA, а потім скористатися Visual Profiler, щоб визначити, що краще для конкретного завдання, яке вас цікавить. Якщо можливо, передача пам'яті займе найбільше часу вашої програми, і ви не мені не хочеться турбуватися про оптимізацію власних ядер для банківських конфліктів, підрахунку інструкцій тощо, то я б застосував Thrust. Це також має побічну перевагу - зробити ваш код набагато менш детальним та легшим для читання людям, які не знайомі з програмуванням GPU.

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

Я б запропонував не дуже хвилюватися про продуктивність, а запитати себе, чи є

• ваша програма може бути описана в алгоритмах, реалізованих у тязі, і якщо

• вам подобається можливість написання "загального" паралельного коду, не потребуючи детальних завдань пошуку ефективного відображення до заданої архітектури обладнання та програмного забезпечення.

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

Це сказало, я мушу зізнатися, що мені не подобається "загального" програмування, тому що я готовий дізнатися щось нове, коли пишу програму. Я б пішов іншим шляхом: написати прототип реалізації в python + numpy + scipy, а потім додати ядра CUDA для тих 1% - 2% коду, який дійсно потребує оптимізації та підходить для роботи в GPU. Звичайно, для цього вам потрібна якась наука, оскільки неправильне рішення на етапі прототипування (наприклад, структура даних, непридатна для ядер CUDA), може мати жахливі результати щодо продуктивності. Зазвичай для отримання хорошого коду потрібно більше ітерацій, і немає впевненості в тому, що робити краще, ніж тяга.