Коли мені слід вивантажувати роботу на графічний процесор замість процесора?


16

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

Однак, з усіма цими новими системами, здається, ніби GPU в будь-якому випадку кращі за процесори . Оскільки GPU можуть робити паралельний обчислення, багатоядерні GPU насправді здаються, що вони будуть набагато кращими, ніж багатоядерні процесори; ви зможете зробити багато обчислень одночасно і дійсно підвищити швидкість. Чи все ж є певні випадки, коли послідовна обробка все ж краща, швидша та / або ефективніша, ніж паралельна?



6
Насправді не питання про обладнання. Слід змінити слово "коли програмування процесора (-ів) краще, ніж програмування графічного процесора", і таке є досить гарним питанням IMO. Дивіться тег GPGPU серед інших у програмі SO. Але питання архітектури "Що використовувати технологію" тут краще, ніж там.
Кейт Григорій

1
@Kate Цей кут, здається, дуже добре висвітлений у пов'язаному питанні про Супер Користувача. Читаючи це, я трохи здивований, що сюди не переселилися, чесно кажучи. Там також це на SO. Я знову відкрию це питання (оскільки ви маєте рацію, програмні аспекти цього питання є на тему тут). Сподіваюся, ми побачимо відповідь, яка не просто вказує на існуюче (відмінне) висвітлення цієї проблеми.
Адам Лір

1
До точки зору @ Anna, я думаю, що відповіді повинні бути набагато більше про те, коли програміст повинен використовувати GPU, а не чисто теоретичне обговорення того, в чому різниця між GPU та CPU. Я відредагував заголовок, щоб це відобразити.

2
@RetroX Ми не можемо закрити запитання як копії, якщо вони є на різних сайтах.
Адам Лір

Відповіді:


27

Однак, з усіма цими новими системами, схоже, що GPU в будь-якому кращому рівні кращі за процесори.

Це фундаментальне нерозуміння. Наявні ядра GPU все ще обмежені порівняно з поточними центральними процесорами верхнього рівня. Я думаю, що архітектура Fermi NVIDIA - це найпотужніший GPU на даний момент. У нього є лише 32-бітні регістри для цілої арифметики, і менша можливість для прогнозування гілок та спекулятивного виконання, ніж поточний товарний процесор Intel. Чіпи Intel i7 забезпечують три рівні кешування, у ядрах Fermi є лише два, а кожен кеш у Fermi менший, ніж відповідний кеш на i7. Міжпроцесовий зв'язок між ядрами графічного процесора досить обмежений, і ваші обчислення повинні бути складені таким чином, щоб врахувати це обмеження (ядра з’єднані в блоки, а зв'язок між ядрами в блоці є відносно швидким, але зв'язок між блоками відбувається повільно).

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

Процесори на GPU живуть в ізольованому світі. Вони можуть керувати дисплеєм, але не мають доступу до диска, мережі чи клавіатури.

Доступ до системи GPU має значні накладні витрати. У GPU є своя пам’ять, тому ваші розрахунки будуть обмежені обсягом пам'яті на картці GPU. Передача даних між пам'яттю GPU та основною пам'яттю є відносно дорогою. Прагматично це означає, що передати декілька коротких обчислень з процесора в GPU немає користі, оскільки витрати на налаштування та вилучення загрожують часу, необхідному для проведення розрахунку.

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


Підтримка подвійної точності є частиною Shader Model 5, а також AMD / ATI.
Бен Войгт

@Ben, дякую за виправлення. Я видалив неправильне твердження.
Чарльз Е. Грант

11

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

Коли у вас є велика кількість даних, які вам потрібно обробити, і кожен елемент можна обробляти паралельно, незалежно від інших, тоді перейдіть і надішліть їх до GPU. Але не думайте про це як про "нову парадигму", в яку потрібно втиснути все.

Це питання позначено "оптимізація", тому не забудьте ставитися до цього як до одного. Застосовуйте оптимізацію GPU там, де тестування та профілювання виявляють, що потрібна оптимізація, а характер завдання такий, що оптимізація GPU може бути застосована. В іншому випадку не турбуйтеся з цим, оскільки це буде передчасною або неправильною оптимізацією, що спричиняє більше проблем, ніж виправляє.


8

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

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

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

Графічні процесори підходять до речі з протилежного напрямку: вони розроблені значною мірою для зручності дизайнера апаратури, а такі речі, як OpenCL, намагалися забезпечити максимально розумну модель програмування, враховуючи обмеження обладнання.

Написання коду для запуску на графічний процесор, як правило, займе більше часу та зусиль (тому це коштуватиме дорожче), ніж робити те ж саме на процесорі. Таким чином, в першу чергу це має сенс, коли / якщо:

  1. Проблема настільки паралельна, що можна очікувати великого виграшу від мінімальних зусиль, або
  2. Підвищення швидкості настільки важливе, що виправдовує багато зайвої роботи.

Є кілька очевидних можливостей для кожного - але величезна кількість додатків явно навіть не близька ні до одного. Я був би дуже здивований, побачивши (наприклад, програму CRUD, що незабаром працює на графічному процесорі (і якщо це станеться, це, мабуть, станеться тому, що хтось поставив перед собою таку точну ціль, не обов'язково щось наближається до оптимальної співвідношення витрат / вигод).

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


3

ви зможете зробити багато обчислень одночасно і дійсно підвищити швидкість.

підвищити швидкість? і що? Протягом минулого року я можу згадати лише один чи два рази, коли це було потрібно. Більшу частину часу мене просили змінити або виправити логіку, налаштувати інше джерело даних, покращити взаємодію користувачів тощо. Єдиною швидкістю , яка зацікавила клієнтів у цих випадках, була швидкість зміни. "Випустіть нову функцію через місяць, а ще краще - за два тижні".

Не зрозумійте мене неправильно - як кодер мені подобається ретельно стискати кліщі процесора. Просто це мистецтво зазвичай не користується великим попитом.

Чи все ж є певні випадки, коли послідовна обробка все ж краща, швидша та / або ефективніша, ніж паралельна?

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

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


2

Процесори все ще більш універсальні. Наприклад, GPU є більш ефективними, ніж процесори в одній точності, але не в подвійній точності. Існує набагато більше бібліотек для процесорів, ніж для графічних процесорів.


3
Чи можете ви детальніше розібратися? Ви надали три заяви без жодної інформації та пояснень щодо їх правдивості.

Ну, відсутність ефективних обчислень подвійної точності загальновідома: en.wikipedia.org/wiki/GPGPU
Quant_dev

@quant: Ваша інформація застаріла принаймні за 2 роки: 544 GigaFLOPS набагато швидше, ніж будь-який основний процесор.
Бен Войгт

@Ben я не бачу, де ваше посилання згадує про подвійну точність роботи.
Quant_dev


2

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

Графічні процесори не люблять велику кількість процесорів, вони мають надзвичайно різні характеристики продуктивності.


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

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

1

Якщо вам потрібна сира обробка чисел, GPU - це шлях. Однак усі ці АЛУ означають, що існує менше транзисторів, призначених для управління схемою потоку (розгалуження). Отже, якщо вам потрібно написати щось, для чого потрібна велика кількість складного потоку управління, багато умовностей тощо, тоді процесор буде швидшим.

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