1. Передмова
2. народження GPGPU
3. GPU - наше все?
4. KGPU або ядро ​​Linux, прискорене GPU
5. Що є зараз?
6. Ставимо CUDA Toolkit
7. Ставимо ATI Stream SDK
8. ImageMagick і OpenCL
9. FlacCL (Flacuda)
10. oclHashcat або брутфорс по-швидкому
11. висновки
12. Info
13. Links

Сьогодні новини про використання графічних процесорів для загальних обчислень можна почути на кожному розі. Такі слова, як CUDA, Stream і OpenCL, за якихось два роки стали чи не найбільш цитованими в айтішной інтернеті. Однак, що означають ці слова, і що несуть стоять за ними технології, відомо далеко не кожному. А для линуксоидов, які звикли «бути в прольоті», так і взагалі все це бачиться темним лісом.

Передмова

У цій статті ми спробуємо розібратися, навіщо потрібна технологія GPGPU (General-purpose graphics processing units, Графічний процесор загального призначення) і всі пов'язані з нею реалізації від конкретних виробників. Дізнаємося, чому ця технологія має дуже вузьку сферу застосування, в яку переважна більшість софта не влучає у принципі, і звичайно ж, спробуємо витягти з усього цього вигоду у вигляді істотних приростів продуктивності в таких завданнях, як шифрування, підбір паролів, робота з мультимедіа та архівування.

народження GPGPU

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

Пізніше з'явилися багатоядерні процесори і багатопроцесорні системи, в яких таких компонентів було кілька. Це дозволило машинам виконувати кілька завдань одночасно, а загальна (теоретична) продуктивність системи піднялася рівно в стільки разів, скільки ядер було встановлено в машині. Однак виявилося, що виробляти і конструювати багатоядерні процесори занадто складно і дорого. У кожному ядрі доводилося розміщувати повноцінний процесор складною і заплутаною x86-архітектури, зі своїм (досить об'ємним) кешем, конвеєром інструкцій, блоками SSE, безліччю блоків, що виконують оптимізації і т.д. і т.п. Тому процес нарощування кількості ядер суттєво загальмувався, і білі університетські халати, яким два або чотири ядра було явно мало, знайшли спосіб задіяти для своїх наукових розрахунків інші обчислювальні потужності, яких було в достатку на відеокарті (в результаті навіть з'явився інструмент BrookGPU, емулює додатковий процесор за допомогою викликів функцій DirectX і OpenGL).

Графічні процесори, позбавлені багатьох недоліків центрального процесора, виявилися відмінною і дуже швидкої лічильної машинкою, і зовсім скоро до напрацювань вчених умів почали придивлятися самі виробники GPU (а nVidia так і взагалі найняла більшість дослідників на роботу). В результаті з'явилася технологія nVidia CUDA, яка визначає інтерфейс, за допомогою якого стало можливим перенести обчислення складних алгоритмів на плечі GPU без будь-яких милиць. Пізніше за нею пішла ATi (AMD) з власним варіантом технології під назвою Close to Metal (нині Stream), а зовсім скоро з'явилася стала стандартом версія від Apple, яка отримала ім'я OpenCL.

GPU - наше все?

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

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

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

І третє: графічні процесори працюють з пам'яттю, встановленої на самій відеокарті, так що при кожному залученні GPU буде відбуватися дві додаткових операції копіювання: вхідні дані з оперативної пам'яті самого додатка і вихідні дані з GRAM назад в пам'ять програми. Неважко здогадатися, що це може звести нанівець весь виграш у часі роботи програми (як і відбувається у випадку з інструментом FlacCL, який ми розглянемо пізніше).

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

KGPU або ядро ​​Linux, прискорене GPU

Дослідники з університету Юти розробили систему KGPU , Що дозволяє виконувати деякі функції ядра Linux на графічному процесорі за допомогою фреймворка CUDA. Для виконання цього завдання використовується модифіковане ядро ​​Linux і спеціальний демон, який працює в просторі користувача, слухає запити ядра і передає їх драйверу відеокарти за допомогою бібліотеки CUDA. Цікаво, що незважаючи на істотний оверхед, який створює така архітектура, авторам KGPU вдалося створити реалізацію алгоритму AES, який піднімає швидкість шифрування файлової системи eCryptfs в 6 разів.

Що є зараз?

В силу своєї молодості, а також завдяки описаним вище проблем, GPGPU так і не стала по-справжньому поширеною технологією, проте корисний софт, який використовує її можливості, існує (хоч і в мізерній кількості). Одними з перших з'явилися крекери різних хеш, алгоритми роботи яких дуже легко распараллелить. Також народилися мультимедійні додатки, наприклад, кодировщик FlacCL, що дозволяє перекодувати звукову доріжку в формат FLAC. Підтримкою GPGPU обзавелися і деякі вже існуючі раніше додатки, найпомітнішим з яких став ImageMagick, який тепер вміє перекладати частину своєї роботи на графічний процесор за допомогою OpenCL. Також є проекти з перекладу на CUDA / OpenCL (не люблять юніксоід ATi) архиваторов даних і інших систем стиснення інформації. Найцікавіші з цих проектів ми розглянемо в наступних розділах статті, а поки спробуємо розібратися з тим, що нам потрібно для того, щоб все це завелося і стабільно працювало.

GPU вже давно обігнали x86-процесори в продуктивності

По-перше, знадобиться відеокарта, що підтримує технологію CUDA або Stream. Необов'язково, щоб вона була топова, досить тільки, щоб рік її випуску був не менше 2009. Повний список підтримуваних видюшек можна подивитися у Вікіпедії: en.wikipedia.org/wiki/CUDA і en.wikipedia.org/wiki/AMD_Stream_Processor . Також про підтримку тієї чи іншої технології можна дізнатися, прочитавши документацію, хоча в більшості випадків буде достатнім поглянути на коробку з під відеокарти або ноутбука, зазвичай на неї наклеєні різні рекламні стікери.

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

І по-третє, так як поки дістрібутівостроітелі ще не почали поширювати пакети додатків з підтримкою GPGPU, нам доведеться збирати додатки самостійно, а для цього потрібні офіційні SDK від виробників: CUDA Toolkit або ATI Stream SDK . Вони містять у собі необхідні для складання додатків заголовки та бібліотеки.

Ставимо CUDA Toolkit

Йдемо по вищенаведеної посиланням і викачуємо CUDA Toolkit для Linux (вибрати можна з декількох версій, для дистрибутивів Fedora, RHEL, Ubuntu і SUSE, є версії як для архітектури x86, так і для x86_64). Крім того, там же треба скачати комплекти драйверів для розробників (Developer Drivers for Linux, вони йдуть першими в списку).

Запускаємо інсталятор SDK:

$ Sudo sh cudatoolkit_4.0.17_linux_64_ubuntu10.10.run

Коли установка буде завершена, приступаємо до установки драйверів. Для цього завершуємо роботу X-сервера:

# Sudo /etc/init.d/gdm stop

Відкриваємо консоль <Ctrl + Alt + F5> і запускаємо інсталятор драйверів:

$ Sudo sh devdriver_4.0_linux_64_270.41.19.run

Після закінчення установки стартуємо ікси:

$ startx

Щоб додаток змогли працювати з CUDA / OpenCL, прописуємо шлях до каталогу з CUDA-бібліотеками в змінну LD_LIBRARY_PATH:

$ Export LD_LIBRARY_PATH = / usr / local / cuda / lib64

Або, якщо ти встановив 32-бітну версію:

$ Export LD_LIBRARY_PATH = / usr / local / cuda / lib32

Також необхідно прописати шлях до заголовків файлів CUDA, щоб компілятор їх знайшов на етапі складання програми:

$ Export C_INCLUDE_PATH = / usr / local / cuda / include

Все, тепер можна приступити до складання CUDA / OpenCL-софта.

Ставимо ATI Stream SDK

Stream SDK не вимагає установки, тому скачаний з сайту AMD-архів можна просто розпакувати в будь-який каталог (найкращим вибором буде / opt) і прописати шлях до нього у всю ту ж змінну LD_LIBRARY_PATH:

$ Wget http://goo.gl/CNCNo
$ Sudo tar -xzf ~ / AMD-APP-SDK-v2.4-lnx64.tgz -C / opt
$ Export LD_LIBRARY_PATH = / opt / AMD-APP-SDK-v2.4-lnx64 / lib / x86_64 /
$ Export C_INCLUDE_PATH = / opt / AMD-APP-SDK-v2.4-lnx64 / include /

Як і у випадку з CUDA Toolkit, x86_64 необхідно замінити на x86 в 32-бітних системах. Тепер переходимо в кореневій каталог і розпаковуємо архів icd-registration.tgz (це свого роду безкоштовний ліцензійний ключ):

$ Sudo tar -xzf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz -С /

Перевіряємо правильність установки / роботи пакета за допомогою інструменту clinfo:

$ /opt/AMD-APP-SDK-v2.4-lnx64/bin/x86_64/clinfo

ImageMagick і OpenCL

Підтримка OpenCL з'явилася в ImageMagick вже досить давно, однак за замовчуванням вона не активована ні в одному дистрибутиві. Тому нам доведеться зібрати IM самостійно з початкових кодів. Нічого складного в цьому немає, все необхідне вже є в SDK, тому збірка не зажадає установки якихось додаткових бібліотек від nVidia або AMD. Отже, викачуємо / розпаковуємо архів з вихідними кодами:

$ Wget http://goo.gl/F6VYV
$ Tar -xjf ImageMagick-6.7.0-0.tar.bz2
$ Cd ImageMagick-6.7.0-0

Далі встановлюємо інструменти збірки:

$ Sudo apt-get install build-essential

Запускаємо конфигуратор і Грепан його висновок на предмет підтримки OpenCL:

$ LDFLAGS = -L $ LD_LIBRARY_PATH ./confi gure | grep -e cl.h -e OpenCL

Правильний результат роботи команди повинен виглядати приблизно так:

checking CL / cl.h usability ... yes
checking CL / cl.h presence ... yes
checking for CL / cl.h ... yes
checking OpenCL / cl.h usability ... no
checking OpenCL / cl.h presence ... no
checking for OpenCL / cl.h ... no
checking for OpenCL library ... -lOpenCL

Словом «yes» повинні бути відзначені або перші три рядки, або другі (або обидва варіанти відразу). Якщо це не так, значить, швидше за все, була неправильно инициализирована змінна C_INCLUDE_PATH. Якщо ж словом «no» відзначена останній рядок, значить, справа в змінної LD_LIBRARY_PATH. Якщо все окей, запускаємо процес складання / установки:

$ Sudo make install clean

Перевіряємо, що ImageMagick дійсно було скомпільовано з підтримкою OpenCL:

$ / Usr / local / bin / convert -version | grep Features
Features: OpenMP OpenCL

Тепер виміряємо отриманий виграш у швидкості. Розробники ImageMagick рекомендують використовувати для цього фільтр convolve:

$ Time / usr / bin / convert image.jpg -convolve '-1, -1, -1, -1, 9, -1, -1, -1, -1' image2.jpg
$ Time / usr / local / bin / convert image.jpg -convolve '-1, -1, -1, -1, 9, -1, -1, -1, -1' image2.jpg

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

FlacCL (Flacuda)

FlacCL - це кодировщик звукових файлів в формат FLAC, вповні в своїй роботі можливості OpenCL. Він входить до складу пакета CUETools для Windows, але завдяки mono може бути використаний і в Linux. Для отримання архіву з кодувальником виконуємо наступну команду:

$ Mkdir flaccl && cd flaccl
$ Wget www.cuetools.net/install/flaccl03.rar

Далі встановлюємо unrar, mono і розпаковуємо архів:

$ Sudo apt-get install unrar mono
$ Unrar x fl accl03.rar

Щоб програма змогла знайти бібліотеку OpenCL, робимо символічне посилання:

$ Ln -s $ LD_LIBRARY_PATH / libOpenCL.so libopencl.so

Тепер запускаємо кодировщик:

$ Mono CUETools.FLACCL.cmd.exe music.wav

Якщо на екран буде виведено повідомлення про помилку «Error: Requested compile size is bigger than the required workgroup size of 32», значить, у нас в системі занадто слабка відеокарта, і кількість задіяних ядер слід скоротити до зазначеного числа за допомогою прапора '-group -size XX ', де XX - потрібну кількість ядер.

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

oclHashcat або брутфорс по-швидкому

Як я вже говорив, одними з перших підтримку GPGPU в свої продукти додали розробники різних крекерів і систем брутфорса паролів. Для них нова технологія стала справжнім святим граалем, який дозволив з легкістю перенести від природи легко распараллелівать код на плечі швидких GPU-процесорів. Тому не дивно, що зараз існують десятки найрізноманітніших реалізацій подібних програм. Але в цій статті я розповім тільки про одну з них - oclHashcat.

oclHashcat - це ломалка, яка вміє підбирати паролі по їх хешу з екстремально високою швидкістю, задіюючи при цьому потужності GPU за допомогою OpenCL. Якщо вірити вимірам, опублікованими на сайті проекту, швидкість підбору MD5-паролів на nVidia GTX580 становить до 15800 млн комбінацій в секунду, завдяки чому oclHashcat здатний знайти середній за складністю восьмісімвольний пароль за якісь 9 хвилин.

Програма підтримує OpenCL і CUDA, алгоритми MD5, md5 ($ pass. $ Salt), md5 (md5 ($ pass)), vBulletin <v3.8.5, SHA1, sha1 ($ pass. $ Salt), хеші MySQL, MD4, NTLM , Domain Cached Credentials, SHA256, підтримує розподілений підбір паролів із задіянням потужності декількох машин.

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

Далі слід розпакувати архів:

$ 7z x oclHashcat-0.25.7z
$ Cd oclHashcat-0.25

І запустити програму (скористаємося пробним списком хеш і пробним словником):

$ ./OclHashcat64.bin example.hash? L? L? L? L example.dict

oclHashcat відкриє текст користувальницької угоди, з яким слід погодитися, набравши «YES». Після цього почнеться процес перебору, прогрес якого можна дізнатися після натискання <s>. Щоб призупинити процес, кнопаем <p>, для відновлення - <r>. Також можна використовувати прямий перебір (наприклад, від aaaaaaaa до zzzzzzzz):

$ ./OclHashcat64.bin hash.txt? L? L? L? L? L? L? L? L

І різні модифікації словника і методу прямого перебору, а також їх комбінації (про це можна прочитати у файлі docs / examples.txt). У моєму випадку швидкість перебору всього словника склала 11 хвилин, тоді як прямий перебір (від aaaaaaaa до zzzzzzzz) тривав близько 40 хвилин. В середньому швидкість роботи GPU (чіп RV710) склала 88,3 млн / с.

висновки

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

Info

• Суть технології GPGPU - довільні обчислення на відкритих.
• Існує OpenCL SDK, що розробляється компанією Intel, але поки з його допомогою можна запускати додатки тільки на класичному CPU.
• FASTRA II - суперкомп'ютер, побудований з використанням 13 відеокарт, потужністю 12TFLOPS.

Links

• bzip2-cuda.github.com - реалізація архиватора bzip2с використанням CUDA.
• www.hoopoe-cloud.com - хмарний сервіс, що дозволяє завантажувати і запускати софт з підтримкою CUDA і OpenCL.