• Главная
  • Карта сайта
Не найдено

Графічний виклик суперкомп'ютерів

  1. Архітектура графічних процесорів
  2. nVidia GeForce 8
  3. AMD FireStream
  4. Технології програмування графічних процесорів
  5. Що вирішують на GPU?

Спочатку графічні процесорні пристрої (Graphical Processor Unit, GPU) не призначалися для високопродуктивних обчислень Спочатку графічні процесорні пристрої (Graphical Processor Unit, GPU) не призначалися для високопродуктивних обчислень. Завданням GPU першого покоління, які отримали завдяки комп'ютерним іграм широке поширення в середині 90-х років, була побудова в реальному часі зображень за описом тривимірних сцен. Для цього була потрібна швидка однорідна обробка великої кількості елементів (вершини, трикутники, пікселі), яка досягалася, перш за все, за рахунок апаратної реалізації основних алгоритмів.

Перші можливості програмування з'явилися в 2001 році в GPU другого покоління. Програми, що виконуються на GPU, стали називатися «шейдерами» (від англійського shade - «зафарбовувати»), і основним їх призначенням було обчислення кольору пікселя на екрані. Тоді ж почали щось робити перші спроби використання GPU для загальних обчислень, однак через низьку точності обчислень, яка складала лише 16 біт в форматі з фіксованою комою, і обмежених можливостей програмування - довжина шейдера не перевищувала 20 команд - це не набуло поширення. Ситуація змінилася з появою в 2003 році серії nVidia GeForce FX, що надала підтримку повноцінної 32-розрядної речової арифметики. Тоді ж був запропонований термін «загальні обчислення на GPU» (General Purpose GPU, GPGPU). Графічні процесори почали активно застосовуватися для розв'язання задач математичної фізики, обробки зображень і матричних обчислень.

GPU першого покоління - GeForce 6, GeForce 7, ATI Radeon X1K і більш пізні - ще більше розширили можливості програмування за рахунок введення додаткових команд управління, зокрема підтримки повноцінних циклів.

Весь цей час основним засобом програмування GPU залишалися інтерфейси тривимірної графіки DirectX і OpenGL, а також шейдерниє мови HLSL, GLSL і Cg. Останні являють собою модифікований мову програмування С, з якого викинуті масиви і покажчики, додані специфічні для GPU типи даних і вбудовані змінні, а також введені деякі обмеження, зокрема заборона на рекурсію. І хоча сам шейдер пишеться на них досить просто, програма для GPU складається не тільки з нього. Для вирішення на GPU реального завдання оброблювані дані необхідно представити у вигляді двомірних масивів - текстур, завантажити і скомпілювати сам шейдер, встановити його параметри і вихідні буфери, що робиться на основному процесорі, і тільки після цього виконати шейдер, «намалювавши квадрат» за розміром вихідного буфера. Подібні дії не викликають питань у програміста тривимірної графіки, але абсолютно незвичні для прикладного програміста, що і стримувало розвиток GPGPU. Були потрібні кошти програмування більш високого рівня, і, звичайно ж, вони були створені, але перш за подивимося на приховані в архітектурі можливості сучасних GPU, що дозволяють говорити про подібність графічних процесорів і суперкомп'ютерів.

Архітектура графічних процесорів

Сучасні GPU третього покоління, такі як nVidia GeForce 8, nVidia GeForce 9, AMD HD 2K і AMD HD 3K, містять набір однакових обчислювальних пристроїв - «потокових процесорів» (ПП), що працюють із загальною пам'яттю GPU (відеопам'ять). Число ПП змінюється від чотирьох до 128, розмір відеопам'яті може досягати 1 Гбайт. Все ПП синхронно виконують один і той же шейдер, що дозволяє віднести GPU до класу SIMD (Single Instruction, Multiple Data). За один прохід, який є етапом обчислень на GPU, шейдер виповнюється для всіх точок двомірного масиву. Система команд ПП включає в себе арифметичні команди для речових і цілочисельних обчислень з 32-розрядної точністю, команди управління (розгалуження і цикли), а також команди звернення до пам'яті. GPU виконують операції тільки з даними на регістрах, число яких може досягати 128. Через високі затримок (до 500 тактів) команди доступу до оперативної пам'яті виконуються асинхронно. З метою приховування затримок в черзі виконання GPU може одночасно перебувати до 512 потоків, і, якщо поточний потік блокується з доступу до пам'яті, на виконання ставитися другий. Оскільки контекст потоку повністю зберігається на регістрах GPU, перемикання здійснюється за один такт - за цю операцію відповідає диспетчер потоків, який не є програмованим.

Тактові частоти GPU нижче, ніж у звичайних процесорів, і лежать в діапазоні від 0,5 до 1,5 ГГц, однак завдяки великій кількості потокових процесорів продуктивність GPU дуже значна. Сучасні GPU верхнього цінового сегмента мають пікову продуктивність 200-500 GFLOPS, що в поєднанні з можливістю установки в одну машину двох графічних карт дозволяє отримати пікову продуктивність в 1 TFLOPS на одному персональному комп'ютері. Більш того, на деяких реальних задачах досягається до 70% пікової продуктивності. Одночасно з цим, в порівнянні з класичними кластерними системами, GPU мають значно кращі характеристики як за ціною (менше 1 дол. На GFLOPS), так і по енергоспоживанню (менше 1 Вт на GFLOPS).

nVidia GeForce 8

Архітектура GPU сімейства nVidia GeForce 8 представлена ​​на рис. 1. Взагалі кажучи, вона не є класичним представником архітектур SIMD. У ній 128 ПП об'єднані в SIMD-групи по 16 мультипроцессоров (МП), але при цьому різні МП працюють незалежно один від одного, хоча і виконують один і той же шейдер. Кожен ПП є суперскалярні пристроєм і може виконувати до двох команд за такт. При зверненні в відеопам'ять йому доступна вся пам'ять, як на читання, так і на запис. Однак на практиці з огляду на слабкість засобів синхронізації між різними МП бажано процес обробки будувати так, щоб адреси записи не перетиналися.

В GeForce 8 програмісту доступні 16 Кбайт явно адресується статичної пам'яті на мультипроцесорі, яка використовується спільно всіма ПП одного мультипроцессора, що має всередині механізм бар'єрної синхронізації потоків. Зауважимо, що грамотне використання статичної пам'яті якраз і є ключем до написання ефективних програм для даної архітектури.

У 2007 році компанія nVidia почала виробництво апаратних рішень на основі GPU, спеціально орієнтованих на виконання обчислювальних задач. Ця серія називається Tesla і включає в себе конфігурації на основі однієї, двох і чотирьох графічних карт. Остання призначена для установки в серверні системи.

Архітектура GeForce 8 досить популярна в співтоваристві GPGPU, і причина цього - інтерфейс програмування CUDA (C Unified Driver Architecture). У nVidia першими забезпечили можливість написання повних програм на діалекті мови програмування С. Це означає, що на цій мові можна одночасно писати код, виконуваний на графічному процесорі, і код, що виконується на центральному процесорі, і все це в рамках одного проекту. Мова Сі був розширений додатковими кваліфікаторів пам'яті і функцій для подання статичної пам'яті і шейдеров відповідно. І хоча залишився ряд обмежень, наприклад відсутність рекурсії на GPU, і програмування переміщення даних як і раніше лежить на розробнику, мова вперше дозволив програмувати на GPU в термінах, зрозумілих звичайним програмістам.

Безумовно, таке рішення не можна вважати ідеальним. По-перше, CUDA-програми виконуються тільки на графічних процесорах від nVidia і не можуть бути перенесені на інші архітектури. По-друге, CUDA, як і Сі, - це низкоуровневое засіб програмування, і для написання ефективних програм необхідно добре розуміти архітектуру GPU nVidia.

Сучасні GPU компанії AMD, представлені серіями HD 2K і HD 3K, більше схожі на традиційні GPU, ніж продукти nVidia. Загальна схема їх організації представлена ​​на рис. 2.

2

AMD FireStream

На відміну від nVidia, потоковий процесор AMD має архітектуру з довгим командним словом. Один ПП містить шість функціональних пристроїв (ФУ), у тому числі одне відповідає за команди переходу, чотири - за звичайні арифметичні команди і ще одне - за обчислення елементарних функцій (log, sin і т.д.). Арифметичні ФУ здатні виконувати до двох команд за такт, а ФУ, обчислює елементарні функції, - одну. Таким чином, один такий ПП здатний виконувати до восьми команд за такт, що більше, ніж у nVidia.

При розгляді даної архітектури можна в першому наближенні обмежитися тільки командами, які задають одну і ту ж операцію для чотирьох арифметичних ФУ. Це тим більш логічно, що обмін даними з пам'яттю йде в термінах 128-бітових одиниць, а це дорівнює чотирьом 32-розрядних слів. З цієї точки зору ПП від AMD схожий на один елемент SPE (Synergistic Processing Element) процесора Cell або ядро ​​x86-процесора з розширеннями SSE2.

Доступ до пам'яті на читання можливий через один з 32 сегментних регістрів, кожен з яких адресує двомірний ділянку пам'яті, що містить до 8192 * 8192 елементів (один елемент = 128 біт). На відміну від nVidia, GPU «у виконанні» AMD надають два режими запису. У режимі регулярної записи шейдер може записати по одному елементу в кожен з вихідних буферів, при цьому індекс елемента в буфері жорстко заданий. В режимі довільного запису доступний тільки один буфер, але запис може проводитися за довільним адресою. Засоби синхронізації відсутні.

Серія GPU від AMD, орієнтована на високопродуктивні обчислення, носить назву FireStream. На відміну від nVidia, в AMD орієнтуються тільки на виробництво графічних карт, залишаючи дизайн рішень партнерам. Зауважимо, що в FireStream 9170 вперше з'явилася підтримка обчислень з подвійною точністю, при цьому пікова продуктивність складає 100 GFLOPS.

AMD першою звернула увагу на GPGPU, випустивши інструментарій низькорівневого доступу, бібліотеку DPVM (Data-Parallel Virtual Machine). На відміну від CUDA подібні засоби швидше є проміжною ланкою у взаємодії засобів більш високого рівня з GPU.

DPVM представляла GPU на двох рівнях - рівні окремих шейдеров (вони описувалися на шейдерний мовою PS 3.0 або на асемблері AMD) і рівні послідовності команд, який відповідав за установку параметрів і адрес, роботу з кешем і виконання шейдера. Сама DPVM надавала тільки два бібліотечних виклику: запуск послідовності команд і очікування його завершення. Коштів управління пам'яттю в бібліотеці не було. При цьому була доступна вся відеопам'ять, а також пам'ять порту PCI-Express. Незважаючи на відсутність розвиненої мови для написання шейдеров, DPVM давала простий і зрозумілий інтерфейс доступу, який дозволив прискорити ряд операцій, наприклад, множення матриць, на порядок. З незрозумілих причин, від нього було вирішено відмовитися. Сучасна версія бібліотеки, CAL (Compute Abstraction Layer), підтримує кілька GPU і можливість швидкого обміну, однак більш складна в застосуванні і як і раніше дозволяє використовувати тільки шейдерниє мови, що, ймовірно, і пояснює її невисоку популярність.

Технології програмування графічних процесорів

Підхід потокового програмування, в якому алгоритм розбивається на процеси, що виконують в конвеєрі відносно прості операції над елементами даних, відомий ще з часів ранніх версій ОС Unix. В контексті GPGPU він почав активно використовуватися у зв'язку з невеликими розмірами шейдера і обмеженнями на можливості читання з пам'яті на GPU другого покоління. Після розбиття завдання на ядра кожне з них реалізовувалося у вигляді шейдера, а в ролі потоків даних виступали текстури. Цей підхід дозволяв перенести керуючу логіку на центральний процесор, залишивши на GPU основний обсяг обчислень.

Спочатку для реалізації ідей потокового програмування використовувалися мови OpenGL або DirectX. У 2003 році з'явився Brook - перша мова, який дозволив писати на GPU повноцінні програми, а не тільки шейдери. Він спирається на мову програмування С, розширений типом даних двовимірних масивів в пам'яті GPU і деякими операціями для роботи з ними. Даний мова використовувалася в ряді проектів в Стенфордському університеті, але спочатку не отримав широкого розповсюдження. Ситуація змінилася, коли в AMD вирішили використовувати Brook як свою відповідь на CUDA і просувати його в якості мови програмування власних GPU. І хоча в деяких відносинах, наприклад, при роботі з пам'яттю, Brook більш зручний, ніж CUDA, він вимагає хорошого знання архітектури GPU від AMD.

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

Метапрограмування в C ++. Програмісту дається набір додаткових стандартних типів даних і макросів, що представляють конструкції управління на GPU. Макроси перетворять текст мови в рядок, яка подається на вхід системи часу виконання. З цієї рядку система генерує шейдер, виконуваний на GPU. Даний підхід зручний тим, що не вимагає створення нових мов або інтегрованих середовищ розробки і не обмежує можливостей програміста. Вперше такий підхід був реалізований в вільно розповсюджуваної системі Sh. Зауважимо, що згодом з неї відбулися комерційні системи PeakStream і досить поширена сьогодні RapidMind, причому остання також дозволяє переносити програми на Cell і багатоядерні процесори.

«Ледачі» обчислення і «масивне» програмування. Цей спосіб програмування реалізується за допомогою системи Accelerator, що розробляється в Microsoft Research, яка дозволяє писати програму на будь-якій мові .NET, наприклад, на C #. Він вводить поняття масиву GPU з дійсних чисел і перевизначає для нього стандартні операції (наприклад, додавання і множення), які мають поелементну семантику. Визначаються і більш складні операції: редукція, сканування, вибір подмассіва і т.д. Операції виконуються «ліниво», повертаючи нереальний масив, а посилання на деякий дерево виразів. У момент приведення цього дерева до звичайного масиву відбувається його розбір, генерація коду, обчислення на GPU і повернення даних назад. Система вільно доступна для некомерційного використання, проте широкого поширення не отримала. Причина цього лежить не в підході, а в реалізації - відсутність коштів написання власних функцій для виконання на GPU суттєво обмежувало можливості програміста.

RapidMind являє собою поєднання підходів метапрограмування і масивного програмування. Метапрограмування використовується при написанні ядер для GPU, а масивне програмування - при виконанні стандартних масивних операцій. Основними поняттями RapidMind є «значення», «програма» і «масив». Програма - це деякий код, написаний за допомогою примітивів RapidMind і укладений між макросами BEGIN і END, що приблизно відповідає процедурі в звичайних мовах програмування. Значення є аналогом змінної або параметра функції і може бути тільки одного зі стандартних типів RapidMind. Нарешті, для зберігання даних використовується масив, з автоматичною синхронізацією між оперативної та видеопамятью, виконуваної системою часу виконання RapidMind.

Технологія RapidMind передбачає трьохетапний процес адаптації програм для GPU: замінити змінні значеннями RapidMind; оформити обчислення у вигляді програм RapidMind; оформити дані у вигляді масивів RapidMind і передати їх в програму для обробки.

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

Що хотілося б бачити в технологіях програмування для GPU?

Ефективність. Технологія повинна підтримувати засоби створення ефективних програм для GPU.

Переносимість. Створені програми повинні переноситися зі збереженням ефективності як між різними архітектурами GPU, так і, бажано, на схожі архітектури (SMP, Cell) без істотних змін.

Високорівневих. Технологія повинна дозволяти працювати в термінах високого рівня, зрозумілих прикладного програмісту.

Простота інтеграції. Система повинна дозволяти легко інтегрувати роботу з GPU в існуючі програми.

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

Висока обчислювальна потужність. Обсяг обчислень повинен значно перевищувати обсяг необхідних даних, в іншому випадку обчислення на GPU не покриють навіть накладних витрат на пересилання вхідних даних і результатів.

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

Можливість незалежного обчислення цільових елементів на кожному з проходів. Ця вимога прямо випливає з відсутності можливостей синхронізації.

Масиви даних, що використовуються при обчисленні, повинні повністю поміщатися в відеопам'ять. Це відразу випливає з повільного обміну між оперативною і відеопам'яттю.

Новий підхід до програмування GPU пропонується в проекті C $ (читається «сі-ес»). Проект ставить за мету створення системи програмування GPU, що задовольняє перерахованим вимогам. Основною ідеєю є те, що шейдер являє собою функцію без побічних ефектів, яка застосовується до масивів в пам'яті GPU. Шейдер можна реалізувати як функцію, а масив - як масив мови C $, що зберігається в оперативній і відеопам'яті і при необхідності синхронізований. В цьому випадку за допомогою конструкції застосування функції до масиву можна буде виконувати цю функцію на GPU.

Проект C $ складається з двох частин - системи часу виконання і власне мови C $. Система часу виконання схожа на бібліотеки типу RapidMind. Вона будує граф операцій, динамічно транслює, оптимізує і виконує його на GPU. Вона ж відповідає за виділення пам'яті під масиви і її управління за допомогою механізму складання сміття. Програміст пише програми в термінах мови C $, який надає зручну нотацію звернення до API системи часу виконання C $. Крім того, C $ - повноцінний об'єктно-орієнтована мова .NET, що дозволяє використовувати .NET як для його проміжного представлення, так і для виконання тієї частини програми, яка виконується на центральному процесорі. По суті, це C # / Java з додатковими елементами масивного і функціонального програмування. Завдяки єдиній системі типів програма на C $ може бути доступна у вигляді DLL-файлу .NET і легко інтегрується в будь-який .NET-проект як бібліотека класів.

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

Для більш складних випадків передбачено поняття пов'язаної змінної. Її використання є цикл без заголовка і дозволяє задавати більш гнучкі конструкції. Користувач записує алгоритм в термінах звичайних масивів, і при цьому йому нічого не відомо про схему їх зберігання: на різних GPU ці схеми можуть істотно відрізнятися. Більш того, під час виконання система постарається вибрати як підходяще уявлення даних в пам'яті, так і відображення коду на рівні паралелізму GPU. В даному випадку для GPU від AMD, наприклад, буде проведена автоматична векторизація коду для використання четвірок дійсних чисел і специфічних шаблонів доступу до пам'яті, що дозволить підвищити швидкість роботи до 76 GFLOPS на AMD X1950 PRO, а це близько 45% його пікової продуктивності.

Що вирішують на GPU?

В контексті GPU під матричними обчисленнями розуміється множення щільних матриць. Інші операції, наприклад додавання, з огляду на дуже малій обчислювальної потужності не досягають продуктивності вище 2% від пікової. При нинішніх обсягах пам'яті на GPU можна множити матриці розміром до 8000 * 8000, і всі дані будуть розміщені в відеопам'яті. Реально досягнута продуктивність також досить висока: на AMD HD 2900 - 100 GFLOPS, на nVidia GeForce GTX8800 - 125 GFLOPS (на процедурі з CUBLAS, реалізованої nVidia). Така продуктивність досягається за рахунок використання блокових алгоритмів множення матриць, а класичні прямі продажі виявляються на порядок повільніше.

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

Окремо стоїть завдання розрахунку ціни опціонів за формулою Блека-Шоулза, часто вирішується на практиці. Це той рідкісний випадок, коли велика кількість обчислень поєднується з дуже простої паралельної структурою. На вхід подаються три масиву параметрів опціонів, і потрібно розрахувати вартість опціону для кожної трійки параметрів. Формула для розрахунків містить тільки одне розгалуження, а в іншому абсолютно лінійна. Більш того, в розрахунках активно використовуються операції логарифма та експоненти, які набагато ефективніше реалізовані на сучасних графічних процесорах, ніж на центральних процесорах. В результаті системи на GPU демонструють на цьому завданні практично 100-кратне прискорення в порівнянні зі звичайним процесором. На nVidia GeForce 8800GTX досягнута продуктивність складає 260 GFLOPS.

Обробка зображень була однією з перших завдань, що вирішуються на GPU. Найбільш важливими алгоритмами тут є фільтрація зображень і перетворення Фур'є. Фільтрація, завдяки відносно простій структурі, легко відображається на GPU, проте коефіцієнт повторного використання даних значно менше, ніж у множення матриць, що і пояснює значно меншу ефективність GPU в рішенні даного завдання. При розмірі ядра 3 * 3 продуктивність коду на nVidia GeForce 8800GTX становить близько 14,1 GFLOPS (тобто завантаження - всього 4%). Часто застосовується на практиці окрема фільтрація за допомогою фільтра Гаусса показує найгірші результати з огляду на ще більш низького коефіцієнта повторного використання.

Перетворення Фур'є відноситься до класу алгоритмів, які на GPU виконуються за час, пропорційне N lg N, де N - розмір завдання. Обидва алгоритми реалізуються за допомогою багатопрохідної схеми, де на кожному проході застосовується ядро ​​типу «метелики». І хоча обчислювальна складність подібного ядра відносно невисока, GPU від nVidia вдається досягти на ньому непоганих результатів. На перших етапах роботи весь робочий набір уміщається в статичну пам'ять, що дозволяє зібрати його в один прохід і отримати близько 40 GFLOPS на графічній карті nVidia GeForce 8800GTX.

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

Показовий приклад використання GPU в grid - проект Folding @ Home, розпочатий в 2000 році з метою використання розподілених обчислень для вирішення завдання визначення просторових структур білка. Розуміння цих процесів надзвичайно важливо в лікуванні цілої низки захворювань, зокрема хвороб Альцгеймера і Паркінсона. Користувачі можуть завантажити програму-клієнт, яка завантажує дані з сервера і виконує розрахунки. Спочатку проект орієнтувався на звичайні процесори і припускав використання оптимізованих під SSE обчислювальних ядер. У жовтні 2006 року був випущений клієнт для AMD X1K на основі DPVM. Через кілька днів внесок GPU в загальну продуктивність проекту становив близько 31 TFLOPS, при цьому використовувалося всього 450 графічних карт. Загальний внесок GPU з тих пір залишається приблизно на тому ж рівні. З виходом в березні 2007 року клієнта для Sony PlayStation 3, що використовує процесор Cell, загальний внесок GPU став досить невеликим порівняно з іншими архітектурою (загальна продуктивність системи дорівнює 1,5 PFLOPS, при цьому більше 80% припадає на PlayStation 3), і становить всього близько 2%. Однак GPU лідирують за вкладом одного пристрою певного типу: кожне GPU вносить близько 63 GFLOPS в загальну продуктивність, а це вдвічі більше, ніж Cell, і в 60 разів більше вкладу одного процесора з класичною архітектурою x86.

Кластери з GPU дозволяють отримати високу пікову продуктивність, однак наблизитися до неї на практиці непросто. Найбільш істотним фізичним обмеженням є низька пропускна здатність каналу «GPU - центральний процесор», особливо у напрямку до центрального процесора, оскільки мережева карта безпосередньо з GPU недоступна. З поширенням PCI-Express і швидкої зворотної пересилки ситуація значно покращилася: швидкості близько 1 Гбайт / с зробили кластери GPU ефективними і реально використовуваними комп'ютерними системами.

Хорошим прикладом вирішення завдання на кластері GPU є завдання N тіл, активно застосовується в астрономічних розрахунках. Є система з N тіл, задані їх положення і початкові швидкості. Між частинками діє сила взаємного тяжіння, яка обчислюється за формулою Ньютона. Потрібно розрахувати еволюцію всієї системи. Найбільш очевидний підхід - це розраховувати на кожному кроці прискорення кожної частинки, і відповідно до цього змінювати її положення. Для розрахунку руху однієї частинки необхідно підсумувати внесок всіх інших частинок в її прискорення, тому складність одного кроку розрахунку становить O (N2), де O- деяка константа. Оскільки завдання може застосовуватися для великих скупчень частинок, наприклад галактик або астероїдів Сонячної системи, а число кроків за часом може бути великим, то завдання в цілому буде мати значну обчислювальною складністю.

Автори однієї з подібних робіт спочатку реалізували свою систему на одному графічному процесорі GeForce 8 з використанням CUDA. Була досягнута продуктивність 250 GFLOPS (завантаженість 78%). На графічному процесорі обчислювалося тільки прискорення частинок і його похідна по часу, а зміна положення і подальше побудова їх орбіт проводилося на центральному процесорі.

Реалізація алгоритму на кластері GPU (16 комп'ютерів по дві карти nVidia GeForce 8800GTX в кожному) виконана за рахунок розбиття частинок на групи. Все GPU були організовані в логічне кільце, частинки були розділені порівну між різними GPU. Кожен крок еволюції розраховувався в M етапів, де M - це загальне число GPU в системі. На кожному кроці GPU розраховував вплив поточного блоку частинок на свої частки, після чого передавав поточний блок наступного по колу процесору і брав новий поточний блок від попереднього. Після цього результати обчислень підсумовувалися. Для роботи з мережею використовувався MPI і його можливості по асинхронної пересилання даних, що дозволяло виконувати передачу даних на тлі обчислення сили взаємодії. Пікова продуктивність кластера з 32 GPU склала 16,7 TFLOPS. При цьому реальна досягнута продуктивність дорівнювала 7,1 TFLOPS на завданні моделювання одного мільйона частинок. Це відповідає ефективності 42% і є дуже хорошим результатом. Починаючи з 100 тис. Частинок завдання масштабувати на 32 GPU майже лінійно.

***

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

Куди рухаються архітектури GPU? Якщо простежити вектор розвитку по першим трьом поколінням, то вони змінюються в сторону збільшення їх універсальності при подальшому зростанні продуктивності. Важливим кроком у цьому напрямку є GeForce 8, який відходить від традиційної SIMD-архітектури для GPU. У тому ж напрямку рухаються не тільки GPU. Дійсно, процесор Cell, експериментальні 80-ядерні процесори Intel і знаходиться в даний час на стадії розробки графічний процесор Larrabee від Intel також йдуть в руслі цих тенденцій. Спостерігається конвергенція різних паралельних архітектур в сторону створення високопродуктивної і доступною MIMD-архітектури загального вигляду.

Паралелізм в сучасних архітектурах не обмежується суперкомп'ютерами - він йде «в маси» у вигляді багатоядерних процесорів, GPU, ПЛІС та інших архітектур. Тому, з одного боку, варто очікувати появи стандартів, які нададуть єдиний спосіб організації програм в неоднорідних обчислювальних середовищах, а з іншого - високорівневих мов програмування, які будуть здатні ефективно відображати паралельні програми на різні цільові архітектури.

Андрій Адінец ( [email protected] ) - програміст, Володимир Воєводін ( [email protected] ) - заступник директора НИВЦ МГУ (Москва).

Особливості роботи з GPU

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

Висока вартість читання з відеопам'яті в шейдера на GPU. Операція читання з відеопам'яті займає на два порядки більше часу, ніж виконання однієї арифметичної операції.

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

Підтримка апаратної многопоточности. Якщо готових до виконання потоків буде мало, то високу латентність звернення до відеопам'яті приховати не вдасться.

Повільний обмін даними між оперативною і відеопам'яттю. Канал обміну даними між ними є вузьким, що потрібно мати на увазі при організації програми.

Різнорідність архітектур. Слід враховувати, що оптимальні програми для nVidia і AMD будуть сильно відрізнятися.

Що хотілося б бачити в технологіях програмування для GPU?
Що вирішують на GPU?
Куди рухаються архітектури GPU?
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

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

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью