Výpočty zapnuté GPU

Technologie CUDA (Compute Unified Device Architecture) je softwarová a hardwarová architektura, která umožňuje výpočty pomocí GPU NVIDIA s podporou technologie GPGPU (arbitrary computing on video cards). Architektura CUDA se poprvé objevila na trhu s vydáním osmé generace čipu NVIDIA - G80 a je přítomna ve všech následujících sériích grafických čipů, které se používají v rodinách akcelerátorů GeForce, ION, Quadro a Tesla.

CUDA SDK umožňuje programátorům implementovat ve speciálním zjednodušeném dialektu programovacího jazyka C algoritmy, které lze spustit na GPU NVIDIA a zahrnují speciální funkce v textu programu C. CUDA dává vývojáři možnost podle vlastního uvážení organizovat přístup k instrukční sadě grafického akcelerátoru a spravovat jeho paměť, organizovat na něm komplexní paralelní výpočty.

Příběh

V roce 2003 byly Intel a AMD ve společném závodě o nejvíce výkonný procesor. V průběhu let se taktovací frekvence v důsledku tohoto závodu výrazně zvýšila, zejména po vydání Intel Pentium 4.

Po zvýšení taktovacích frekvencí (v letech 2001 až 2003 se taktovací frekvence Pentia 4 zdvojnásobila z 1,5 na 3 GHz) a uživatelé se museli spokojit s desetinovými gigahertzy, které výrobci přinesli na trh (v letech 2003 až 2005 taktovací frekvence zvýšeno o 3 na 3,8 GHz).

Architektury optimalizované pro vysoké takty, jako je Prescott, také začaly mít potíže, a to nejen ve výrobě. Výrobci čipů čelili výzvám při překonávání fyzikálních zákonů. Někteří analytici dokonce předpovídali, že Moorův zákon přestane fungovat. To se ale nestalo. Původní význam zákona je často zkreslen, ale odkazuje na počet tranzistorů na povrchu křemíkového jádra. Na dlouhou dobu zvýšení počtu tranzistorů v CPU bylo doprovázeno odpovídajícím zvýšením výkonu - což vedlo ke zkreslení významu. Pak se ale situace zkomplikovala. Konstruktéři architektury CPU přistoupili na zákon redukce zisku: počet tranzistorů, které bylo potřeba přidat pro žádoucí zvýšení výkonu, byl stále větší, což vedlo do slepé uličky.

Důvod, proč výrobci GPU nečelili tomuto problému, je velmi jednoduchý: CPU jsou navrženy tak, aby dosáhly co nejlepšího výkonu v proudu instrukcí, které zpracovávají různá data (jak celá čísla, tak čísla s pohyblivou řádovou čárkou), provádějí náhodný přístup k paměti atd. d. Až dosud se vývojáři snažili poskytovat větší paralelismus instrukcí – tedy provádět paralelně co nejvíce instrukcí. Tak se například u Pentia objevilo superskalární provádění, kdy za určitých podmínek bylo možné provést dvě instrukce na takt. Pentium Pro obdrželo provedení instrukcí mimo pořadí, což umožnilo optimalizovat výkon výpočetních jednotek. Problém je v tom, že paralelní provádění sekvenčního proudu instrukcí má zjevná omezení, takže slepé zvyšování počtu výpočetních jednotek nepřináší zisk, protože většinu času budou stále nečinné.

Obsluha GPU je poměrně jednoduchá. Skládá se z odebrání skupiny polygonů na jedné straně a generování skupiny pixelů na straně druhé. Polygony a pixely jsou na sobě nezávislé, takže je lze zpracovávat paralelně. V GPU je tak možné alokovat velkou část krystalu pro výpočetní jednotky, které se na rozdíl od CPU skutečně využijí.

GPU se od CPU liší nejen v tomto. Přístup k paměti v GPU je velmi svázaný - pokud je čten texel, pak po několika cyklech bude načten sousední texel; když je zapsán pixel, sousední se zapíše po několika cyklech. Inteligentním uspořádáním paměti můžete dosáhnout výkonu blízkého teoretické šířce pásma. To znamená, že GPU na rozdíl od CPU nevyžaduje velkou mezipaměť, protože jeho úlohou je urychlit operace texturování. Stačí k tomu několik kilobajtů obsahujících několik texelů používaných v bilineárních a trilineárních filtrech.

První výpočty na GPU

Vůbec první pokusy o takovou aplikaci se omezily na použití některých hardwarových funkcí, jako je rasterizace a Z-buffering. Ale v současném století, s příchodem shaderů, začali zrychlovat výpočet matic. V roce 2003 byla SIGGRAPH přidělena samostatná sekce pro GPU computing s názvem GPGPU (General-Purpose computation on GPU).

Nejznámější BrookGPU je kompilátor programovacího jazyka Brook stream, určený k provádění negrafických výpočtů na GPU. Před jeho objevením si vývojáři využívající možnosti video čipů pro výpočty zvolili jedno ze dvou běžných API: Direct3D nebo OpenGL. To vážně omezilo použití GPU, protože 3D grafika používá shadery a textury, o kterých paralelní programátoři nemusí vědět, používají vlákna a jádra. Brook jim mohl pomoci usnadnit jejich úkol. Tato streamovací rozšíření jazyka C vyvinutá na Stanfordské univerzitě skrývala před programátory 3D API a prezentovala video čip jako paralelní koprocesor. Kompilátor analyzoval soubor .br s kódem C++ a rozšířeními a vytvořil kód propojený s knihovnou s podporou DirectX, OpenGL nebo x86.

Vzhled Brooka vzbudil zájem společností NVIDIA a ATI a dále otevřel jejich zcela nový sektor – paralelní počítače založené na video čipech.

Dále se někteří výzkumníci z projektu Brook přesunuli do vývojového týmu NVIDIA, aby představili hardwarově-softwarovou paralelní výpočetní strategii, čímž otevřeli nový podíl na trhu. A hlavní výhodou této iniciativy NVIDIA bylo, že vývojáři dokonale znají všechny možnosti svých GPU do nejmenších detailů a není potřeba používat grafické API a s hardwarem můžete pracovat přímo pomocí ovladače. Výsledkem snažení tohoto týmu je NVIDIA CUDA.

Oblasti použití paralelních výpočtů na GPU

Když je výpočetní výkon přenesen na GPU, v mnoha úlohách je dosaženo 5-30násobné akcelerace ve srovnání s rychlými univerzálními procesory. Největších čísel (řádově 100x zrychlení a ještě více!) je dosaženo na kódu, který není příliš vhodný pro výpočty pomocí bloků SSE, ale je docela vhodný pro GPU.

Toto jsou jen některé příklady zrychlení syntetického kódu na GPU oproti vektorizovanému kódu SSE na CPU (podle NVIDIA):

Fluorescenční mikroskopie: 12x.

Molekulární dynamika (nevazebný výpočet síly): 8-16x;

Elektrostatika (přímá a víceúrovňová coulombovská sumace): 40-120x a 7x.

Tabulka, kterou NVIDIA zobrazuje na všech prezentacích a která ukazuje rychlost GPU vzhledem k CPU.

Seznam hlavních aplikací, ve kterých se GPU computing používá: analýza a zpracování obrazu a signálu, fyzikální simulace, výpočetní matematika, výpočetní biologie, finanční výpočty, databáze, dynamika plynů a kapalin, kryptografie, adaptivní radiační terapie, astronomie, zpracování zvuku, bioinformatika, biologické simulace, počítačové vidění, dolování dat, digitální kino a televize, elektromagnetické simulace, geografické informační systémy, vojenské aplikace, plánování těžby, molekulární dynamika, zobrazování magnetickou rezonancí (MRI), neuronové sítě, oceánografický výzkum, fyzika částic, simulace skládání proteinů, kvantová chemie, sledování paprsků, zobrazování, radar, simulace nádrží, umělá inteligence, satelitní analýza dat, seismický průzkum, chirurgie, ultrazvuk, videokonference.

Výhody a omezení CUDA

Z pohledu programátora je grafický pipeline soubor fází zpracování. Geometrický blok generuje trojúhelníky a rasterizační blok generuje pixely zobrazené na monitoru. Tradiční model programování GPGPU je následující:

Pro přenos výpočtů na GPU v rámci takového modelu je zapotřebí speciální přístup. Dokonce i přidání dvou vektorů prvek po prvku bude vyžadovat nakreslení tvaru na obrazovku nebo do vyrovnávací paměti mimo obrazovku. Obrázek je rastrován, barva každého pixelu je vypočtena podle daného programu (pixel shader). Program načte vstupní data z textur pro každý pixel, sečte je a zapíše do výstupní vyrovnávací paměti. A všechny tyto četné operace jsou potřebné pro to, co je napsáno v jediném operátoru v konvenčním programovacím jazyce!

Proto má použití GPGPU pro obecné výpočty omezení v podobě příliš velké složitosti, kterou se vývojáři nemohou naučit. Ano a dalších omezení je dost, protože pixel shader je jen vzorec pro závislost výsledné barvy pixelu na jeho souřadnicích a jazyk pixel shader je jazyk pro psaní těchto vzorců se syntaxí podobnou C. Rané metody GPGPU jsou chytrým trikem, jak využít sílu GPU, ale bez jakéhokoli pohodlí. Data jsou zde reprezentována obrázky (texturami) a algoritmus je reprezentován rasterizačním procesem. Je třeba poznamenat a velmi specifický model paměti a provádění.

Hardwarová a softwarová architektura NVIDIA pro výpočty na GPU od NVIDIA se liší od předchozích modelů GPGPU tím, že umožňuje psát programy pro GPU v reálném C se standardní syntaxí, ukazateli a nutností minimálního rozšíření pro přístup k výpočetním zdrojům video čipů. CUDA nezávisí na grafických rozhraních API a má některé funkce navržené speciálně pro obecné účely.

Výhody CUDA oproti tradičnímu přístupu k GPGPU počítání

CUDA poskytuje přístup k 16 KB sdílené paměti na multiprocesor, kterou lze použít k organizaci cache s větší šířkou pásma než načítání textur;

Efektivnější přenos dat mezi systémem a video pamětí;

Není potřeba grafických API s redundancí a režií;

Lineární adresování paměti a shromažďování a rozptylování, schopnost zapisovat na libovolné adresy;

Hardwarová podpora celočíselných a bitových operací.

Hlavní omezení CUDA:

Nedostatek podpory rekurze pro spustitelné funkce;

Minimální šířka bloku je 32 vláken;

Uzavřená architektura CUDA vlastněná společností NVIDIA.

Slabiny programování s předchozími metodami GPGPU spočívají v tom, že tyto metody nepoužívají prováděcí jednotky vertex shader v předchozích nesjednocených architekturách, data se ukládají v texturách a vydávají se do vyrovnávací paměti mimo obrazovku a víceprůchodové algoritmy používají jednotky pixel shader. Omezení GPGPU zahrnují: nedostatečně efektivní využití hardwarových schopností, omezení šířky pásma paměti, žádná operace rozptylu (pouze shromažďování), povinné používání grafického API.

Hlavní výhody CUDA oproti předchozím metodám GPGPU vyplývají ze skutečnosti, že je tato architektura navržena efektivní využití negrafické výpočty na GPU a používá programovací jazyk C, aniž by bylo nutné převádět algoritmy do formy vhodné pro koncepci grafického potrubí. CUDA nabízí nová cesta GPU computing, který nepoužívá grafické rozhraní API a nabízí náhodný přístup k paměti (scatter nebo shromažďování). Taková architektura neobsahuje nevýhody GPGPU a využívá všechny prováděcí jednotky a také rozšiřuje možnosti prostřednictvím celočíselné matematiky a operací s bitovým posunem.

CUDA otevírá některé hardwarové funkce, které nejsou dostupné z grafických API, jako je sdílená paměť. Jedná se o malé množství paměti (16 kilobajtů na multiprocesor), ke kterému mají přístup bloky vláken. Umožňuje vám ukládat do mezipaměti vaše nejčastěji používaná data a může poskytnout další vysoká rychlost, ve srovnání s použitím načítání textur pro tento úkol. To zase snižuje propustnost paralelních algoritmů v mnoha aplikacích. Například je užitečný pro lineární algebru, rychlou Fourierovu transformaci a filtry pro zpracování obrazu.

Pohodlnější v CUDA a přístupu k paměti. Programový kód v grafickém API vydává data ve formě 32 s jednoduchou přesností hodnot s plovoucí desetinnou čárkou (hodnoty RGBA současně v osmi vykreslovacích cílech) v předdefinovaných oblastech a CUDA podporuje bodové nahrávání - neomezený počet záznamů na libovolné adrese . Tyto výhody umožňují provádět na GPU některé algoritmy, které nelze efektivně implementovat pomocí metod GPGPU založených na grafickém API.

Grafická rozhraní API také musí ukládat data do textur, což vyžaduje předchozí zabalení velkých polí do textur, což komplikuje algoritmus a nutí použití speciálního adresování. A CUDA umožňuje číst data na jakékoli adrese. Další výhodou CUDA je optimalizovaná komunikace mezi CPU a GPU. A pro vývojáře, kteří chtějí přistupovat k nízké úrovni (například při psaní jiného programovacího jazyka), nabízí CUDA možnost nízkoúrovňového programování v assembleru.

Nevýhody CUDA

Jednou z mála nevýhod CUDA je špatná přenositelnost. Tato architektura funguje pouze na videočipech této společnosti, a ne na všech, ale počínaje řadou GeForce 8 a 9 a odpovídajícími Quadro, ION a Tesla. NVIDIA uvádí číslo 90 milionů video čipů kompatibilních s CUDA.

Alternativy k CUDA

Rámec pro psaní počítačové programy spojené s paralelními výpočty na různých grafických a centrálních procesorech. Rámec OpenCL obsahuje programovací jazyk založený na standardu C99 a aplikační programovací rozhraní (API). OpenCL poskytuje paralelismus na úrovni instrukcí a dat a je implementací techniky GPGPU. OpenCL je zcela otevřený standard a za jeho používání se neplatí žádné licenční poplatky.

Cílem OpenCL je doplnit OpenGL a OpenAL, což jsou otevřené průmyslové standardy pro 3D počítačovou grafiku a zvuk, využitím výkonu GPU. OpenCL vyvíjí a spravuje Khronos Group, neziskové konsorcium, které zahrnuje mnoho významných společností včetně Apple, AMD, Intel, nVidia, Sun Microsystems, Sony Computer Entertainment a dalších.

CAL/IL (výpočetní abstraktní vrstva/středně pokročilý jazyk)

Technologie ATI Stream je sada hardwaru a softwarových technologií, které umožňují používat GPU AMD ve spojení s CPU k akceleraci mnoha aplikací (nejen grafických).

Aplikační oblasti ATI Stream jsou aplikace, které jsou náročné na výpočetní prostředky, jako např finanční analýza nebo zpracování seismických dat. Použití stream procesoru umožnilo zvýšit rychlost některých finančních výpočtů až 55krát ve srovnání s řešením stejného problému pouze pomocí procesor.

NVIDIA nepovažuje technologii ATI Stream za příliš silného konkurenta. CUDA a Stream jsou dvě různé technologie, které jsou na různých úrovních vývoje. Programování pro produkty ATI je mnohem obtížnější - jejich jazyk připomíná spíše assembler. Na druhou stranu CUDA C je jazyk mnohem vyšší úrovně. Psaní na něm je pohodlnější a jednodušší. Pro velké developerské společnosti je to velmi důležité. Pokud mluvíme o výkonu, můžeme vidět, že jeho špičková hodnota u produktů ATI je vyšší než u řešení NVIDIA. Ale opět vše záleží na tom, jak tuto sílu získat.

DirectX11 (DirectCompute)

Rozhraní pro programování aplikací, které je součástí DirectX, sady rozhraní API od společnosti Microsoft, které je navrženo pro spuštění na počítačích kompatibilních s IBM PC operační systémy Rodina Microsoft Windows. DirectCompute je navržen k provádění obecných výpočtů na GPU a je implementací konceptu GPGPU. DirectCompute byl původně publikován jako součást DirectX 11, ale později byl zpřístupněn také pro DirectX 10 a DirectX 10.1.

NVDIA CUDA v ruském vědeckém prostředí.

Od prosince 2009 programovací model CUDA se vyučuje na 269 univerzitách po celém světě. V Rusku se školicí kurzy o CUDA vyučují na univerzitách v Moskvě, Petrohradě, Kazani, Novosibirsku a Permu, Mezinárodní univerzitě přírody společnosti a člověka „Dubna“, Společném institutu pro jaderný výzkum, Moskevském institutu elektroniky Technologie, Ivanovo State Power Engineering University, BSTU. V. G. Shukhova, MSTU im. Bauman, RKhTU im. Mendělejev, Ruské výzkumné centrum „Kurčatovův institut“, Meziregionální superpočítačové centrum Ruské akademie věd, Technologický institut Taganrog (TTI SFedU).

Vlastnosti architektury AMD/ATI Radeon

Je to podobné jako při zrodu nových biologických druhů, kdy se živé bytosti vyvíjejí, aby zlepšily svou adaptabilitu na prostředí během vývoje stanovišť. Podobně GPU, počínaje zrychlenou rasterizací a texturováním trojúhelníků, vyvinuly další schopnosti pro spouštění shader programů pro barvení stejných trojúhelníků. A ukázalo se, že tyto schopnosti jsou žádané v negrafických výpočtech, kde v některých případech poskytují významný nárůst výkonu ve srovnání s tradičními řešeními.

Analogie kreslíme dále – savci po dlouhém vývoji na souši pronikli do moře, odkud vytlačili běžné mořské obyvatele. V konkurenčním boji savci využívali jak nové pokročilé schopnosti, které se objevily na zemském povrchu, tak ty speciálně získané pro adaptaci na život ve vodě. Stejně tak GPU, založené na výhodách architektury pro 3D grafiku, stále více získávají speciální funkce užitečné pro negrafické úlohy.

Co tedy umožňuje GPU uplatnit svůj vlastní sektor v oblasti programů pro všeobecné použití? Mikroarchitektura GPU je postavena velmi odlišně od běžných CPU a od samého začátku má určité výhody. Grafické úlohy zahrnují nezávislé paralelní zpracování dat a GPU je nativně vícevláknové. Ale tato paralelnost je pro něj jen radostí. Mikroarchitektura je navržena tak, aby využívala velkého počtu vláken, která je třeba spustit.

GPU se skládá z několika desítek (30 pro Nvidia GT200, 20 pro Evergreen, 16 pro Fermi) procesorových jader, která se nazývají Streaming Multiprocessor v terminologii Nvidia a SIMD Engine v terminologii ATI. V rámci tohoto článku jim budeme říkat miniprocesory, protože vykonávají několik stovek programových vláken a umí téměř vše, co běžný CPU, ale stále ne všechno.

Marketingové názvy jsou matoucí – pro větší důležitost označují počet funkčních modulů, které lze odečítat a násobit: například 320 vektorových „jader“ (jádra). Tato jádra připomínají spíše zrna. Je lepší si představit GPU jako vícejádrový procesor s mnoha jádry vykonávajícími mnoho vláken současně.

Každý miniprocesor má lokální paměť, 16 KB pro GT200, 32 KB pro Evergreen a 64 KB pro Fermi (v podstatě programovatelná L1 cache). Má podobnou přístupovou dobu jako L1 cache konvenčního CPU a provádí podobné funkce při doručování dat funkčním modulům co nejrychleji. V architektuře Fermi lze část místní paměti nakonfigurovat jako normální mezipaměť. V GPU se místní paměť používá k rychlé výměně dat mezi vykonávajícími vlákny. Jedno z obvyklých schémat pro program GPU je následující: nejprve se do místní paměti načtou data z globální paměti GPU. Toto je jen obyčejná video paměť umístěná (např systémové paměti) odděleně od "vlastního" procesoru - v případě videa je připájen několika mikroobvody na textolitu grafické karty. Dále několik stovek vláken pracuje s těmito daty v místní paměti a zapisuje výsledek do globální paměti, načež je přenesen do CPU. Je na odpovědnosti programátora, aby napsal instrukce pro načítání a vyjímání dat z lokální paměti. V podstatě se jedná o rozdělení dat [konkrétního úkolu] pro paralelní zpracování. GPU také podporuje atomické instrukce pro zápis/čtení do paměti, ale ty jsou neefektivní a obvykle jsou vyžadovány v konečné fázi pro „slepení“ výsledků výpočtů všech miniprocesorů.

Lokální paměť je společná pro všechna vlákna běžící v miniprocesoru, takže např. v terminologii Nvidie se jí dokonce říká sdílená a termín lokální paměť znamená pravý opak, totiž: určitou osobní oblast samostatného vlákna v globálním měřítku paměti, viditelné a přístupné pouze jí. Ale kromě lokální paměti má miniprocesor další paměťovou oblast, ve všech architekturách, asi čtyřikrát větší objem. Je rozdělen rovnoměrně mezi všechna vykonávající vlákna, jedná se o registry pro ukládání proměnných a mezivýsledky výpočtů. Každé vlákno má několik desítek registrů. Přesný počet závisí na tom, kolik vláken miniprocesor běží. Toto číslo je velmi důležité, protože latence globální paměti je velmi vysoká, stovky cyklů a při absenci mezipaměti není kam ukládat mezivýsledky výpočtů.

A ještě jedna důležitá vlastnost GPU: „měkká“ vektorizace. Každý miniprocesor má velké množství výpočetních modulů (8 pro GT200, 16 pro Radeon a 32 pro Fermi), ale mohou provádět pouze stejnou instrukci se stejnou adresou programu. Operandy v tomto případě mohou být různé, různá vlákna mají své vlastní. Například návod přidat obsah dvou registrů: je současně vykonáván všemi výpočetními zařízeními, ale berou se různé registry. Předpokládá se, že všechna vlákna programu GPU, provádějící paralelní zpracování dat, se obecně pohybují v paralelním průběhu programovým kódem. Všechny výpočetní moduly jsou tak zatěžovány rovnoměrně. A pokud se vlákna v důsledku větví v programu rozcházela ve své cestě provádění kódu, dochází k takzvané serializaci. Pak se nepoužívají všechny výpočetní moduly, protože vlákna zasílají k provedení různé instrukce a blok výpočetních modulů může provést, jak jsme již řekli, pouze instrukci s jednou adresou. A samozřejmě výkon zároveň klesá v poměru k maximu.

Výhodou je, že vektorizace je zcela automatická, nejedná se o programování pomocí SSE, MMX a podobně. A samotné GPU si s nesrovnalostmi poradí. Teoreticky je možné psát programy pro GPU bez přemýšlení o vektorové povaze vykonávajících modulů, ale rychlost takového programu nebude příliš vysoká. Nevýhodou je velká šířka vektoru. Je to více než nominální počet funkčních modulů a je to 32 pro GPU Nvidia a 64 pro Radeon. Vlákna jsou zpracovávána v blocích příslušné velikosti. Nvidia nazývá tento blok vláken termínem warp, AMD - wave front, což je totéž. Na 16 výpočetních zařízeních je tedy ve čtyřech cyklech (za předpokladu obvyklé délky instrukce) zpracována „vlnová fronta“ dlouhá 64 vláken. Autor v tomto případě preferuje termín warp, a to z důvodu asociace s námořním pojmem warp, označující lano svázané z kroucených lan. Takže nitě se "kroutí" a tvoří celistvý svazek. „Čelo vlny“ však může být spojeno i s mořem: pokyny přicházejí k ovladačům stejným způsobem, jako se vlny valí jedna za druhou na břeh.

Pokud všechna vlákna pokročila při provádění programu stejně (jsou na stejném místě) a tedy provádějí stejnou instrukci, pak je vše v pořádku, ale pokud ne, zpomaluje se. V tomto případě jsou vlákna ze stejné osnovy nebo čela vlny v programu na různých místech, jsou rozdělena do skupin vláken, které mají stejnou hodnotu čísla instrukce (jinými slovy ukazatel instrukce). A stejně jako dříve, pouze vlákna jedné skupiny jsou vykonávána najednou - všechna provádějí stejnou instrukci, ale s různými operandy. Výsledkem je, že warp se provádí tolikrát, kolikrát je pomalejší, na kolik skupin je rozdělen a na počtu vláken ve skupině nezáleží. I když se skupina skládá pouze z jednoho vlákna, bude stále trvat tak dlouho, než se spustí jako plný warp. V hardwaru je to realizováno maskováním určitých vláken, to znamená, že instrukce se formálně provádějí, ale výsledky jejich provádění se nikde nezaznamenávají a v budoucnu se nepoužívají.

Ačkoli každý miniprocesor (Streaming MultiProcessor nebo SIMD Engine) vykonává instrukce patřící pouze jednomu warpu (hromadě vláken) v jakémkoli daném okamžiku, má několik desítek aktivních warps ve spustitelném fondu. Po provedení instrukcí jednoho warpu miniprocesor nevykoná další v pořadí instrukci vláken tohoto warpu, ale instrukce někoho jiného ve warpu. Ta warp může být v programu na úplně jiném místě, rychlost to neovlivní, protože pouze uvnitř warpu musí být instrukce všech vláken stejné pro provádění plnou rychlostí.

V tomto případě má každý z 20 motorů SIMD čtyři aktivní vlnová čela, každé se 64 vlákny. Každé vlákno je označeno krátkou čarou. Celkem: 64×4×20=5120 vláken

Takže vzhledem k tomu, že každá warp nebo vlna se skládá z 32-64 vláken, má miniprocesor několik stovek aktivních vláken, která se provádějí téměř současně. Níže uvidíme, jaké architektonické výhody slibuje takové množství paralelních vláken, ale nejprve se zamyslíme nad tím, jaká omezení mají miniprocesory, které GPU tvoří.

Hlavní věc je, že GPU nemá zásobník, kam by se daly ukládat parametry funkcí a lokální proměnné. Vzhledem k velkému počtu vláken pro stack prostě není na čipu místo. Vzhledem k tomu, že GPU současně spouští přibližně 10 000 vláken při velikosti zásobníku jednoho vlákna 100 kB, bude celková velikost 1 GB, což se rovná standardnímu množství veškeré video paměti. Navíc neexistuje způsob, jak umístit zásobník jakékoli významné velikosti do samotného jádra GPU. Pokud například vložíte 1000 bajtů zásobníku na vlákno, pak pouze jeden miniprocesor bude vyžadovat 1 MB paměti, což je téměř pětinásobek celkového množství místní paměti miniprocesoru a paměti přidělené pro ukládání registrů.

Proto v programu GPU neexistuje žádná rekurze a s voláním funkcí se opravdu nemůžete otočit. Všechny funkce jsou přímo dosazeny do kódu při kompilaci programu. To omezuje rozsah GPU na výpočetní úlohy. Někdy je možné použít omezenou emulaci zásobníku pomocí globální paměti pro rekurzivní algoritmy se známou malou hloubkou iterace, ale nejedná se o typickou aplikaci GPU. K tomu je potřeba speciálně vyvinout algoritmus, prozkoumat možnosti jeho implementace bez záruky úspěšné akcelerace oproti CPU.

Fermi nejprve představil možnost používat virtuální funkce, ale opět je jejich použití omezeno nedostatkem velké a rychlé mezipaměti pro každé vlákno. 1536 vláken představuje 48 KB nebo 16 KB L1, to znamená, že virtuální funkce v programu lze používat relativně zřídka, jinak bude zásobník používat také pomalou globální paměť, což zpomalí provádění a pravděpodobně nepřinese výhody ve srovnání na verzi CPU.

GPU je tedy prezentováno jako výpočetní koprocesor, do kterého se načtou data, zpracují je nějakým algoritmem a vznikne výsledek.

Výhody architektury

Ale považuje GPU za velmi rychlý. A v tom mu pomáhá jeho vysoký multithreading. Velký počet aktivních vláken umožňuje částečně skrýt velkou latenci samostatně umístěné globální videopaměti, která je asi 500 cyklů. Vyrovnává se zvláště dobře pro kód s vysokou hustotou. aritmetické operace. Není tedy vyžadována hierarchie mezipaměti L1-L2-L3, která je drahá na tranzistory. Místo toho lze na čip umístit mnoho výpočetních modulů, které poskytují vynikající aritmetický výkon. Mezitím se provádějí instrukce jednoho vlákna nebo warpu, další stovky vláken tiše čekají na svá data.

Fermi představil cache druhé úrovně o velikosti cca 1 MB, ale s cachemi moderních procesorů se nedá srovnávat, je určena spíše pro komunikaci mezi jádry a různé softwarové triky. Pokud se jeho velikost rozdělí mezi všechny desítky tisíc vláken, bude mít každé velmi zanedbatelné množství.

Ale kromě latence globální paměti je v počítačovém zařízení mnohem více latencí, které je třeba skrýt. Jedná se o latenci přenosu dat v rámci čipu z výpočetních zařízení do mezipaměti první úrovně, tedy místní paměti GPU, a do registrů a také do mezipaměti instrukcí. Registrový soubor, stejně jako lokální paměť, jsou umístěny odděleně od funkčních modulů a rychlost přístupu k nim je zhruba tucet cyklů. A opět velké množství vláken, aktivních warps, dokáže tuto latenci efektivně skrýt. Navíc celková šířka pásma (šířka pásma) přístupu k lokální paměti celého GPU, s přihlédnutím k počtu miniprocesorů, které ji tvoří, je mnohem větší než šířka pásma přístupu k mezipaměti první úrovně u moderních CPU. GPU dokáže zpracovat podstatně více dat za jednotku času.

Okamžitě můžeme říci, že pokud GPU nebude vybaveno velkým množstvím paralelních vláken, pak bude mít téměř nulový výkon, protože bude pracovat stejným tempem, jako by bylo plně vytížené, a odvede mnohem méně práce. Například ať místo 10 000 zůstane jen jedno vlákno: výkon klesne asi tisíckrát, protože nejen že se nenačtou všechny bloky, ale ovlivní to i všechny latence.

Problém skrývání latencí je akutní i u moderních vysokofrekvenčních CPU, k jeho odstranění se používají sofistikované metody - deep pipelining, provádění instrukcí mimo pořadí (out-of-order). To vyžaduje složité plánovače provádění instrukcí, různé vyrovnávací paměti atd., které zabírají místo na čipu. To vše je nutné pro nejlepší výkon v režimu s jedním vláknem.

Ale pro GPU to vše není nutné, pro výpočetní úlohy s velkým počtem vláken je architektonicky rychlejší. Místo toho převádí multithreading na výkon, jako když kámen mudrců proměňuje olovo ve zlato.

GPU byl původně navržen tak, aby optimálně spouštěl shader programy pro trojúhelníkové pixely, které jsou samozřejmě nezávislé a mohou být spouštěny paralelně. A z tohoto stavu se vyvinul přidáním různých funkcí (lokální paměť a adresovatelný přístup k videopaměti, stejně jako zkomplikování instrukční sady) ve velmi výkonné výpočetní zařízení, které lze stále efektivně použít pouze pro algoritmy, které umožňují vysoce paralelní implementaci. pomocí omezeného množství místní paměti.

Příklad

Jedním z nejklasičtějších problémů GPU je problém výpočtu interakce N těles, která vytvářejí gravitační pole. Pokud ale například potřebujeme spočítat vývoj systému Země-Měsíc-Slunce, pak je pro nás GPU špatným pomocníkem: objektů je málo. Pro každý objekt je nutné spočítat interakce se všemi ostatními objekty a ty jsou pouze dva. V případě pohybu sluneční soustavy se všemi planetami a jejich měsíci (asi pár stovek objektů) je GPU stále málo efektivní. Vícejádrový procesor však kvůli vysokým režijním nákladům na správu vláken také nebude schopen předvést všechnu svou sílu, bude pracovat v jednovláknovém režimu. Pokud ale potřebujete vypočítat i trajektorie komet a objektů v pásu asteroidů, pak je to již úkol pro GPU, protože objektů je dostatek pro vytvoření požadovaného počtu paralelních výpočtových vláken.

GPU bude také fungovat dobře, pokud je nutné vypočítat srážku kulových hvězdokup o stovkách tisíc hvězd.

Další příležitost, jak využít sílu GPU v problému N-těl, se objeví, když potřebujete spočítat mnoho jednotlivých problémů, byť s malým počtem těl. Například, pokud chcete vypočítat vývoj jednoho systému pro různé možnosti počátečních rychlostí. Pak bude možné efektivně využívat GPU bez problémů.

Detaily mikroarchitektury AMD Radeon

Zvážili jsme základní principy organizace GPU, jsou společné pro video akcelerátory všech výrobců, protože zpočátku měly jeden cílový úkol - shader programy. Výrobci však zjistili, že je možné se neshodnout na detailech implementace mikroarchitektury. Ačkoli CPU různých výrobců jsou někdy velmi odlišné, i když jsou kompatibilní, jako je Pentium 4 a Athlon nebo Core. Architektura Nvidie je již všeobecně známá, nyní se podíváme na Radeon a vyzdvihneme hlavní rozdíly v přístupech těchto prodejců.

Grafické karty AMD získaly plnou podporu pro obecné výpočty již od rodiny Evergreen, která byla také průkopníkem specifikace DirectX 11. Karty rodiny 47xx mají řadu významných omezení, o kterých bude řeč níže.

Rozdíly ve velikosti lokální paměti (32 KB u Radeonu oproti 16 KB u GT200 a 64 KB u Fermi) obecně nejsou zásadní. Stejně jako velikost čela vlny 64 vláken pro AMD oproti 32 vláknům na warp pro Nvidii. Téměř každý program GPU lze snadno překonfigurovat a vyladit na tyto parametry. Výkon se může měnit o desítky procent, ale v případě GPU to není tak důležité, protože program GPU obvykle běží desetkrát pomaleji než jeho protějšek pro CPU, nebo desetkrát rychleji, nebo nefunguje vůbec.

Důležitější je použití Technologie AMD VLIW (Velmi dlouhé instrukční slovo). Nvidia používá skalární jednoduché instrukce, které fungují na skalárních registrech. Jeho akcelerátory implementují jednoduchý klasický RISC. Grafické karty AMD mají stejný počet registrů jako GT200, ale registry jsou 128bitové vektorové. Každá instrukce VLIW pracuje na několika čtyřsložkových 32bitových registrech, což je podobné SSE, ale možnosti VLIW jsou mnohem širší. Toto není SIMD (Single Instruction Multiple Data) jako SSE - zde mohou být instrukce pro každý pár operandů různé a dokonce závislé! Nechť se například složky registru A jmenují a1, a2, a3, a4; pro registr B - obdobně. Lze vypočítat pomocí jediné instrukce, která se provede v jednom cyklu, například číslo a1×b1+a2×b2+a3×b3+a4×b4 nebo dvourozměrný vektor (a1×b1+a2×b2, a3× b3+a4×b4).

To bylo možné díky nižší frekvenci GPU než CPU a výraznému snížení technických procesů v minulé roky. To nevyžaduje žádný plánovač, téměř vše se provádí za hodiny.

S vektorovými instrukcemi je špičkový výkon Radeonu s jedinou přesností velmi vysoký, na teraflopech.

Jeden vektorový registr může uložit jedno číslo s dvojnásobnou přesností místo čtyř jednoduchých čísel s přesností. A jedna instrukce VLIW může buď sečíst dva páry dvojic, nebo vynásobit dvě čísla, nebo vynásobit dvě čísla a přidat ke třetímu. Špičkový výkon v double je tedy asi pětkrát nižší než v float. U starších modelů Radeon odpovídá Výkon Nvidia Tesla na nové architektuře Fermi a mnohem vyšším výkonem než dvojité karty na architektuře GT200. U spotřebitelských grafických karet Geforce založených na Fermi byla maximální rychlost dvojnásobných výpočtů snížena čtyřikrát.

Schematické schéma práce Radeonu. Je zobrazen pouze jeden miniprocesor z 20 běžících paralelně

Výrobci GPU, na rozdíl od výrobců CPU (především těch kompatibilních s x86), nejsou vázáni problémy s kompatibilitou. Program GPU je nejprve zkompilován do nějakého přechodného kódu, a když je program spuštěn, ovladač zkompiluje tento kód do strojových instrukcí specifických pro konkrétní model. Jak je popsáno výše, výrobci GPU toho využili tím, že pro své GPU vynalezli pohodlnou architekturu ISA (Instruction Set Architecture) a měnili je z generace na generaci. V každém případě to přidalo nějaké procento výkonu kvůli chybějícímu (jako zbytečnému) dekodéru. AMD ale šlo ještě dál a vynalezlo vlastní formát pro uspořádání instrukcí ve strojovém kódu. Nejsou uspořádány sekvenčně (podle výpisu programu), ale v sekcích.

Nejprve přichází sekce instrukcí podmíněného skoku, které mají odkazy na sekce souvislých aritmetických instrukcí odpovídajících různým větvím. Říká se jim svazky VLIW (balíčky instrukcí VLIW). Tyto sekce obsahují pouze aritmetické instrukce s daty z registrů nebo lokální paměti. Taková organizace zjednodušuje tok pokynů a jejich doručování prováděcím jednotkám. To je o to užitečnější, že instrukce VLIW jsou relativně velké. Jsou zde také sekce pro pokyny pro přístup do paměti.

GPU od obou výrobců (Nvidia i AMD) mají také vestavěné instrukce pro rychlý výpočet základních matematických funkcí, odmocnina, exponent, logaritmy, sinusy a kosinusy pro jednotlivá čísla s přesností v několika cyklech. K tomu existují speciální výpočetní bloky. „Vzešly“ z potřeby implementovat rychlou aproximaci těchto funkcí v geometry shaderech.

I kdyby někdo nevěděl, že GPU se používají pro grafiku, a seznámil se pouze s technickými vlastnostmi, pak podle tohoto znamení mohl tušit, že tyto výpočetní koprocesory pocházejí z video akcelerátorů. Podobně některé rysy mořských savců vedly vědce k domněnce, že jejich předci byli suchozemští tvorové.

Ale zjevnější vlastností, která prozrazuje grafický původ zařízení, jsou bloky pro čtení dvourozměrných a trojrozměrných textur s podporou bilineární interpolace. Jsou široce používány v programech GPU, protože poskytují rychlejší a snadnější čtení datových polí pouze pro čtení. Jeden z standardní možnosti Aplikace GPU se chová tak, že čte pole počátečních dat, zpracuje je ve výpočetních jádrech a výsledek zapíše do jiného pole, které se pak přenese zpět do CPU. Takové schéma je standardní a běžné, protože je vhodné pro architekturu GPU. Úlohy, které vyžadují intenzivní čtení a zápis do jedné velké oblasti globální paměti, tedy obsahující datové závislosti, je obtížné paralelizovat a efektivně implementovat na GPU. Také jejich výkon bude velmi záviset na latenci globální paměti, která je velmi velká. Ale pokud je úkol popsán vzorem „čtení dat – zpracování – zápis výsledku“, pak téměř jistě můžete získat velkou podporu z jeho provádění na GPU.

Pro texturová data v GPU existuje samostatná hierarchie malých mezipamětí první a druhé úrovně. Poskytuje také zrychlení díky použití textur. Tato hierarchie se původně objevila v GPU za účelem využití místa přístupu k texturám: samozřejmě po zpracování jednoho pixelu bude sousední pixel (s vysokou pravděpodobností) vyžadovat data textury s úzkým odstupem. Ale mnoho algoritmů pro konvenční výpočty má podobnou povahu přístupu k datům. Takže texturové cache z grafiky budou velmi užitečné.

Přestože je velikost L1-L2 cache u karet Nvidia a AMD přibližně stejná, což je evidentně způsobeno požadavky na optimalitu z hlediska herní grafiky, latence přístupu k těmto cache se výrazně liší. Přístupová latence Nvidie je vyšší a mezipaměti textur v Geforce pomáhají především snižovat zatížení paměťové sběrnice, než aby přímo zrychlovaly přístup k datům. To není patrné v grafických programech, ale je důležité pro programy pro všeobecné použití. V Radeonu je latence texturové cache nižší, ale latence lokální paměti miniprocesorů je vyšší. Zde je příklad: pro optimální násobení matice na kartách Nvidia je lepší použít místní paměť, načítat tam matici blok po bloku a pro AMD je lepší se spolehnout na mezipaměť textur s nízkou latencí, číst prvky matice jako potřeboval. Ale to je již poměrně jemná optimalizace a pro algoritmus, který již byl zásadně přenesen na GPU.

Tento rozdíl se také projevuje při použití 3D textur. Jeden z prvních výpočetních benchmarků GPU, který ukázal vážnou výhodu pro AMD, právě používal 3D textury, protože pracoval s trojrozměrným datovým polem. A latence přístupu k texturám v Radeonu je výrazně rychlejší a 3D pouzdro je navíc hardwarově optimalizovanější.

Pro získání maximálního výkonu z hardwaru různých společností je potřeba nějaké vyladění aplikace pro konkrétní kartu, ale je to řádově méně významné než v zásadě vývoj algoritmu pro architekturu GPU.

Omezení řady Radeon 47xx

V této rodině je podpora pro výpočty GPU neúplná. Tam jsou tři důležité momenty. Za prvé neexistuje žádná místní paměť, to znamená, že je tam fyzicky, ale nemá univerzální přístup požadovaný moderním standardem programů GPU. Je programově emulován v globální paměti, což znamená, že nebude mít prospěch z jeho použití na rozdíl od plně vybaveného GPU. Druhým bodem je omezená podpora pro různé instrukce pro operace s atomickou pamětí a instrukce pro synchronizaci. A třetí bod je v pořádku malá velikost instrukční mezipaměť: od určité velikosti programu se rychlost několikrát zpomalí. Existují i ​​další drobná omezení. Můžeme říci, že na této grafické kartě budou dobře fungovat pouze programy, které jsou ideálně vhodné pro GPU. Přestože grafická karta může vykazovat dobré výsledky v gigaflopech v jednoduchých testovacích programech, které pracují pouze s registry, je problematické pro ni efektivně naprogramovat něco složitého.

Výhody a nevýhody Evergreenu

Pokud srovnáme produkty AMD a Nvidia, pak z hlediska GPU počítání vypadá řada 5xxx jako velmi výkonná GT200. Tak silný, že předčí Fermiho ve špičkovém výkonu asi dvaapůlkrát. Zejména po ořezání parametrů nových grafických karet Nvidia došlo ke snížení počtu jader. Ale vzhled L2 cache ve Fermi zjednodušuje implementaci některých algoritmů na GPU, čímž rozšiřuje rozsah GPU. Zajímavé je, že pro dobře optimalizované programy GT200 CUDA předchozí generace Fermiho architektonické inovace často neudělaly nic. Zrychlovaly se úměrně s nárůstem počtu výpočetních modulů, tedy méně než dvakrát (pro jednotlivá čísla s přesností), nebo ještě méně, protože se nezvětšila šířka pásma paměti (nebo z jiných důvodů).

A v úlohách, které dobře sedí na architektuře GPU a mají výraznou vektorovou povahu (například násobení matic), Radeon ukazuje výkon relativně blízko teoretickému vrcholu a předbíhá Fermiho. O vícejádrových CPU ani nemluvě. Zejména v problémech s jednoduchými čísly s přesností.

Radeon má ale menší plochu matrice, menší rozptyl tepla, spotřebu energie, vyšší výtěžnost a v důsledku toho nižší náklady. A přímo v problémech 3D grafiky je zisk Fermi, pokud existuje, mnohem menší než rozdíl v oblasti krystalu. To je z velké části způsobeno tím, že výpočetní architektura Radeonu se 16 výpočetními jednotkami na miniprocesor, 64vláknovou vlnovou frontou a vektorovými instrukcemi VLIW je perfektní pro svůj hlavní úkol – výpočet grafických shaderů. Pro drtivou většinu běžní uživatelé Herní výkon a cena jsou prioritou.

Z pohledu profesionálních, vědeckých programů poskytuje architektura Radeon nejlepší poměr ceny a výkonu, výkon na watt a absolutní výkon v úlohách, které v zásadě dobře zapadají do architektury GPU, umožňují paralelizaci a vektorizaci.

Například v plně paralelním, snadno vektorizovatelném problému s výběrem klíčů je Radeon několikrát rychlejší než Geforce a několik desítekkrát rychlejší než CPU.

To odpovídá obecné koncepci AMD Fusion, podle které by GPU měly doplňovat CPU, a v budoucnu být integrovány do samotného jádra CPU, stejně jako byl dříve matematický koprocesor převeden ze samostatného čipu do jádra procesoru (to se stalo asi před dvaceti lety, než se objevily první procesory Pentium). GPU bude integrováno grafické jádro a vektorový koprocesor pro úlohy streamování.

Radeon používá složitou techniku ​​míchání instrukcí z různých vlnových front, když jsou prováděny funkčními moduly. To je snadné, protože pokyny jsou zcela nezávislé. Princip je podobný zřetězenému provádění nezávislých instrukcí moderními CPU. Zjevně to umožňuje efektivně provádět složité, vícebajtové vektorové instrukce VLIW. Na CPU to vyžaduje sofistikovaný plánovač pro identifikaci nezávislých instrukcí nebo použití technologie Hyper-Threading, která také dodává CPU známé nezávislé instrukce z různých vláken.

128 instrukcí dvou vlnových čel, z nichž každá se skládá ze 64 operací, vykonává 16 modulů VLIW v osmi cyklech. Dochází ke střídání a každý modul má ve skutečnosti dva cykly k provedení celé instrukce, za předpokladu, že ve druhém cyklu začne paralelně provádět novou. To pravděpodobně pomáhá rychle provést instrukci VLIW jako a1×a2+b1×b2+c1×c2+d1×d2, to znamená provést osm takových instrukcí v osmi cyklech. (Formálně se ukazuje, jedna na hodiny.)

Nvidia tuto technologii zřejmě nemá. A při absenci VLIW vyžaduje vysoký výkon pomocí skalárních instrukcí vysokou frekvenci provozu, což automaticky zvyšuje odvod tepla a klade vysoké nároky na proces (aby obvod přinutil běžet na vyšší frekvenci).

Nevýhodou Radeonu z hlediska GPU computingu je velká nechuť k větvení. GPU obecně neupřednostňují větvení kvůli výše uvedené technologii pro provádění instrukcí: okamžitě skupinou vláken s jednou adresou programu. (Mimochodem, tato technika se nazývá SIMT: Single Instruction - Multiple Threads (jedna instrukce - mnoho vláken), analogicky se SIMD, kde jedna instrukce provádí jednu operaci s různými daty.) . Je jasné, že pokud program není zcela vektorový, pak čím větší je velikost čela warpu nebo vlny, tím hůře, protože když se cesta programem rozchází, tvoří se sousední vlákna více skupin, který musí být prováděn sekvenčně (serializován). Řekněme, že se všechna vlákna rozptýlila, pak v případě velikosti warpu 32 vláken poběží program 32krát pomaleji. A v případě velikosti 64 je stejně jako v Radeonu 64x pomalejší.

Jde o znatelný, nikoli však jediný projev „nechuti“. U grafických karet Nvidia má každý funkční modul, jinak nazývaný jádro CUDA, speciální jednotku pro zpracování větví. A ve grafických kartách Radeon pro 16 výpočetních modulů jsou pouze dvě větvené řídicí jednotky (jsou odvozeny z oblasti aritmetických jednotek). Takže i jednoduché zpracování instrukce podmíněného větvení, i když je její výsledek stejný pro všechna vlákna na vlnové frontě, zabere více času. A rychlost klesá.

AMD také vyrábí CPU. Domnívají se, že pro programy se spoustou větví je CPU stále vhodnější a GPU je určeno pro čistě vektorové programy.

Radeon tedy poskytuje celkově méně efektivní programování, ale v mnoha případech lepší poměr ceny a výkonu. Jinými slovy, existuje méně programů, které lze efektivně (výhodně) migrovat z CPU na Radeon, než programů, které lze efektivně provozovat na Fermi. Ale na druhou stranu ty, které lze efektivně přenést, budou na Radeonu v mnoha ohledech fungovat efektivněji.

API pro GPU Computing

oni sami Technické specifikace Radeon vypadá atraktivně, i když není nutné idealizovat a absolutizovat GPU computing. Ale neméně důležitý pro výkon je software nezbytný pro vývoj a spouštění programu GPU – kompilátory z vysokoúrovňového jazyka a run-time, tedy ovladač, který interaguje mezi částí programu běžícího na CPU a GPU. sám. Je to ještě důležitější než v případě CPU: CPU nepotřebuje ovladač ke správě přenosu dat a z pohledu kompilátoru je GPU vybíravější. Kompilátor si například musí vystačit s minimálním počtem registrů pro ukládání mezivýsledků výpočtů a také úhledně vkládaných volání funkcí, opět s použitím minima registrů. Koneckonců, čím méně registrů vlákno používá, tím více vláken můžete spustit a tím plněji zatížit GPU, lépe skryjete dobu přístupu do paměti.

A tak softwarová podpora produktů Radeon stále zaostává za vývojem hardwaru. (Na rozdíl od situace s Nvidií, kde se vydání hardwaru opozdilo a produkt byl vydán ve stažené podobě.) Nedávno byl kompilátor OpenCL od AMD ve stavu beta s mnoha nedostatky. Příliš často generoval chybný kód nebo odmítal kód zkompilovat ze správného zdrojového kódu nebo sám hlásil chybu a havaroval. Teprve na konci jara přišlo vydání s vysokým výkonem. Bez chyb to také není, ale je jich podstatně méně a zpravidla se objevují na okraji při pokusu o naprogramování něčeho na hranici správnosti. Pracují například s typem uchar4, který specifikuje 4bajtovou čtyřsložkovou proměnnou. Tento typ je ve specifikacích OpenCL, ale na Radeonu se s ním nevyplatí pracovat, protože registry jsou 128bitové: stejné čtyři komponenty, ale 32bitové. A taková proměnná uchar4 stejně zabere celý registr, jen další operace balení a přístupu k jednotlivým byte komponentům budou stále potřeba. Kompilátor by neměl mít žádné chyby, ale neexistují žádné kompilátory bez chyb. Dokonce i kompilátor Intel po 11 verzích má chyby při kompilaci. Identifikované chyby jsou opraveny v příštím vydání, které bude vydáno blíže k podzimu.

Ale stále je spousta věcí, které je potřeba zlepšit. Například až dosud standardní ovladač GPU pro Radeon nepodporuje výpočty GPU pomocí OpenCL. Uživatel si musí stáhnout a nainstalovat další speciální balíček.

Nejdůležitější je ale absence jakýchkoliv knihoven funkcí. Pro reálná čísla s dvojitou přesností neexistuje ani sinus, kosinus a exponent. No, pro sčítání/násobení matic to není nutné, ale pokud chcete naprogramovat něco složitějšího, musíte všechny funkce napsat od začátku. Nebo počkejte na nové vydání SDK. ACML bude brzy vydáno ( AMD jádro Math Library) pro rodinu Evergreen GPU s podporou základních maticových funkcí.

V tuto chvíli se podle autora článku použití Direct Compute 5.0 API jeví jako reálné pro programování grafických karet Radeon, samozřejmě s ohledem na omezení: orientaci na platformu Windows 7 a Windows Vista. Microsoft má s výrobou kompilátorů bohaté zkušenosti a velmi brzy můžeme očekávat plně funkční vydání, Microsoft se o to přímo zajímá. Direct Compute je ale zaměřen na potřeby interaktivních aplikací: něco spočítat a okamžitě vizualizovat výsledek – například proudění kapaliny po povrchu. To neznamená, že jej nelze jednoduše použít pro výpočty, ale není to jeho přirozený účel. Microsoft například neplánuje do Direct Compute přidávat funkce knihoven – přesně ty, které AMD v tuto chvíli nemá. Tedy to, co lze nyní efektivně spočítat na Radeonu – některé nepříliš sofistikované programy – lze implementovat i na Direct Compute, který je mnohem jednodušší než OpenCL a měl by být stabilnější. Navíc je zcela přenosný a poběží na Nvidii i AMD, takže budete muset program zkompilovat pouze jednou, zatímco implementace OpenCL SDK od Nvidie a AMD nejsou přesně kompatibilní. (V tom smyslu, že pokud vyvíjíte OpenCL program na systému AMD s použitím AMD OpenCL SDK, nemusí na Nvidii běžet tak snadno. Možná budete muset zkompilovat stejný text pomocí Nvidia SDK. A naopak, samozřejmě. )

Pak je v OpenCL spousta redundantních funkcí, protože OpenCL má být univerzálním programovacím jazykem a API pro širokou škálu systémů. A GPU, CPU a Cell. Takže v případě, že chcete pouze napsat program pro typický uživatelský systém (procesor plus grafická karta), nezdá se, že by OpenCL bylo takříkajíc „vysoce produktivní“. Každá funkce má deset parametrů a devět z nich musí být nastaveno na 0. A abyste mohli nastavit každý parametr, musíte zavolat speciální funkci, která má také parametry.

A nejdůležitější současnou výhodou Direct Compute je, že uživatel nemusí instalovat speciální balíček: vše, co je potřeba, je již v DirectX 11.

Problémy vývoje GPU computingu

Vezmeme-li oblast osobních počítačů, pak je situace následující: není mnoho úloh, které vyžadují velký výpočetní výkon a v běžném dvoujádrovém procesoru výrazně chybí. Vypadalo to, jako by se z moře na pevninu vyškrábala velká nenasytná, ale nemotorná monstra a na souši nebylo téměř co jíst. A prapůvodní sídla zemského povrchu se zmenšují, učí se méně spotřebovávat, jak se to děje vždy, když je nedostatek přírodních zdrojů. Pokud by dnes existovala stejná potřeba výkonu jako před 10–15 lety, výpočetní technika GPU by byla přijata s třeskem. A tak se do popředí dostávají problémy s kompatibilitou a relativní složitostí programování GPU. Je lepší napsat program, který běží na všech systémech, než program, který je rychlý, ale běží pouze na GPU.

Vyhlídky pro GPU jsou o něco lepší, pokud jde o použití v profesionálních aplikacích a sektoru pracovních stanic, protože je zde větší poptávka po výkonu. Objevují se pluginy pro 3D editory s podporou GPU: například pro vykreslování s ray tracingem - nezaměňovat s běžným vykreslováním GPU! Něco se ukazuje i pro 2D a prezentační editory, s rychlejší tvorbou komplexních efektů. Programy pro zpracování videa také postupně získávají podporu pro GPU. Výše uvedené úlohy se s ohledem na jejich paralelní povahu dobře hodí na architekturu GPU, ale nyní byla vytvořena velmi rozsáhlá kódová základna, která byla odladěna a optimalizována pro všechny možnosti CPU, takže bude chvíli trvat, než se objeví dobré implementace GPU.

V tomto segmentu se projevují i ​​takové slabiny GPU, jako je omezené množství video paměti – cca 1 GB u běžných GPU. Jedním z hlavních faktorů, které snižují výkon programů GPU, je nutnost výměny dat mezi CPU a GPU po pomalé sběrnici a kvůli omezenému množství paměti se musí přenášet více dat. A tady vypadá koncept AMD spojení GPU a CPU v jednom modulu slibně: můžete obětovat velkou šířku pásma grafické paměti pro snadný a jednoduchý přístup ke sdílené paměti, navíc s nižší latencí. Tato velká šířka pásma současné videopaměti DDR5 je mnohem více žádaná přímo grafické programy než většina výpočetních programů GPU. Obvykle, Společná paměť GPU a CPU prostě výrazně rozšíří pole působnosti GPU, umožní využít jeho výpočetní schopnosti v malých dílčích úlohách programů.

A nejvíce ze všech GPU jsou žádané v oblasti vědeckých výpočtů. Již bylo postaveno několik superpočítačů na bázi GPU, které vykazují velmi vysoké výsledky v testu maticových operací. Vědecké problémy jsou tak rozmanité a četné, že vždy existuje sada, která dokonale zapadá do architektury GPU, pro kterou použití GPU usnadňuje dosažení vysokého výkonu.

Pokud si mezi všemi úkoly moderních počítačů vyberete jeden, pak to bude počítačová grafika – obraz světa, ve kterém žijeme. A architektura optimální pro tento účel nemůže být špatná. To je tak důležitý a zásadní úkol, že hardware pro něj speciálně navržený musí být univerzální a optimální pro různé úkoly. Kromě toho se grafické karty úspěšně vyvíjejí.

Jeden z nejvíce skryté funkce, v nedávné aktualizaci Windows 10, je možnost zkontrolovat, které aplikace používají vaši grafickou procesorovou jednotku (GPU). Pokud jste někdy otevřeli Správce úloh, pravděpodobně jste se podívali na využití procesoru, abyste zjistili, které aplikace jsou nejnáročnější na procesor. V poslední aktualizace přidána podobná funkce, ale pro GPU GPU. Pomáhá pochopit, jak intenzivní je váš software a hry na GPU, aniž byste museli stahovat software třetích stran. Existuje další zajímavá funkce, která pomáhá přenést váš CPU na GPU. Doporučuji přečíst, jak si vybrat.

Proč nemám GPU ve Správci úloh?

Bohužel ne všechny grafické karty budou schopny poskytnout Windows statistiky, které potřebuje ke čtení GPU. Pro jistotu můžete tuto technologii rychle otestovat pomocí diagnostického nástroje DirectX.

1. Klikněte na " Start“ a do vyhledávání napište dxdiag spustit Diagnostický nástroj DirectX.
2. Přejít na kartu " Obrazovka", přímo ve sloupci Řidiči"měl bys mít model WDDM verze vyšší než 2.0 pro použití grafů GPU ve správci úloh.

Povolte graf GPU ve Správci úloh

Chcete-li zobrazit využití GPU pro jednotlivé aplikace, musíte otevřít Správce úloh.

• Stiskněte kombinaci tlačítek Ctrl + Shift + Esc otevřete Správce úloh.
• Klikněte klikněte pravým tlačítkem myši klikněte ve správci úloh na prázdné pole " Název" a zkontrolujte z rozbalovací nabídky GPU. Můžete také poznamenat GPU jádro abyste viděli, které programy jej používají.
• Nyní ve správci úloh jsou vpravo vidět graf GPU a jádro GPU.

Zobrazit celkový výkon GPU

Můžete sledovat celkové využití GPU pro sledování a analýzu při velkém zatížení. V tomto případě můžete vidět vše, co potřebujete v " Výkon“ výběrem grafický procesor.

Každý prvek GPU je rozdělen do jednotlivých grafů, abyste získali ještě lepší přehled o tom, jak je vaše GPU využíváno. Pokud chcete změnit zobrazené grafy, můžete kliknout na malou šipku vedle názvu každého úkolu. Tato obrazovka také zobrazuje verzi a datum vašeho ovladače, což je dobrá alternativa k použití DXDiag nebo Správce zařízení.

Nikdy není moc jader...

Moderní GPU jsou monstrózní rychlé bestie schopné žvýkat gigabajty dat. Člověk je však mazaný a bez ohledu na to, jak roste výpočetní výkon, přichází s úkoly stále obtížnějšími, takže přichází chvíle, kdy musíte se smutkem konstatovat, že je potřeba optimalizace 🙁

Tento článek popisuje základní pojmy, aby se usnadnila orientace v teorii gpu-optimalizace a základní pravidla, aby se k těmto pojmům nemuselo přistupovat tak často.

Důvody, proč jsou GPU efektivní při práci s velkým množstvím dat, která vyžadují zpracování:

• mají velké možnosti pro paralelní provádění úloh (mnoho, mnoho procesorů)
• velká šířka pásma paměti

Šířka pásma paměti- tolik informací - bitů nebo gigabajtů - lze přenést za jednotku času, sekundu nebo procesorový cyklus.

Jedním z úkolů optimalizace je využití maximální propustnosti – zvýšení výkonu propustnost(v ideálním případě by se měla rovnat šířce pásma paměti).

Chcete-li zlepšit využití šířky pásma:

• zvýšit množství informací - využít šířku pásma na maximum (například každý stream pracuje s float4)
• snížit latenci – zpoždění mezi operacemi

Latence- časový interval mezi okamžiky, kdy si řadič vyžádal konkrétní paměťovou buňku, a okamžikem, kdy byla data dostupná procesoru pro provedení instrukcí. Samotné zpoždění nemůžeme nijak ovlivnit – tato omezení jsou přítomna na hardwarové úrovni. Díky tomuto zpoždění může procesor současně obsluhovat několik vláken - zatímco vlákno A požádalo o přidělení paměti, vlákno B může něco vypočítat a vlákno C může počkat, dokud nedorazí požadovaná data.

Jak snížit latenci při použití synchronizace:

• snížit počet vláken v bloku
• zvýšit počet skupin bloků

Plné využití zdrojů GPU – obsazenost GPU

V povznesených konverzacích o optimalizaci často bliká termín - obsazenost gpu nebo obsazenost jádra- odráží efektivitu využití zdrojů-kapacit grafické karty. Samostatně poznamenávám, že i když používáte všechny zdroje, neznamená to, že je používáte správně.

Výpočetní výkon GPU jsou stovky procesorů chtivých výpočtů, při tvorbě programu - jádra (kernelu) - břemeno rozložení zátěže na ně padá na bedra programátora. Chyba může mít za následek, že většina těchto vzácných zdrojů bude bez důvodu nečinná. Nyní vysvětlím proč. Musíte začít z dálky.

Dovolte mi připomenout, že warp ( osnova v terminologii NVidia, vlnoplochu - v terminologii AMD) - sada vláken, která současně provádějí stejnou funkci jádra na procesoru. Vlákna, sjednocená programátorem do bloků, jsou plánovačem vláken rozdělena na warpy (pro každý multiprocesor zvlášť) - zatímco jeden warp běží, druhý čeká na zpracování paměťových požadavků atd. Pokud některá z warp vláken stále provádějí výpočty, zatímco jiná již udělala maximum, pak dochází k neefektivnímu využití výpočetního zdroje – lidově označovanému jako nečinný výkon.

Každý synchronizační bod, každá větev logiky může vytvořit takovou nečinnou situaci. Maximální divergence (větvení prováděcí logiky) závisí na velikosti warpu. Pro GPU NVidia je to 32, pro AMD 64.

Chcete-li snížit prostoje více procesorů během provádění warpu:

• minimalizovat bariéry čekací doby
• minimalizovat divergenci prováděcí logiky ve funkci jádra

K efektivnímu vyřešení tohoto problému má smysl pochopit, jak se tvoří osnovy (pro případ s několika rozměry). Ve skutečnosti je pořadí jednoduché - nejprve v X, pak v Y a naposledy v Z.

jádro je spuštěno bloky 64×16, vlákna jsou rozdělena na osnovy v pořadí X, Y, Z - tzn. prvních 64 prvků je rozděleno na dvě osnovy, pak druhé a tak dále.

Jádro začíná s bloky 16x64. Prvních a druhých 16 prvků se přidá k první osnově, třetí a čtvrtý prvek se přidá k druhé osnově a tak dále.

Jak snížit divergenci (nezapomeňte - větvení není vždy příčinou kritické ztráty výkonu)

• když sousední vlákna mají různé cesty provádění - mnoho podmínek a přechodů na nich - hledejte způsoby, jak restrukturalizovat
• hledat nevyváženou zátěž vláken a rozhodně ji odstranit (to je, když máme nejen podmínky, ale kvůli těmto podmínkám první vlákno vždy něco vypočítá a páté do této podmínky nespadne a je nečinné)

Jak vytěžit maximum ze zdrojů GPU

Zdroje GPU mají bohužel také svá omezení. A přísně vzato, před spuštěním funkce jádra má smysl definovat limity a vzít je v úvahu při rozložení zátěže. Proč je to důležité?

Grafické karty mají limity na celkový počet vláken, které může jeden multiprocesor spustit, maximální počet vláken v jednom bloku, maximální počet warpů na jednom procesoru, omezení na různé typy paměti atd. Všechny tyto informace lze vyžádat jak programově, prostřednictvím odpovídajícího API, tak dříve pomocí utilit ze sady SDK. (moduly deviceQuery pro zařízení NVidia, moduly CLInfo pro grafické karty AMD).

Obecná praxe:

• počet bloků vláken/pracovních skupin musí být násobkem počtu stream procesorů
• velikost bloku/pracovní skupiny musí být násobkem velikosti pokřivení

Zároveň je třeba mít na paměti, že naprosté minimum - na každém procesoru se točí 3-4 warpy / wayfronty současně, moudří průvodci radí vycházet z úvahy - alespoň sedm wayfrontů. Zároveň – nezapomeňte na omezení na žehličce!

Udržovat si všechny tyto detaily v hlavě rychle omrzí, proto pro výpočet obsazenosti gpu NVidia nabídla nečekaný nástroj - excelovou (!) kalkulačku plnou maker. Zde můžete zadat informace o maximálním počtu vláken pro SM, počtu registrů a velikosti sdílené (sdílené) paměti dostupné na stream procesor, a použité parametry pro spouštění funkcí - a udává to procenta efektivity využití zdrojů (a vy si rvete vlasy, když si uvědomíte, že nemáte dostatek registrů na využití všech jader).

informace o použití:
http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/#calculating-occupancy

Operace GPU a paměti

Grafické karty jsou optimalizovány pro 128bitové operace s pamětí. Tito. v ideálním případě by každá manipulace s pamětí, v ideálním případě, měla změnit 4 čtyřbajtové hodnoty současně. Hlavní nepříjemnost pro programátora je, že moderní kompilátory pro GPU nejsou schopny takové věci optimalizovat. To musí být provedeno přímo v kódu funkce a v průměru to přináší zlomky procenta zvýšení výkonu. Mnohem větší vliv na výkon má frekvence požadavků na paměť.

Problém je následující - každý požadavek vrací jako odpověď část dat, která je násobkem 128 bitů. A každé vlákno toho využívá jen čtvrtinu (v případě běžné čtyřbajtové proměnné). Když sousední vlákna současně pracují s daty umístěnými sekvenčně v paměťových buňkách, snižuje to celkový počet přístupů do paměti. Tento jev se nazývá kombinované operace čtení a zápisu ( sjednocený přístup - dobrý! jak číst, tak psát) - a se správnou organizací kódu ( rychlý přístup k souvislé části paměti - špatné!) může výrazně zlepšit výkon. Při organizaci vašeho jádra – pamatujte – souvislý přístup – v rámci prvků jednoho řádku paměti již není práce s prvky sloupce tak efektivní. Chcete více podrobností? Líbilo se mi toto pdf - nebo google pro " techniky slučování paměti “.

Vedoucí pozici v nominaci „úzké místo“ zaujímá další paměťová operace - zkopírujte data z paměti hostitele do GPU . Ke kopírování nedochází v žádném případě, ale z oblasti paměti speciálně přidělené ovladačem a systémem: když je vznesena žádost o zkopírování dat, systém tato data nejprve zkopíruje tam a teprve poté je nahraje do GPU. Rychlost přenosu dat je omezena šířkou pásma sběrnice PCI Express xN (kde N je počet datových linek), přes které moderní grafické karty komunikují s hostitelem.

Nicméně dodatečné kopírování pomalé paměti na hostiteli je někdy neopodstatněná režie. Východiskem je použití tzv připnutá paměť - speciálně označená paměťová oblast, takže operační systém s ní nemůže provádět žádné operace (například uvolnit za účelem odložení / přesunout podle svého uvážení atd.). Přenos dat z hostitele na grafickou kartu se provádí bez účasti operačního systému - asynchronně, prostřednictvím DMA (přímý přístup do paměti).

A na závěr ještě něco málo o paměti. Sdílená paměť na multiprocesoru je obvykle organizována ve formě paměťových bank obsahujících 32bitová slova – data. Počet bank se tradičně liší od jedné generace GPU ke druhé - 16/32 Pokud každé vlákno požaduje data od samostatné banky, je vše v pořádku. V opačném případě se obdrží několik požadavků na čtení / zápis do jedné banky a dostaneme - konflikt ( konflikt banky sdílené paměti). Taková konfliktní volání jsou serializována, a proto jsou prováděna postupně, nikoli paralelně. Pokud všechna vlákna přistupují ke stejné bance, použije se odpověď „vysílání“ ( přenos) a nedochází k žádnému konfliktu. Existuje několik způsobů, jak efektivně řešit konflikty přístupu, líbilo se mi to popis hlavních technik, jak se zbavit konfliktů přístupu k paměťovým bankám – .

Jak ještě zrychlit matematické operace? Pamatuj si to:

• výpočty s dvojitou přesností jsou velké provozní zatížení s fp64 >> fp32
• konstanty ve tvaru 3.13 v kódu jsou ve výchozím nastavení interpretovány jako fp64, pokud výslovně neurčíte 3.14f
• pro optimalizaci matematiky nebude zbytečné konzultovat průvodce - a existují nějaké příznaky pro kompilátor
• prodejci do svých sad SDK zahrnují funkce, které využívají funkce zařízení k dosažení výkonu (často na úkor přenositelnosti)

Pro vývojáře CUDA má smysl věnovat tomuto konceptu velkou pozornost potok cuda, umožňuje spouštět několik základních funkcí najednou na jednom zařízení nebo kombinovat asynchronní kopírování dat z hostitele do zařízení během provádění funkcí. OpenCL zatím takovou funkcionalitu neposkytuje 🙁

Profilování nevyžádané pošty:

NVifia Visual Profiler je zajímavý nástroj, který analyzuje jádra CUDA i OpenCL.

P.S. Jako delšího průvodce optimalizací mohu doporučit všemožné googlování průvodce osvědčenými postupy pro OpenCL a CUDA.

• ,

Když už mluvíme o paralelním počítání na GPU, musíme si pamatovat, v jaké době žijeme, dnes je doba, kdy je všechno na světě tak zrychlené, že ztrácíme pojem o čase a nevnímáme, jak spěchá. Vše, co děláme, je spojeno s vysokou přesností a rychlostí zpracování informací, v takových podmínkách určitě potřebujeme nástroje, abychom zpracovali všechny informace, které máme a převedli je na data, kromě toho, když už mluvíme o takových úkolech, musíme mít na paměti, že tyto úkoly jsou nezbytné nejen pro velké organizace nebo megakorporace, ale takové problémy nyní potřebují řešit i běžní uživatelé, kteří své životně důležité úkoly spojené s vyspělými technologiemi řeší doma na osobní počítače! Vznik NVIDIA CUDA nebyl překvapivý, ale spíše oprávněný, protože jakmile bude nutné zpracovávat na PC mnohem časově náročnější úkoly než dosud. Práce, která dříve trvala velmi dlouho, nyní zabere pár minut, respektive to ovlivní celkový obraz celého světa!

Co je to GPU Computing

GPU computing je použití GPU k výpočtu technických, vědeckých a každodenních úkolů. Počítání na GPU zahrnuje použití CPU a GPU s heterogenním výběrem mezi nimi, konkrétně: sekvenční část programů přebírá CPU, zatímco časově náročné výpočetní úlohy zůstávají na GPU. Díky tomu dochází k paralelizaci úloh, což vede k rychlejšímu zpracování informací a zkracuje dobu potřebnou k dokončení práce, systém se stává produktivnějším a může současně zpracovávat více úloh než dříve. K dosažení takového úspěchu však nestačí pouze hardwarová podpora, v tomto případě je potřeba i softwarová podpora, aby aplikace přenesla časově nejnáročnější výpočty na GPU.

Co je CUDA

CUDA je technologie pro programování algoritmů ve zjednodušeném jazyce C, která běží na grafických procesorech osmé generace a starších akcelerátorech GeForce a také na odpovídajících kartách Quadro a Tesla od NVIDIA. CUDA umožňuje zahrnout speciální funkce do textu programu C. Tyto funkce jsou napsány ve zjednodušeném programovacím jazyce C a běží na GPU. Počáteční verze CUDA SDK byla vydána 15. února 2007. Pro úspěšný překlad kódu do tohoto jazyka obsahuje CUDA SDK svůj vlastní C kompilátor příkazový řádek nvcc od společnosti NVIDIA. Kompilátor nvcc je založen na otevřený kompilátor Open64 a je navržen tak, aby přeložil hostitelský kód (hlavní, řídicí kód) a kód zařízení (hardwarový kód) (soubory s příponou .cu) do objektových souborů vhodných pro vytvoření finálního programu nebo knihovny v jakémkoli programovacím prostředí, např. , ve studiu Microsoft Visual Studio.

Technologické schopnosti

1. Standardní jazyk C pro paralelní vývoj aplikací GPU.
2. Hotové knihovny numerické analýzy pro rychlou Fourierovu transformaci a základní balík programů lineární algebry.
3. Vyhrazený ovladač CUDA pro výpočty s rychlým přenosem dat mezi GPU a CPU.
4. Schopnost ovladače CUDA komunikovat s grafickými ovladači OpenGL a DirectX.
5. Podpora na operačním sále Linuxové systémy 32/64-bit, Windows XP 32/64-bit a MacOS.

Výhody technologie

1. CUDA Application Programming Interface (CUDA API) je založeno na standardním programovacím jazyce C s určitými omezeními. To zjednodušuje a vyhlazuje proces učení architektury CUDA.
2. 16 KB sdílená paměť mezi vlákny může být použita pro uživatelsky organizovanou mezipaměť s širší šířkou pásma než při načítání z běžných textur.
3. Efektivnější transakce mezi pamětí CPU a video pamětí.
4. Plná hardwarová podpora celočíselných a bitových operací.

Příklad aplikace technologie

cRark

Nejtěžší částí tohoto programu je tinktura. Program má konzolové rozhraní, ale díky instrukcím, které jsou součástí samotného programu, jej lze používat. Následující je krátký návod pro nastavení programu. Program otestujeme na výkon a porovnáme s jiným podobným programem, který nepoužívá NVIDIA CUDA, v tomto případě se jedná o známý program „Advanced Archive Password Recovery“.

Ze staženého archivu cRark potřebujeme pouze tři soubory: crark.exe , crark-hp.exe a password.def . Сrark.exe je prolamování hesel RAR 3.0 bez zašifrovaných souborů uvnitř archivu (tj. při otevření archivu vidíme jména, ale nemůžeme archiv rozbalit bez hesla).

Сrark-hp.exe je nástroj pro prolomení hesla RAR 3.0 z příkazového řádku, který zašifruje celý archiv (tj. při otevření archivu nevidíme ani název, ani archivy samotné a nemůžeme archiv rozbalit bez Heslo).

Password.def je jakýkoli přejmenovaný textový soubor s velmi malým obsahem (například: 1. řádek: ## 2. řádek: ?* , v takovém případě bude heslo prolomeno pomocí všech znaků). Password.def je hlavou programu cRark. Soubor obsahuje pravidla pro otevření hesla (nebo znakové oblasti, kterou crark.exe při své práci použije). Více podrobností o možnostech výběru těchto znaků je napsáno v textovém souboru získaném otevřením staženého z webu od autora programu cRark: russian.def.

Výcvik

Okamžitě musím říci, že program funguje pouze tehdy, pokud je vaše grafická karta založena na GPU s podporou úrovně zrychlení CUDA 1.1. Takže řada grafických karet založených na čipu G80, jako je GeForce 8800 GTX, nepřichází v úvahu, protože mají hardwarovou podporu pro akceleraci CUDA 1.0. Pomocí CUDA program vybírá pouze hesla pro RAR archivy verze 3.0+. Je třeba nainstalovat veškerý software související s CUDA, jmenovitě:

• Ovladače NVIDIA podporující CUDA od verze 169.21
• NVIDIA CUDA SDK, počínaje verzí 1.1
• Sada nástrojů NVIDIA CUDA, počínaje verzí 1.1

Vytvoříme libovolnou složku kdekoli (například na disku C:) a nazveme ji libovolným názvem, například „3.2“. Vložili jsme tam soubory: crark.exe , crark-hp.exe a password.def a heslem chráněný / šifrovaný archiv RAR.

Dále byste měli spustit konzolu příkazového řádku Windows a přejít do vytvořené složky v ní. Ve Windows Vista a 7 byste měli vyvolat nabídku „Start“ a do vyhledávacího pole zadat „cmd.exe“; ve Windows XP z nabídky „Start“ byste měli nejprve vyvolat dialogové okno „Spustit“ a zadat „cmd .exe" v něm. Po otevření konzole zadejte příkaz jako: cd C:\folder\ , v tomto případě cd C:\3.2.

Nábor v textový editor dva řádky (text můžete také uložit jako soubor .bat do složky s cRark) pro uhodnutí hesla k heslem chráněnému archivu RAR s nešifrovanými soubory:

echo vypnuto;
cmd /K crark (název archivu).rar

uhodnout heslo heslem chráněného a šifrovaného archivu RAR:

echo vypnuto;
cmd /K crark-hp (název archivu).rar

Zkopírujte 2 řádky textový soubor do konzole a stiskněte Enter (nebo spusťte soubor .bat).

Výsledek

Proces dešifrování je znázorněn na obrázku:

Rychlost výběru na cRarku pomocí CUDA byla 1625 hesel za sekundu. Za jednu minutu a třicet šest sekund bylo uhodnuto heslo se 3 znaky: „q)$“. Pro srovnání: rychlost hrubé síly v Advanced Archive Password Recovery na mém dvoujádrovém procesoru Athlon 3000+ je maximálně 50 hesel za sekundu a hrubá síla by trvala 5 hodin. To znamená, že výběr archivu RAR pomocí bruteforce v cRarku pomocí grafické karty GeForce 9800 GTX+ je 30krát rychlejší než na CPU.

Pro ty, kteří mají procesor Intel, dobrou základní desku s vysokou frekvencí systémové sběrnice (FSB 1600 MHz), bude rychlost procesoru a hrubá síla vyšší. A pokud máte čtyřjádrový procesor a dvojici grafických karet úrovně GeForce 280 GTX, pak je výkon hesla brute force občas zrychlený. Shrneme-li příklad, je třeba říci, že tento problém byl vyřešen pomocí technologie CUDA za pouhé 2 minuty namísto 5 hodin, což ukazuje na vysoký potenciál této technologie!

závěry

Když jsme dnes zvážili technologii pro paralelní výpočty CUDA, jasně jsme viděli veškerou sílu a obrovský potenciál pro rozvoj této technologie na příkladu programu pro obnovu hesla pro RAR archivy. Musím říci o vyhlídkách této technologie, tuto technologii si jistě najde místo v životě každého člověka, který se ho rozhodne využít, ať už se jedná o vědecké úkoly, úkoly spojené se zpracováním videa, nebo i ekonomické úkoly, které vyžadují rychlý přesný výpočet, to vše povede k nevyhnutelnému nárůstu pracnosti produktivitu, kterou nelze ignorovat. K dnešnímu dni se již začíná dostávat do slovníku slovní spojení „domácí superpočítač“; je naprosto zřejmé, že k převedení takového objektu do reality má již každý dům nástroj zvaný CUDA. Od vydání karet založených na čipu G80 (2006), velké množství Akcelerátory na bázi NVIDIA, které podporují technologii CUDA, díky nimž se sen o superpočítači v každé domácnosti stane skutečností. Propagací technologie CUDA NVIDIA zvyšuje svou důvěryhodnost v očích zákazníků v podobě poskytování dalších funkcí k jejich vybavení, které si již mnozí zakoupili. Nezbývá než věřit, že se CUDA brzy rozvine velmi rychle a umožní uživatelům plně využít všech možností paralelního počítání na GPU.