Számítások be GPU-k

A CUDA (Compute Unified Device Architecture) technológia egy olyan szoftver- és hardverarchitektúra, amely lehetővé teszi a számítástechnikát olyan NVIDIA GPU-k használatával, amelyek támogatják a GPGPU (tetszőleges számítástechnika a videokártyákon) technológiát. A CUDA architektúra először a nyolcadik generációs NVIDIA chip - G80 - kiadásával jelent meg a piacon, és jelen van az összes későbbi grafikus chip-sorozatban, amelyet a GeForce, ION, Quadro és Tesla gyorsítócsaládokban használnak.

A CUDA SDK lehetővé teszi a programozók számára, hogy a C programozási nyelv speciális, leegyszerűsített dialektusával olyan algoritmusokat valósítsanak meg, amelyek NVIDIA GPU-kon futtathatók, és speciális funkciókat tartalmaznak a C program szövegében. A CUDA lehetőséget ad a fejlesztőnek, hogy saját belátása szerint megszervezze a grafikus gyorsító utasításkészletéhez való hozzáférést és kezelje a memóriáját, komplex párhuzamos számításokat szervezzen rajta.

Sztori

2003-ban az Intel és az AMD közös versenyben állt a legtöbbért erős processzor. Az évek során az órajelek jelentősen megemelkedtek ennek a versenynek köszönhetően, különösen az Intel Pentium 4 megjelenése után.

Az órajel-frekvenciák növekedése után (2001 és 2003 között a Pentium 4 órajele megduplázódott 1,5-ről 3 GHz-re), és a felhasználóknak meg kellett elégedniük a gyártók által piacra hozott tized gigahertzekkel (2003-tól 2005-ig az órajelek frekvenciái) 3-ról 3,8 GHz-re növelve).

A nagy órajelre optimalizált architektúrák, például a Prescott is nehézségekbe ütköztek, és nem csak a gyártás során. A chipgyártók kihívásokkal néztek szembe a fizika törvényeinek leküzdésében. Egyes elemzők még azt is megjósolták, hogy a Moore-törvény hatályát veszti. De ez nem történt meg. A törvény eredeti jelentését gyakran félre adják, de a szilíciummag felületén lévő tranzisztorok számára utal. Hosszú ideje a CPU-ban lévő tranzisztorok számának növekedése a teljesítmény megfelelő növekedésével járt együtt - ami a jelentés torzulásához vezetett. De aztán a helyzet bonyolultabbá vált. A CPU-architektúra tervezői az erősítéscsökkentés törvényéhez közeledtek: a teljesítmény kívánt növeléséhez szükséges tranzisztorok száma egyre több lett, ami zsákutcához vezetett.

Az ok, amiért a GPU-gyártók nem szembesültek ezzel a problémával, nagyon egyszerű: a CPU-kat úgy tervezték, hogy a legjobb teljesítményt nyújtsák olyan utasításfolyamokon, amelyek különböző adatokat (egész és lebegőpontos számokat egyaránt) dolgoznak fel, véletlenszerű hozzáférést biztosítanak a memóriához stb. d. A fejlesztők eddig is igyekeztek nagyobb utasításpárhuzamot biztosítani – vagyis minél több utasítást párhuzamosan végrehajtani. Így például a Pentiumnál megjelent a szuperskaláris végrehajtás, amikor bizonyos feltételek mellett órajelenként két utasítást lehetett végrehajtani. A Pentium Pro rendellenes utasítás-végrehajtást kapott, ami lehetővé tette a számítási egységek teljesítményének optimalizálását. A probléma az, hogy a szekvenciális utasításfolyam párhuzamos végrehajtásának nyilvánvaló korlátai vannak, így a számítási egységek számának vak növelése nem ad nyereséget, mivel legtöbbször továbbra is tétlen marad.

A GPU működése viszonylag egyszerű. Ez abból áll, hogy az egyik oldalon sokszögcsoportot veszünk, a másikon pedig egy pixelcsoportot generálunk. A sokszögek és pixelek függetlenek egymástól, így párhuzamosan is feldolgozhatók. Így a GPU-ban lehetőség van a kristály nagy részét a számítási egységek számára lefoglalni, amelyek a CPU-val ellentétben valóban felhasználásra kerülnek.

A GPU nem csak ebben különbözik a CPU-tól. A memória hozzáférés a GPU-ban nagyon csatolt - ha egy texel beolvasásra kerül, akkor néhány ciklus után a szomszédos texel beolvasásra kerül; ha egy pixelt írunk, a szomszédos is kiírásra kerül néhány ciklus után. A memória intelligens rendszerezésével az elméleti sávszélességhez közeli teljesítmény érhető el. Ez azt jelenti, hogy a GPU a CPU-val ellentétben nem igényel hatalmas gyorsítótárat, mivel szerepe a textúrázási műveletek felgyorsítása. Mindössze néhány kilobájt kell, amely néhány bilineáris és trilineáris szűrőkben használt texelt tartalmaz.

Első számítások a GPU-n

Az ilyen alkalmazásokkal kapcsolatos legelső próbálkozások néhány hardverfunkció használatára korlátozódtak, mint például a raszterezés és a Z-pufferelés. De a jelenlegi században, a shaderek megjelenésével, elkezdték felgyorsítani a mátrixok kiszámítását. 2003-ban külön szakaszt jelöltek ki a SIGGRAPH számára a GPU-számításhoz, és ezt GPGPU-nak (General-Purpose compution on GPU) nevezték el.

A legismertebb BrookGPU a Brook stream programozási nyelv fordítója, amelyet nem grafikus számítások elvégzésére terveztek a GPU-n. Megjelenése előtt a számításokhoz a videochipek képességeit használó fejlesztők a két gyakori API egyikét választották: a Direct3D-t vagy az OpenGL-t. Ez komolyan korlátozta a GPU használatát, mert a 3D grafika olyan shadereket és textúrákat használ, amelyekről a párhuzamos programozóknak nem kötelező tudniuk, szálakat és magokat használnak. Brook segíteni tudott a feladatuk megkönnyítésében. A Stanford Egyetemen kifejlesztett C nyelv streaming-kiterjesztései elrejtették a 3D API-t a programozók elől, és a videochipet párhuzamos koprocesszorként mutatták be. A fordító elemzett egy .br fájlt C++ kóddal és kiterjesztéssel, így egy DirectX, OpenGL vagy x86-kompatibilis könyvtárhoz kapcsolt kódot hozott létre.

A Brook megjelenése felkeltette az NVIDIA és az ATI érdeklődését, és egy teljesen új szektort nyitott meg – a videochipeken alapuló párhuzamos számítógépeket.

Ezenkívül a Brook projekt néhány kutatója az NVIDIA fejlesztőcsapatához költözött, hogy bevezessenek egy hardver-szoftver párhuzamos számítási stratégiát, új piaci részesedést nyitva ezzel. Ennek az NVIDIA kezdeményezésnek pedig az volt a legfőbb előnye, hogy a fejlesztők a legapróbb részletekig tökéletesen ismerik GPU-juk minden képességét, és nincs szükség a grafikus API használatára, a hardverrel pedig közvetlenül az illesztőprogram segítségével dolgozhatunk. A csapat erőfeszítéseinek eredménye az NVIDIA CUDA.

A párhuzamos számítások alkalmazási területei a GPU-n

Amikor a számítástechnika a GPU-ra kerül, sok feladatban 5-30-szoros gyorsulás érhető el a gyors, általános célú processzorokhoz képest. A legnagyobb számokat (nagyságrendileg 100-szoros gyorsulást és még ennél is többet!) olyan kódon érik el, amely nem túl jól alkalmas SSE blokkokkal történő számításokhoz, de a GPU számára meglehetősen kényelmes.

Ez csak néhány példa a szintetikus kód gyorsítására a GPU-n, szemben az SSE vektorizált kóddal a CPU-n (az NVIDIA szerint):

Fluoreszcens mikroszkóp: 12x.

Molekuladinamika (nem kötött erő számítás): 8-16x;

Elektrosztatika (közvetlen és többszintű Coulomb-összegzés): 40-120x és 7x.

Az NVIDIA által az összes prezentáción megjelenített táblázat, amely a GPU-k sebességét mutatja a CPU-khoz viszonyítva.

A főbb alkalmazások listája, amelyekben a GPU számítástechnikát használják: kép- és jelelemzés és -feldolgozás, fizikai szimuláció, számítási matematika, számítási biológia, pénzügyi számítások, adatbázisok, gáz- és folyadékdinamika, kriptográfia, adaptív sugárterápia, csillagászat, hangfeldolgozás, bioinformatika, biológiai szimulációk, számítógépes látás, adatbányászat, digitális mozi és televízió, elektromágneses szimulációk, földrajzi információs rendszerek, katonai alkalmazások, bányászati ​​tervezés, molekuláris dinamika, mágneses rezonancia képalkotás (MRI), neurális hálózatok, oceanográfiai kutatás, részecskefizika, fehérjehajtogatás szimuláció, kvantumkémia, sugárkövetés, képalkotás, radar, tározószimuláció, mesterséges intelligencia, műholdas adatok elemzése, szeizmikus feltárás, műtét, ultrahang, videokonferencia.

A CUDA előnyei és korlátai

A programozó szemszögéből a grafikus folyamat feldolgozási szakaszok halmaza. A geometria blokk háromszögeket, a raszterezési blokk pedig a monitoron megjelenő pixeleket állít elő. A hagyományos GPGPU programozási modell a következő:

A számítások GPU-ra való átviteléhez egy ilyen modell keretein belül speciális megközelítésre van szükség. Még két vektor elemenkénti hozzáadásához is meg kell rajzolni az alakzatot a képernyőre vagy egy képernyőn kívüli pufferre. Az ábra raszterezett, az egyes pixelek színét adott program szerint (pixel shader) számítjuk ki. A program minden pixelhez kiolvassa a bemeneti adatokat a textúrákból, összeadja és a kimeneti pufferbe írja. És mindezekre a számos műveletre szükség van ahhoz, amit egy hagyományos programozási nyelv egyetlen operátorával írnak le!

Emiatt a GPGPU általános célú számítástechnikai felhasználása korlátozott, mert túl sok bonyolultságot jelent a fejlesztők számára. Igen, és van még elég megkötés, mert a pixel shader csak egy képlet a pixel végső színének koordinátáitól való függésére, a pixel shader nyelv pedig egy olyan nyelv, amellyel ezeket a képleteket írhatjuk C-szerű szintaxissal. A korai GPGPU módszerek egy ügyes trükk a GPU erejének kihasználására, de minden kényelem nélkül. Az ott található adatokat képek (textúrák) reprezentálják, az algoritmust pedig egy raszterezési folyamat reprezentálja. Meg kell jegyezni, és egy nagyon specifikus modell a memória és a végrehajtás.

Az NVIDIA GPU-kon történő számítástechnikai hardver- és szoftverarchitektúrája abban különbözik a korábbi GPGPU-modellektől, hogy lehetővé teszi a GPU-k számára való programok írását valós C-ben szabványos szintaxissal, mutatókkal, és minimális bővítmény szükséges a videochipek számítási erőforrásainak eléréséhez. A CUDA nem függ a grafikus API-któl, és van néhány olyan funkciója, amelyet kifejezetten általános célú számítástechnikára terveztek.

A CUDA előnyei a GPGPU számítástechnika hagyományos megközelítésével szemben

A CUDA többprocesszoronként 16 KB megosztott memóriához biztosít hozzáférést, amely a textúralekéréseknél nagyobb sávszélességű gyorsítótár rendszerezésére használható;

Hatékonyabb adatátvitel a rendszer és a videomemória között;

Nincs szükség redundanciával és többletköltséggel rendelkező grafikus API-kra;

Lineáris memóriacímzés, valamint összegyűjtés és szóródás, tetszőleges címekre való írás képessége;

Hardveres támogatás egész és bit műveletekhez.

A CUDA fő korlátai:

A végrehajtható függvények rekurziós támogatásának hiánya;

A minimális blokkszélesség 32 menet;

Az NVIDIA tulajdonában lévő zárt CUDA architektúra.

A korábbi GPGPU-módszerekkel végzett programozás gyengeségei, hogy ezek a módszerek nem használnak vertex shader végrehajtási egységeket a korábbi, nem egységes architektúrákban, az adatok textúrákban tárolódnak és egy képernyőn kívüli pufferbe kerülnek, a többlépéses algoritmusok pedig pixel shader egységeket használnak. A GPGPU korlátozásai a következők: a hardver képességeinek nem kellően hatékony kihasználása, a memória sávszélességének korlátozása, a szóródás nélküli működés (csak összegyűjtés), a grafikus API kötelező használata.

A CUDA fő előnyei a korábbi GPGPU-módszerekkel szemben abból a tényből fakadnak, hogy ezt az architektúrát arra tervezték hatékony felhasználása nem grafikus számítástechnika a GPU-n, és a C programozási nyelvet használja, anélkül, hogy szükség lenne az algoritmusok átvitelére a grafikus folyamat fogalmának megfelelő formába. CUDA kínál új út GPU számítástechnika, amely nem használ grafikus API-kat, és véletlenszerű memória-hozzáférést kínál (szórt vagy gyűjtöget). Egy ilyen architektúra mentes a GPGPU hátrányaitól, és az összes végrehajtási egységet felhasználja, valamint egész szám matematikai és biteltolási műveletekkel bővíti a képességeket.

A CUDA megnyit néhány hardverfunkciót, amelyek nem érhetők el a grafikus API-kból, például a megosztott memóriát. Ez egy kis mennyiségű memória (többprocesszoronként 16 kilobájt), amelyhez szálblokkok férhetnek hozzá. Lehetővé teszi a leggyakrabban használt adatok gyorsítótárazását, és még többet is tud nyújtani Magassebesség, ahhoz képest, hogy textúralekérést használunk ehhez a feladathoz. Ez viszont számos alkalmazásban csökkenti a párhuzamos algoritmusok átviteli érzékenységét. Például hasznos a lineáris algebra, a gyors Fourier-transzformáció és a képfeldolgozó szűrők esetében.

Kényelmesebb a CUDA-ban és a memóriaelérésben. Program kód a grafikus API-ban 32 egyszeres pontosságú lebegőpontos érték formájában (RGBA értékek egyidejűleg nyolc renderelési célban) ad ki adatokat előre meghatározott területeken, és a CUDA támogatja a szórt rögzítést - korlátlan számú rekordot bármely címen . Az ilyen előnyök lehetővé teszik néhány olyan algoritmus végrehajtását a GPU-n, amely nem valósítható meg hatékonyan a grafikus API-n alapuló GPGPU metódusokkal.

Ezenkívül a grafikus API-knak textúrákban kell tárolniuk az adatokat, ami megköveteli a nagy tömbök előzetes textúrákba való csomagolását, ami bonyolítja az algoritmust és speciális címzés alkalmazását kényszeríti ki. A CUDA pedig lehetővé teszi az adatok bármely címről történő olvasását. A CUDA másik előnye a CPU és a GPU közötti optimalizált kommunikáció. Azoknak a fejlesztőknek pedig, akik hozzá akarnak férni az alacsony szinthez (például egy másik programozási nyelv írásakor), a CUDA az alacsony szintű assembly nyelvű programozás lehetőségét kínálja.

A CUDA hátrányai

A CUDA egyik hátránya a rossz hordozhatóság. Ez az architektúra csak ennek a cégnek a videochipjein működik, és nem mindegyiken, hanem a GeForce 8 és 9 sorozattól, valamint a megfelelő Quadrotól, ION-tól és Teslától kezdve. Az NVIDIA 90 millió CUDA-kompatibilis videochipről ad számot.

A CUDA alternatívái

Keret az íráshoz számítógépes programok párhuzamos számítástechnikával kapcsolatos különféle grafikus és központi processzorokon. Az OpenCL keretrendszer tartalmaz egy C99 szabványon alapuló programozási nyelvet és egy alkalmazásprogramozási felületet (API). Az OpenCL utasítás- és adatszintű párhuzamosságot biztosít, és a GPGPU technika megvalósítása. Az OpenCL egy teljesen nyílt szabvány, és nem kell licencdíjat fizetni a használatáért.

Az OpenCL célja, hogy kiegészítse az OpenGL-t és az OpenAL-t, amelyek a 3D számítógépes grafika és hang nyílt iparági szabványai, kihasználva a GPU erejét. Az OpenCL-t a Khronos Group, egy non-profit konzorcium fejleszti és tartja karban, amelybe számos nagy cég tartozik, köztük az Apple, az AMD, az Intel, az nVidia, a Sun Microsystems, a Sony Computer Entertainment és mások.

CAL/IL (számítási absztrakciós réteg/köztes nyelv)

Az ATI Stream Technology egy sor hardver és szoftver technológiák, amelyek lehetővé teszik az AMD GPU-k használatát a CPU-val együtt számos alkalmazás (nem csak a grafikus) felgyorsítására.

Az ATI Stream alkalmazási területei a számítási erőforrásokat igénylő alkalmazások, mint pl a pénzügyi elemzés vagy szeizmikus adatfeldolgozás. A stream processzor használata lehetővé tette egyes pénzügyi számítások sebességének 55-szörösére való növelését ahhoz képest, hogy ugyanazt a problémát csak a processzor.

Az NVIDIA az ATI Stream technológiát nem tartja túl erős versenytársnak. A CUDA és a Stream két különböző technológia, amelyek különböző fejlettségi szinten állnak. Az ATI termékek programozása sokkal nehezebb – a nyelvük inkább az assemblerhez hasonlít. A CUDA C viszont egy sokkal magasabb szintű nyelv. Kényelmesebb és egyszerűbb rá írni. A nagy fejlesztő cégek számára ez nagyon fontos. Ha már a teljesítményről beszélünk, akkor láthatjuk, hogy az ATI termékekben a csúcsértéke magasabb, mint az NVIDIA megoldásokban. De ismét minden azon múlik, hogyan lehet megszerezni ezt az erőt.

DirectX11 (DirectCompute)

Alkalmazásprogramozási felület, amely a DirectX része, a Microsoft API-készlete, amelyet IBM PC-kompatibilis számítógépeken való futtatásra terveztek. operációs rendszer Microsoft Windows család. A DirectCompute-ot általános célú számítások elvégzésére tervezték GPU-kon, mivel a GPGPU koncepció megvalósítása. A DirectCompute eredetileg a DirectX 11 részeként jelent meg, de később elérhetővé tették a DirectX 10-hez és a DirectX 10.1-hez is.

NVDIA CUDA az orosz tudományos közösségben.

2009 decemberétől programozási modell A CUDA-t a világ 269 egyetemén tanítják. Oroszországban a CUDA-val kapcsolatos képzéseket a moszkvai, szentpétervári, kazanyi, novoszibirszki és permi állami egyetemeken, a „Dubna” Társadalom és Ember Természettudományi Nemzetközi Egyetemen, a Közös Nukleáris Kutatási Intézetben, a Moszkvai Elektronikus Intézetben tartanak. Technológia, Ivanovo Állami Energiamérnöki Egyetem, BSTU. V. G. Shukhova, MSTU im. Bauman, RKhTU im. Mengyelejev, az Orosz Kutatóközpont "Kurcsatov Intézet", az Orosz Tudományos Akadémia Interregionális Szuperszámítógép Központja, a Taganrogi Technológiai Intézet (TTI SFedU).

AMD/ATI Radeon architektúra jellemzői

Ez hasonló az új biológiai fajok születéséhez, amikor az élőlények az élőhelyek fejlődése során fejlődnek, hogy javítsák alkalmazkodóképességüket a környezethez. Hasonlóképpen, a GPU-k, kezdve a háromszögek gyorsított raszterizálásával és textúrájával, további képességeket fejlesztettek ki árnyékoló programok végrehajtására ugyanezen háromszögek színezésére. Ezekre a képességekre pedig a nem grafikus számítástechnikában bizonyult igény, ahol egyes esetekben jelentős teljesítménynövekedést biztosítanak a hagyományos megoldásokhoz képest.

Az analógiákat tovább vonjuk - a szárazföldön végzett hosszú evolúció után az emlősök behatoltak a tengerbe, ahol kiszorították a hétköznapi tengeri lakosokat. A versengő küzdelemben az emlősök a földfelszínen megjelent új, fejlett képességeket és azokat a speciálisan a vízi élethez való alkalmazkodáshoz sajátítottakat egyaránt felhasználták. Ugyanígy a GPU-k a 3D-s grafika architektúrájának előnyeire alapozva egyre gyakrabban tesznek szert speciális, nem grafikus feladatokhoz hasznos funkciókra.

Tehát mi teszi lehetővé a GPU számára, hogy saját szektort igényeljen az általános célú programok területén? A GPU mikroarchitektúrája nagyon eltér a hagyományos CPU-któl, és már a kezdetektől fogva bizonyos előnyei vannak. A grafikus feladatok független párhuzamos adatfeldolgozást foglalnak magukban, és a GPU natív módon többszálú. De ez a párhuzamosság csak öröm számára. A mikroarchitektúrát úgy tervezték, hogy kihasználja a végrehajtandó nagyszámú szálat.

A GPU több tucat (30 az Nvidia GT200, 20 az Evergreen, 16 a Fermi) processzormagból áll, amelyeket az Nvidia terminológiájában Streaming Multiprocessornak, az ATI terminológiában pedig SIMD Engine-nek hívnak. A cikk keretein belül miniprocesszoroknak nevezzük őket, mivel több száz programszálat hajtanak végre, és szinte mindent meg tudnak csinálni, amit egy normál CPU, de még mindig nem mindent.

A marketingnevek zavaróak - a nagyobb fontosság érdekében a funkcionális modulok számát jelzik, amelyek kivonhatják és szorozhatják: például 320 vektor "mag" (mag). Ezek a magok inkább szemek. Jobb, ha a GPU-t többmagos processzornak kell tekinteni, sok maggal, amelyek egyszerre több szálat hajtanak végre.

Mindegyik miniprocesszor rendelkezik helyi memóriával, 16 KB a GT200, 32 KB az Evergreen és 64 KB a Fermi (lényegében egy programozható L1 gyorsítótár). Hasonló hozzáférési idővel rendelkezik a hagyományos CPU L1 gyorsítótárához, és hasonló funkciókat hajt végre, hogy a lehető leggyorsabban továbbítsa az adatokat a funkciómodulokhoz. A Fermi architektúrában a helyi memória egy része normál gyorsítótárként konfigurálható. A GPU-ban a helyi memóriát a végrehajtó szálak közötti gyors adatcserére használják. A GPU-programok egyik szokásos sémája a következő: először a GPU globális memóriájából származó adatok betöltődnek a helyi memóriába. Ez csak egy közönséges videomemória található (pl rendszermemória) külön a "saját" processzortól - videó esetén több mikroáramkör forrasztja a videokártya textolitján. Ezután több száz szál dolgozik ezekkel az adatokkal a helyi memóriában, és kiírja az eredményt a globális memóriába, majd átkerül a CPU-ba. A programozó feladata, hogy utasításokat írjon az adatok helyi memóriából való betöltésére és kiürítésére. Lényegében ez [egy adott feladat] adatainak particionálása párhuzamos feldolgozáshoz. A GPU támogatja az atomi írási/olvasási utasításokat is a memóriába, de ezek nem hatékonyak, és általában az utolsó szakaszban szükségesek az összes miniprocesszor számítási eredményeinek „ragasztásához”.

A helyi memória közös a miniprocesszorban futó összes szálra, így például az Nvidia terminológiájában még megosztottnak is nevezik, a helyi memória pedig ennek pont az ellenkezőjét jelenti, nevezetesen: egy külön szál bizonyos személyes területét a globálisban. csak számára látható és hozzáférhető memória. De a helyi memórián kívül a miniprocesszornak van egy másik memóriaterülete is, minden architektúrában, körülbelül négyszer nagyobb térfogatú. Egyenlően fel van osztva az összes végrehajtó szál között; ezek a változók és a számítások közbenső eredményeinek tárolására szolgáló regiszterek. Minden szálnak több tucat regisztere van. A pontos szám attól függ, hogy a miniprocesszor hány szálat fut. Ez a szám nagyon fontos, hiszen a globális memória késleltetése nagyon magas, több száz ciklus, és gyorsítótárak hiányában a számítások közbenső eredményeit sehol sem lehet tárolni.

És még egy fontos tulajdonsága a GPU-nak: „puha” vektorizálás. Mindegyik miniprocesszor nagyszámú számítási modullal rendelkezik (8 a GT200-hoz, 16 a Radeonhoz és 32 a Fermihez), de csak ugyanazt az utasítást tudják végrehajtani, azonos programcímmel. Az operandusok ebben az esetben eltérőek lehetnek, a különböző szálaknak megvan a sajátjuk. Például az utasítás add hozzá két regiszter tartalmát: minden számítástechnikai eszköz egyidejűleg hajtja végre, de különböző regisztereket vesz fel. Feltételezzük, hogy a GPU program minden szála, amely párhuzamos adatfeldolgozást végez, általában párhuzamosan mozog a programkódon keresztül. Így az összes számítási modul egyenletesen van betöltve. És ha a szálak a programban lévő elágazások miatt eltértek a kódvégrehajtási útjukon, akkor megtörténik az úgynevezett szerializáció. Ekkor nem minden számítási modult használunk, mivel a szálak különböző utasításokat adnak be a végrehajtáshoz, és a számítási modulok blokkja, mint már említettük, csak egy címmel rendelkező utasítást tud végrehajtani. És persze a teljesítmény ugyanakkor a maximumhoz képest esik.

Előnye, hogy a vektorizálás teljesen automatikus, nem SSE, MMX stb. használatával történő programozás. A GPU pedig maga kezeli az eltéréseket. Elméletileg lehet programokat írni a GPU-hoz anélkül, hogy a végrehajtó modulok vektoros jellegére gondolnánk, de egy ilyen program sebessége nem lesz túl nagy. Hátránya a vektor nagy szélessége. Ez több, mint a funkcionális modulok névleges száma, és az Nvidia GPU-k esetében 32, a Radeon esetében pedig 64. A szálak feldolgozása megfelelő méretű blokkokban történik. Az Nvidia ezt a szálblokkot warp, AMD - hullámfront kifejezésnek nevezi, ami ugyanaz. Így 16 számítástechnikai eszközön egy 64 szál hosszúságú "hullámfrontot" négy ciklusban dolgoznak fel (a szokásos utasításhosszat feltételezve). A szerző ebben az esetben a warp kifejezést részesíti előnyben, mert a hajózási láncszem kifejezéssel asszociál, amely a csavart kötelekből kötött kötelet jelöli. Tehát a szálak "csavarodnak", és egy integrált köteget alkotnak. A „hullámfront” azonban a tengerhez is köthető: az instrukciók ugyanúgy érkeznek az aktuátorokhoz, ahogy a hullámok egymás után gurulnak a partra.

Ha minden szál egyformán haladt előre a program végrehajtása során (ugyanott van) és így ugyanazt az utasítást hajtja végre, akkor minden rendben van, de ha nem, akkor lelassul. Ebben az esetben az ugyanabból a lánc- vagy hullámfrontból származó szálak különböző helyeken vannak a programban, olyan szálcsoportokra vannak osztva, amelyeknek az utasításszáma (más szóval az utasításmutató) megegyezik. És mint korábban, csak egy csoport szálai kerülnek végrehajtásra egyszerre - mindegyik ugyanazt az utasítást hajtja végre, de különböző operandusokkal. Ennek eredményeként a warp annyiszor lassabban hajtódik végre, hány csoportra oszlik, és a csoportban lévő szálak száma nem számít. Még ha a csoport csak egy szálból áll is, akkor is annyi ideig tart, amíg egy teljes warp fut. Hardverben ezt bizonyos szálak maszkolásával valósítják meg, vagyis az utasításokat formálisan végrehajtják, de végrehajtásuk eredményét sehol nem rögzítik, és a jövőben nem használják fel.

Bár minden miniprocesszor (Streaming MultiProcessor vagy SIMD Engine) egy adott időpontban csak egy vetemítéshez (egy csomó szálhoz) tartozó utasításokat hajt végre, több tucat aktív vetemítés van a végrehajtható készletben. Az egyik warp utasításainak végrehajtása után a miniprocesszor nem a következő sorban lévő utasítást hajtja végre ennek a warpnak a szálairól, hanem valaki másnak a warp utasításait. Az a warp teljesen más helyen lehet a programban, ez nem befolyásolja a sebességet, hiszen csak a warp-on belül kell az összes szál utasításának azonosnak lennie a teljes sebességű végrehajtáshoz.

Ebben az esetben mind a 20 SIMD motornak négy aktív hullámfrontja van, mindegyik 64 szállal. Minden szálat egy rövid vonal jelöl. Összesen: 64×4×20=5120 szál

Így, tekintettel arra, hogy minden vetemedés vagy hullámfront 32-64 szálból áll, a miniprocesszor több száz aktív szálat tartalmaz, amelyek szinte egyidejűleg futnak. Az alábbiakban látni fogjuk, milyen építészeti előnyökkel kecsegtet egy ilyen nagy számú párhuzamos szál, de először megvizsgáljuk, milyen korlátai vannak a GPU-kat alkotó miniprocesszoroknak.

A lényeg, hogy a GPU-nak nincs olyan verem, ahol a függvényparamétereket és a helyi változókat tárolhatnák. A verem nagy számú szála miatt egyszerűen nincs hely a chipen. Valójában, mivel a GPU egyidejűleg körülbelül 10 000 szálat hajt végre, egyetlen szál 100 KB-os veremmérete mellett, a teljes mennyiség 1 GB lesz, ami megegyezik az összes videomemória szabványos mennyiségével. Sőt, magában a GPU-magban nincs mód jelentős méretű verem elhelyezésére. Például, ha szálonként 1000 bájt veremet helyez el, akkor csak egy miniprocesszornak lesz szüksége 1 MB memóriára, ami majdnem ötszöröse a miniprocesszor helyi memóriájának és a regiszterek tárolására lefoglalt memóriának.

Ezért a GPU programban nincs rekurzió, és nem igazán lehet funkcióhívásokkal megfordulni. A program fordításakor minden függvény közvetlenül bekerül a kódba. Ez a GPU hatókörét a számítási feladatokra korlátozza. Néha lehetséges korlátozott verem-emuláció használata globális memóriát használó rekurziós algoritmusokhoz ismert kis iterációs mélységgel, de ez nem egy tipikus GPU-alkalmazás. Ehhez speciálisan ki kell dolgozni egy algoritmust, fel kell tárni annak megvalósítási lehetőségét anélkül, hogy a CPU-hoz képest garantáltan sikeres legyen a gyorsítás.

A Fermi először vezette be a virtuális függvények használatának lehetőségét, de használatukat ismét korlátozza, hogy minden szálhoz nincs nagy, gyors gyorsítótár. Az 1536 szál 48 KB-ot vagy 16 KB L1-et tesz ki, vagyis a program virtuális függvényei viszonylag ritkán használhatók, különben a verem is lassú globális memóriát használ, ami lelassítja a végrehajtást, és valószínűleg nem hoz hasznot a CPU verzióhoz képest.

Így a GPU egy számítási társprocesszorként jelenik meg, amelybe adatokat töltenek be, azokat valamilyen algoritmus feldolgozza, és eredményt állítanak elő.

Az építészet előnyei

De a GPU-t nagyon gyorsnak tartja. Ebben pedig nagy sokszálassága segíti. A nagyszámú aktív szál lehetővé teszi a külön elhelyezett globális videomemória nagy késleltetését, amely körülbelül 500 ciklus, részben elrejti. Különösen jól kiegyenlíti a nagy sűrűségű kódot. aritmetikai műveletek. Így nincs szükség tranzisztor-drága L1-L2-L3 gyorsítótár-hierarchiára. Ehelyett sok számítási modul elhelyezhető egy chipen, ami kiemelkedő aritmetikai teljesítményt nyújt. Közben egy szál vagy warp utasításai végrehajtásra kerülnek, a többi több száz szál csendben várja az adatait.

A Fermi egy második szintű, körülbelül 1 MB-os gyorsítótárat vezetett be, de nem hasonlítható össze a modern processzorok gyorsítótáraival, inkább a magok közötti kommunikációra és a különféle szoftveres trükkökre szolgál. Ha a méretét felosztjuk a több tízezer szál között, mindegyiknek nagyon jelentéktelen mennyisége lesz.

De a globális memória késleltetése mellett sokkal több késés van a számítástechnikai eszközben, amelyet el kell rejteni. Ez a chipen belüli adatátvitel késleltetése a számítástechnikai eszközökről az első szintű gyorsítótárba, azaz a GPU helyi memóriájába, valamint a regiszterekbe, valamint az utasítás-gyorsítótárba. A regiszterfájl, valamint a helyi memória a funkcionális moduloktól elkülönítve található, a hozzájuk való hozzáférés sebessége körülbelül egy tucat ciklus. És ismét, nagyszámú szál, aktív vetemedés, hatékonyan elrejti ezt a késleltetést. Ezenkívül a teljes GPU helyi memóriájához való hozzáférés teljes sávszélessége (sávszélessége), figyelembe véve az azt alkotó miniprocesszorok számát, sokkal nagyobb, mint a modern CPU-k első szintű gyorsítótárához való hozzáférés sávszélessége. A GPU lényegesen több adatot tud feldolgozni egységnyi idő alatt.

Rögtön elmondhatjuk, hogy ha a GPU-t nem látják el nagyszámú párhuzamos szálal, akkor szinte nulla lesz a teljesítménye, mert ugyanolyan ütemben fog működni, mintha teljesen fel lenne töltve, és sokkal kevesebb munkát végezne. Például 10 000 helyett csak egy szál maradjon: a teljesítmény körülbelül ezerszeresére csökken, mert nemcsak hogy nem töltődik be minden blokk, de az összes késleltetés is hatással lesz.

A késleltetések elrejtésének problémája a modern, nagyfrekvenciás CPU-k esetében is akut, ennek kiküszöbölésére kifinomult módszereket alkalmaznak - mély csővezetékek, utasítások rendellenes végrehajtása (out-of-order). Ehhez összetett utasítás-végrehajtási ütemezőkre, különféle pufferekre stb. van szükség, ami helyet foglal a chipen. Ez mind szükséges a legjobb teljesítményhez egyszálú üzemmódban.

De a GPU-nál mindez nem szükséges, architekturálisan gyorsabb a nagy szálszámú számítási feladatokhoz. Ehelyett úgy alakítja át a többszálat teljesítménysé, mint a bölcsek köve az ólmot arannyá.

A GPU-t eredetileg úgy tervezték, hogy optimálisan hajtsa végre a háromszög pixelekhez tartozó shader programokat, amelyek nyilvánvalóan függetlenek és párhuzamosan is végrehajthatók. Ebből az állapotból pedig úgy fejlődött ki, hogy különféle funkciókat (helyi memória és címezhető hozzáférés a videomemóriához, valamint az utasításkészlet bonyolítása) hozzáadott egy nagyon erős számítástechnikai eszközzé, amely továbbra is csak olyan algoritmusokhoz alkalmazható hatékonyan, amelyek nagymértékben párhuzamos megvalósítást tesznek lehetővé. korlátozott mennyiségű helyi memória használatával.memória.

Példa

Az egyik legklasszikusabb GPU-probléma a gravitációs teret létrehozó N test kölcsönhatásának kiszámítása. De ha például a Föld-Hold-Nap rendszer evolúcióját kell kiszámolnunk, akkor a GPU rossz segítőnk: kevés az objektum. Minden objektumhoz ki kell számítani az összes többi objektummal való interakciót, és csak kettő van belőlük. A Naprendszer mozgása esetén az összes bolygóval és holdjaikkal (kb. pár száz objektum) a GPU még mindig nem túl hatékony. A többmagos processzor azonban a szálkezelés magas rezsiköltségei miatt szintén nem fogja tudni megmutatni teljes erejét, egyszálas módban fog működni. De ha üstökösök és aszteroidaöv objektumok pályáit is ki kell számítani, akkor ez már a GPU feladata, hiszen van elég objektum a szükséges számú párhuzamos számítási szál létrehozásához.

A GPU akkor is jól teljesít, ha több százezer csillagból álló gömbhalmazok ütközését kell kiszámítani.

Egy másik lehetőség a GPU teljesítményének kihasználására az N-test problémájában akkor jelenik meg, ha sok egyedi problémát kell kiszámítani, bár kevés testtel. Például, ha egy rendszer evolúcióját szeretné kiszámítani a kezdeti sebességek különböző opcióihoz. Ekkor problémamentesen lehet majd hatékonyan használni a GPU-t.

AMD Radeon mikroarchitektúra részletei

Figyelembe vettük a GPU szervezésének alapelveit, ezek minden gyártó videógyorsítóinál közösek, mivel kezdetben egy célfeladatuk volt - a shader programok. A gyártók azonban úgy találták, hogy a mikroarchitektúra megvalósításának részleteiben nem értenek egyet. Bár a különböző gyártók CPU-i néha nagyon eltérőek, még ha kompatibilisek is, például a Pentium 4 és az Athlon vagy a Core. Az Nvidia architektúrája már széles körben ismert, most megnézzük a Radeont, és kiemeljük a főbb különbségeket ezen gyártók megközelítésében.

Az AMD grafikus kártyák a DirectX 11 specifikációt is úttörő Evergreen család óta teljes mértékben támogatják az általános számítástechnikát. A 47xx család kártyáinak számos jelentős korlátja van, amelyekről az alábbiakban lesz szó.

A helyi memória méretének különbségei (32 KB Radeon, 16 KB a GT200 és 64 KB Fermi esetében) általában nem alapvetőek. Valamint a hullámfront mérete 64 szál az AMD és a 32 szál per warp az Nvidia esetében. Szinte minden GPU program könnyen átkonfigurálható és ezekre a paraméterekre hangolható. A teljesítmény akár több tíz százalékkal is változhat, de egy GPU esetében ez nem annyira fontos, mert egy GPU-program általában tízszer lassabban fut, mint a CPU-ra vonatkozó társa, vagy tízszer gyorsabban, vagy egyáltalán nem működik.

Sokkal fontosabb a használat AMD Technologies VLIW (Nagyon hosszú utasításszó). Az Nvidia skaláris egyszerű utasításokat használ, amelyek skalárregisztereken működnek. Gyorsítói egyszerű klasszikus RISC-t valósítanak meg. Az AMD grafikus kártyák ugyanannyi regisztert tartalmaznak, mint a GT200, de a regiszterek 128 bites vektorosak. Minden VLIW utasítás több négykomponensű 32 bites regiszteren működik, ami hasonló az SSE-hez, de a VLIW lehetőségei sokkal szélesebbek. Ez nem SIMD (Single Instruction Multiple Data), mint az SSE - itt az egyes operanduspárokhoz tartozó utasítások eltérőek, sőt függőek lehetnek! Például legyen az A regiszter összetevői neve a1, a2, a3, a4; a B regiszterre - hasonlóan. Kiszámítható egyetlen utasítással, amely egy ciklusban hajtódik végre, például az a1×b1+a2×b2+a3×b3+a4×b4 számmal vagy egy kétdimenziós vektorral (a1×b1+a2×b2, a3× b3+a4×b4).

Ezt a GPU alacsonyabb frekvenciája, mint a CPU, és a technikai folyamatok erőteljes csökkentése tette lehetővé utóbbi évek. Ehhez nincs szükség ütemezőre, szinte minden órajelenként végrehajtódik.

A vektoros utasításokkal a Radeon csúcsteljesítménye nagyon magas, teraflopon.

Egy vektorregiszter négy egyedi precíziós szám helyett egy dupla pontosságú számot tud tárolni. És egy VLIW-utasítás vagy összeadhat két pár párost, vagy megszorozhat két számot, vagy megszorozhat két számot és hozzáadhat a harmadikhoz. Így a csúcsteljesítmény kettősben körülbelül ötször alacsonyabb, mint úszóban. A régebbi Radeon modelleknél ez megfelel a Nvidia teljesítmény Tesla az új Fermi architektúrán és sokkal nagyobb teljesítmény, mint a duplakártyák a GT200 architektúrán. A Fermi alapú fogyasztói Geforce videokártyákban a kétszeres számítások maximális sebessége négyszeresére csökkent.

A Radeon munkájának sematikus diagramja. Csak egy miniprocesszor látható a 20 párhuzamosan futó miniprocesszorból

A GPU-gyártókat a CPU-gyártókkal ellentétben (elsősorban az x86-kompatibilisek) nem kötik kompatibilitási problémák. A GPU-programot először egy köztes kódba fordítják, és amikor a program fut, az illesztőprogram ezt a kódot speciális gépi utasításokká fordítja. konkrét modell. Ahogy fentebb leírtuk, a GPU-gyártók ezt kihasználva kényelmes ISA-t (Instruction Set Architecture) találtak ki GPU-jukhoz, és generációról generációra változtatták azokat. Mindenesetre ez a dekóder hiánya (mint szükségtelen) miatt a teljesítmény bizonyos százalékát növelte. De az AMD még tovább ment, feltalálta saját formátumát az utasítások gépi kódban történő elrendezéséhez. Nem szekvenciálisan vannak elrendezve (a programlista szerint), hanem szakaszokba rendezve.

Először a feltételes ugrásutasítások szakasza következik, amelyek hivatkozásokat tartalmaznak a folytonos aritmetikai utasítások különböző ágaknak megfelelő szakaszaira. Ezeket VLIW kötegeknek (VLIW utasítások kötegeinek) hívják. Ezek a szakaszok csak számtani utasításokat tartalmaznak regiszterekből vagy helyi memóriából származó adatokkal. Egy ilyen szervezet leegyszerűsíti az utasítások áramlását és a végrehajtási egységekhez való eljuttatását. Ez annál is inkább hasznos, mivel a VLIW utasításai viszonylag nagyok. Vannak olyan szakaszok is, amelyek a memória-hozzáférési utasításokat tartalmazzák.

Mindkét gyártó GPU-ja (mind az Nvidia, mind az AMD) rendelkezik beépített utasításokkal az alapvető matematikai függvények, négyzetgyök, kitevő, logaritmusok, szinuszok és koszinuszok gyors kiszámításához egyetlen precíziós számokhoz több ciklusban. Ehhez speciális számítási blokkok vannak. Ezek a függvények gyors közelítésének szükségességéből adódnak a geometria árnyékolókban.

Ha valaki nem is tudta, hogy a GPU-kat grafikára használják, és csak a műszaki jellemzőkkel ismerkedett meg, akkor ezzel a jellel sejtette, hogy ezek a számítási társprocesszorok videógyorsítókból származnak. Hasonlóképpen, a tengeri emlősök bizonyos tulajdonságai arra késztették a tudósokat, hogy elhiggyék, hogy őseik szárazföldi lények voltak.

De egy nyilvánvalóbb tulajdonság, amely elárulja az eszköz grafikus eredetét, a kétdimenziós és háromdimenziós textúrák olvasására szolgáló blokkok a bilineáris interpoláció támogatásával. Széles körben használják a GPU-programokban, mivel gyorsabban és könnyebben olvashatók a csak olvasható adattömbök. Az egyik standard opciók A GPU-alkalmazások úgy viselkednek, hogy kiolvassák a kiindulási adatok tömbjeit, feldolgozzák azokat a számítási magokban, és az eredményt egy másik tömbbe írják, amely aztán visszakerül a CPU-ba. Egy ilyen séma szabványos és általános, mert kényelmes a GPU architektúra számára. Azokat a feladatokat, amelyek intenzív olvasást és írást igényelnek a globális memória egy nagy területére, így adatfüggőségeket tartalmaznak, nehéz párhuzamosítani és hatékonyan megvalósítani a GPU-n. A teljesítményük nagymértékben függ a globális memória késleltetésétől is, amely nagyon nagy. De ha a feladatot az "adatok olvasása - feldolgozás - eredmény írása" minta írja le, akkor szinte biztosan nagy lökést kaphat a GPU-n történő végrehajtása.

A GPU-ban lévő textúraadatokhoz az első és a második szint kis gyorsítótárainak külön hierarchiája van. A textúrák használatából adódó gyorsulást is biztosítja. Ez a hierarchia eredetileg a GPU-kban jelent meg, hogy kihasználják a textúrákhoz való hozzáférés lokális előnyeit: nyilvánvalóan egy pixel feldolgozása után a szomszédos pixelhez (nagy valószínűséggel) szorosan elhelyezett textúraadatokra lesz szükség. De sok hagyományos számítástechnikai algoritmus hasonló jellegű adathozzáféréssel rendelkezik. Tehát a grafikából származó textúra gyorsítótárak nagyon hasznosak lesznek.

Bár az Nvidia és az AMD kártyák L1-L2 gyorsítótárának mérete megközelítőleg megegyezik, amit nyilvánvalóan a játékgrafikával kapcsolatos optimalitás követelményei okoznak, a gyorsítótárak elérésének késleltetése jelentősen eltér. Az Nvidia hozzáférési késleltetése magasabb, és a Geforce textúra-gyorsítótárai elsősorban a memóriabusz terhelésének csökkentését segítik elő, nem pedig közvetlenül az adatok elérését. Ez nem észrevehető a grafikus programokban, de fontos az általános célú programoknál. Radeonban a textúra gyorsítótár késleltetési ideje kisebb, de a miniprocesszorok helyi memóriájának késleltetése magasabb. Íme egy példa: az Nvidia kártyák optimális mátrixszorzásához jobb a helyi memóriát használni, blokkonként betöltve a mátrixot, az AMD-nél pedig érdemesebb egy alacsony késleltetésű textúra gyorsítótárra hagyatkozni, a mátrixelemeket úgy olvasni. szükséges. De ez már egy meglehetősen finom optimalizálás, és egy olyan algoritmushoz, amelyet már alapvetően átvittek a GPU-ra.

Ez a különbség 3D textúrák használatakor is megmutatkozik. Az egyik első GPU-számítási benchmark, amely komoly előnyt mutatott az AMD számára, csak 3D textúrákat használt, mivel háromdimenziós adattömbbel dolgozott. A Radeon textúra-hozzáférési késleltetése pedig lényegesen gyorsabb, a 3D-s tok pedig hardveresen optimalizáltabb.

Ahhoz, hogy a különböző cégek hardvereiből maximális teljesítményt kapjunk, szükség van egy adott kártya alkalmazásának némi hangolására, de ez egy nagyságrenddel kevésbé jelentős, mint elvileg a GPU architektúra algoritmusának kidolgozása.

A Radeon 47xx sorozat korlátozásai

Ebben a családban a GPU számítástechnika támogatása nem teljes. Itt három van fontos pillanatokat. Először is, nincs helyi memória, azaz fizikailag megvan, de nem rendelkezik a GPU programok modern szabványa által megkívánt univerzális hozzáféréssel. Programozottan emulálják a globális memóriában, ami azt jelenti, hogy a teljes funkcionalitású GPU-val szemben nem profitál belőle. A második pont a különféle atomi memória műveleti utasítások és szinkronizálási utasítások korlátozott támogatása. És a harmadik pont eléggé kis méret utasítás gyorsítótár: egy bizonyos programmérettől kezdve a sebesség többszörösére csökken. Vannak más kisebb korlátozások is. Elmondhatjuk, hogy ezen a videokártyán csak a GPU-hoz ideálisan illeszkedő programok működnek jól. Bár a videokártya Gigaflopsban jó eredményeket tud felmutatni egyszerű, csak regiszterekkel működő tesztprogramokban, problémás valami komplexet hatékonyan programozni rá.

Az Evergreen előnyei és hátrányai

Ha összehasonlítjuk az AMD és az Nvidia termékeket, akkor a GPU számítástechnika szempontjából az 5xxx sorozat egy nagyon erős GT200-nak tűnik. Olyan erős, hogy csúcsteljesítményben körülbelül két és félszeresével felülmúlja Fermit. Főleg az új Nvidia videokártyák paramétereinek levágása után csökkent a magok száma. De az L2 gyorsítótár megjelenése a Fermiben leegyszerűsíti néhány algoritmus megvalósítását a GPU-n, így kibővíti a GPU hatókörét. Érdekes módon az előző generációs GT200 CUDA programokra jól optimalizált Fermi építészeti újításai gyakran semmit sem tettek. A számítási modulok számának növekedésével arányosan gyorsultak, vagyis kevesebb mint kétszeresére (egyes precíziós számok esetén), vagy még kevésbé, mert a memória sávszélessége nem nőtt (vagy más okok miatt).

A GPU architektúrához jól illeszkedő és kifejezett vektorjellegű feladatokban (például mátrixszorzás) pedig a Radeon az elméleti csúcshoz viszonylag közeli teljesítményt mutat, és megelőzi Fermit. A többmagos CPU-król nem is beszélve. Különösen az egyszeri precíziós számokkal kapcsolatos problémáknál.

De a Radeon kisebb szerszámfelülettel, kisebb hőelvezetéssel, energiafogyasztással, nagyobb hozammal és ennek megfelelően alacsonyabb költséggel rendelkezik. És közvetlenül a 3D-s grafika problémáiban a Fermi-erősítés, ha van, sokkal kisebb, mint a kristály területének különbsége. Ez nagyrészt annak köszönhető, hogy a Radeon számítási architektúrája miniprocesszoronként 16 számítási egységgel, 64 szálú hullámfronttal és VLIW vektorutasításokkal tökéletesen megfelel a fő feladatának - a grafikus árnyékolók számításának. A túlnyomó többségnek hétköznapi felhasználók a játékteljesítmény és az ár a prioritás.

A professzionális, tudományos programok szempontjából a Radeon architektúra biztosítja a legjobb ár-teljesítmény arányt, wattonkénti teljesítményt és abszolút teljesítményt olyan feladatokban, amelyek elvileg jól illeszkednek a GPU architektúrához, lehetővé teszik a párhuzamosítást és a vektorizálást.

Például egy teljesen párhuzamos, könnyen vektorizálható kulcskiválasztási probléma esetén a Radeon többszörösen gyorsabb, mint a Geforce, és több tízszer gyorsabb, mint a CPU.

Ez megfelel az általános AMD Fusion koncepciónak, miszerint a GPU-knak ki kell egészíteniük a CPU-t, és a jövőben magába a CPU magba kell integrálódni, ahogyan korábban a matematikai társprocesszor is egy külön chipről került át a processzormagba (ez kb. húsz évvel ezelőtt, az első Pentium processzorok megjelenése előtt). A GPU integrálva lesz grafikus magés egy vektoros koprocesszor a streaming feladatokhoz.

A Radeon trükkös technikát alkalmaz a különböző hullámfrontokból származó utasítások keverésére, amikor funkciómodulok hajtják végre. Ezt könnyű megtenni, mivel az utasítások teljesen függetlenek. Az elv hasonló a független utasítások modern CPU-k általi csővezetékes végrehajtásához. Úgy tűnik, ez lehetővé teszi összetett, több bájtos, vektoros VLIW utasítások hatékony végrehajtását. A CPU-n ehhez kifinomult ütemezőre van szükség a független utasítások azonosításához, vagy a Hyper-Threading technológiára, amely a CPU-t is ellátja a különböző szálakból származó ismert független utasításokkal.

Két hullámfront 128 utasítását, amelyek mindegyike 64 műveletből áll, 16 VLIW modul hajtja végre nyolc ciklusban. Van egy váltakozás, és minden modulnak valójában két ciklusa van egy teljes utasítás végrehajtására, feltéve, hogy a második ciklusban párhuzamosan egy újat kezd végrehajtani. Ez valószínűleg segít egy VLIW-utasítás gyors végrehajtásában, mint például az a1×a2+b1×b2+c1×c2+d1×d2, azaz nyolc ilyen utasítás végrehajtását nyolc ciklusban. (Formálisan kiderül, óránként egy.)

Az Nvidia nyilvánvalóan nem rendelkezik ezzel a technológiával. VLIW hiányában pedig a skaláris utasításokat használó nagy teljesítmény magas működési frekvenciát igényel, ami automatikusan növeli a hőleadást, és magas követelményeket támaszt a folyamattal szemben (az áramkör magasabb frekvenciájú működésére kényszeríteni).

A Radeon hátránya a GPU számítástechnika szempontjából, hogy nagy ellenszenv az elágazástól. A GPU-k általában nem részesítik előnyben az elágazást a fenti utasítások végrehajtási technológiája miatt: azonnal egy szálcsoport által egy programcímmel. (Egyébként ezt a technikát SIMT: Single Instruction - Multiple Threads (egy utasítás - sok szál) hívják, a SIMD analógiájára, ahol egy utasítás egy műveletet hajt végre különböző adatokkal.) . Nyilvánvaló, hogy ha a program nem teljesen vektor, akkor minél nagyobb a vetemedés vagy hullámfront mérete, annál rosszabb, mivel amikor a programon áthaladó út eltér, szomszédos szálak alakulnak ki. több csoport, amelyet szekvenciálisan (szerializálva) kell végrehajtani. Tegyük fel, hogy az összes szál szétszóródott, akkor 32 szálból álló vetemedés esetén 32-szer lassabban fog futni a program. A 64-es méretnél pedig, akárcsak a Radeonnál, 64-szer lassabb.

Ez az „ellenszenv” észrevehető, de nem egyetlen megnyilvánulása. Az Nvidia videokártyákban minden funkcionális modul, más néven CUDA mag, rendelkezik egy speciális elágazó feldolgozó egységgel. A 16 számítási modulhoz való Radeon videokártyákban pedig csak két elágazó vezérlőegység van (ezek az aritmetikai egységek tartományából származnak). Tehát még egy feltételes elágazási utasítás egyszerű feldolgozása is több időt vesz igénybe, még akkor is, ha az eredménye a hullámfront minden szálánál azonos. És a sebesség csökken.

Az AMD CPU-kat is gyárt. Úgy gondolják, hogy a sok elágazású programokhoz a CPU még mindig jobban megfelel, a GPU pedig tisztán vektoros programokhoz készült.

A Radeon tehát összességében kevésbé hatékony programozást biztosít, de sok esetben jobb ár-teljesítmény arányt biztosít. Más szóval kevesebb olyan program van, amely hatékonyan (előnyösen) migrálható CPU-ról Radeonra, mint a Fermi-n hatékonyan futtatható programok. De másrészt a hatékonyan átvihetőek sok szempontból hatékonyabban fognak működni Radeonon.

API GPU számítástechnikához

maguk Műszaki adatok A Radeon vonzónak tűnik, még akkor is, ha nem szükséges idealizálni és abszolutizálni a GPU-számítást. De a teljesítmény szempontjából nem kevésbé fontos a GPU-programok fejlesztéséhez és végrehajtásához szükséges szoftver - magas szintű nyelvről és futásidejű fordítók, vagyis olyan illesztőprogram, amely a CPU-n futó program egy része és a GPU között kölcsönhatásba lép. maga. Még a CPU-nál is fontosabb: a CPU-nak nincs szüksége driverre az adatátvitel kezeléséhez, a fordító szempontjából pedig a GPU finnyásabb. Például a fordítóprogramnak be kell érnie minimális számú regiszterrel a számítások közbenső eredményeinek, valamint a szépen sorba épített függvényhívások tárolására, ismételten minimális regiszter felhasználásával. Végtére is, minél kevesebb regisztert használ egy szál, annál több szálat tud futtatni, és minél jobban betölti a GPU-t, így jobban elrejti a memória-elérési időt.

Így a Radeon termékek szoftvertámogatása még mindig elmarad a hardver fejlesztésétől. (Ellenben az Nvidia helyzetével, ahol a hardver megjelenése késett, és a termék lecsupaszított formában jelent meg.) A közelmúltban az AMD OpenCL fordítója béta státuszban volt, sok hibával. Túl gyakran generált hibás kódot, vagy nem volt hajlandó lefordítani a kódot a megfelelő forráskódból, vagy maga is hibát adott és összeomlott. Csak tavasz végén jött egy nagy teljesítményű kiadás. Ez sem hibamentes, de lényegesen kevesebb van belőlük, és általában a pálya szélén jelennek meg, amikor valamit a helyesség határán próbálnak programozni. Például az uchar4 típussal működnek, amely egy 4 bájtos négykomponensű változót ad meg. Ez a típus benne van az OpenCL specifikációban, de Radeonon nem érdemes vele dolgozni, mert a regiszterek 128 bitesek: ugyanaz a négy komponens, de 32 bites. És egy ilyen uchar4 változó továbbra is egy teljes regisztert foglal el, csak további műveletekre lesz szükség az egyes bájt-összetevők csomagolásához és eléréséhez. Egy fordító nem tartalmazhat hibákat, de nincsenek hibák nélkül fordítóprogramok. Még az Intel Compilerben is 11 verzió után vannak fordítási hibák. Az azonosított hibákat a következő kiadás javítja, amely az őszhez közeledve jelenik meg.

De még mindig sok mindent kell javítani. Például eddig a Radeon szabványos GPU-illesztőprogramja nem támogatja az OpenCL-t használó GPU-számítást. A felhasználónak le kell töltenie és telepítenie kell egy további speciális csomagot.

De a legfontosabb dolog a függvénykönyvtárak hiánya. A dupla pontosságú valós számoknál nincs is szinusz, koszinusz és kitevő. Nos, ez nem szükséges a mátrixösszeadáshoz/szorzáshoz, de ha valami bonyolultabbat akarunk programozni, akkor az összes függvényt a nulláról kell megírni. Vagy várja meg az új SDK-kiadást. Az ACML hamarosan megjelenik ( AMD Core Math Library) az Evergreen GPU családhoz, amely támogatja az alapvető mátrixfunkciókat.

Jelenleg a cikk írója szerint a Direct Compute 5.0 API használata tűnik valósnak a Radeon videokártyák programozására, természetesen figyelembe véve a korlátokat: a Windows 7 platformra való tájékozódást ill. Windows Vista. A Microsoftnak nagy tapasztalata van a fordítók gyártásában, és hamarosan teljesen működőképes kiadásra számíthatunk, a Microsoftot ez közvetlenül érdekli. A Direct Compute azonban az interaktív alkalmazások igényeire összpontosít: kiszámítani valamit, és azonnal megjeleníteni az eredményt - például a folyadék áramlását a felületen. Ez nem jelenti azt, hogy ne lehetne egyszerűen számításokra használni, de nem ez a természetes célja. A Microsoft például nem tervezi, hogy könyvtári funkciókat adjon a Direct Compute-hoz – pontosan olyanokkal, amelyekkel az AMD jelenleg nem rendelkezik. Vagyis ami most Radeonon hatékonyan kiszámolható - néhány nem túl kifinomult program - az OpenCL-nél jóval egyszerűbb és stabilabb Direct Compute-on is megvalósítható. Ráadásul teljesen hordozható, Nvidián és AMD-n is futni fog, így csak egyszer kell lefordítani a programot, miközben az Nvidia és az AMD OpenCL SDK implementációi nem teljesen kompatibilisek. (Abban az értelemben, hogy ha OpenCL programot fejlesztünk AMD rendszeren az AMD OpenCL SDK használatával, akkor előfordulhat, hogy az nem fut olyan könnyen az Nvidián. Lehet, hogy ugyanazt a szöveget kell fordítania az Nvidia SDK-val. És persze fordítva. )

Aztán az OpenCL-ben sok redundáns funkció található, mivel az OpenCL-t univerzális programozási nyelvnek és API-nak szánták a rendszerek széles skálájához. És GPU, CPU és Cell. Tehát abban az esetben, ha csak egy tipikus felhasználói rendszerhez (processzor plusz videokártya) szeretne programot írni, az OpenCL nem tűnik úgymond „nagyon produktívnak”. Minden függvénynek tíz paramétere van, és közülük kilencet 0-ra kell állítani. Az egyes paraméterek beállításához pedig meg kell hívni egy speciális függvényt, amelynek szintén vannak paraméterei.

A Direct Compute jelenlegi legfontosabb előnye pedig az, hogy a felhasználónak nem kell külön csomagot telepítenie: minden, ami kell, már a DirectX 11-ben van.

A GPU számítástechnika fejlesztésének problémái

Ha a személyi számítógépek területét vesszük, akkor a helyzet a következő: nincs sok olyan feladat, amely nagy számítási teljesítményt igényel, és egy hagyományos kétmagos processzorból erősen hiányzik. Mintha nagy falánk, de ügyetlen szörnyek kúsztak volna ki a tengerből a szárazföldre, és a szárazföldön szinte nem volt mit enni. A földfelszín őslakóhelyei pedig egyre kisebbek, megtanulnak kevesebbet fogyasztani, mint mindig, amikor hiány van a természeti erőforrásokból. Ha ma ugyanolyan teljesítményigény lenne, mint 10-15 évvel ezelőtt, akkor a GPU-számítást egy ütéssel elfogadnák. Így előtérbe kerülnek a kompatibilitási problémák és a GPU-programozás viszonylagos bonyolultsága. Jobb olyan programot írni, amely minden rendszeren fut, mint olyan programot, amely gyors, de csak a GPU-n fut.

A GPU-k kilátásai valamivel jobbak a professzionális alkalmazásokban és a munkaállomás-szektorban való felhasználás tekintetében, mivel nagyobb az igény a teljesítményre. Bővítmények jelennek meg a GPU-képes 3D szerkesztőkhöz: például sugárkövetéssel történő rendereléshez – nem tévesztendő össze a normál GPU-megjelenítéssel! Valami megjelenik a 2D-s és a prezentációszerkesztőknél is, az összetett hatások gyorsabb létrehozásával. A videófeldolgozó programok is fokozatosan megszerzik a GPU támogatását. A fenti feladatok párhuzamos jellegüket tekintve jól illeszkednek a GPU architektúrára, de mostanra egy nagyon nagy kódbázis készült, hibakeresés, optimalizált minden CPU képességre, így időbe telik, mire megjelennek a jó GPU implementációk.

Ebben a szegmensben a GPU ilyen gyengeségei is megnyilvánulnak, például korlátozott mennyiségű videomemória - körülbelül 1 GB a hagyományos GPU-k esetében. A GPU-programok teljesítményét csökkentő egyik fő tényező, hogy a CPU és a GPU között lassú buszon kell adatot cserélni, és a korlátozott memóriamennyiség miatt több adatot kell átvinni. És itt ígéretesnek tűnik az AMD GPU-t és CPU-t egy modulban kombináló koncepciója: feláldozhatja a grafikus memória nagy sávszélességét a megosztott memóriához való könnyű és egyszerű hozzáférés érdekében, ráadásul alacsonyabb késleltetés mellett. A jelenlegi DDR5 videomemória nagy sávszélességére sokkal nagyobb a kereslet közvetlenül grafikus programok mint a legtöbb GPU számítástechnikai program. Általában, Közös memória A GPU és a CPU egyszerűen jelentősen kibővíti a GPU hatókörét, lehetővé téve számítási képességeinek használatát a programok kis részfeladataiban.

És leginkább a GPU-kra van kereslet a tudományos számítástechnika területén. Több GPU alapú szuperszámítógép is készült már, amelyek igen magas eredményeket mutatnak a mátrixműveletek tesztelésében. A tudományos problémák olyan sokrétűek és számosak, hogy mindig van egy olyan készlet, amely tökéletesen illeszkedik a GPU-architektúrához, amelyhez a GPU használata megkönnyíti a nagy teljesítmény elérését.

Ha a modern számítógépek összes feladata közül választ egyet, akkor az a számítógépes grafika lesz - annak a világnak a képe, amelyben élünk. Az erre a célra optimális architektúra pedig nem lehet rossz. Ez annyira fontos és alapvető feladat, hogy a speciálisan erre tervezett hardvernek univerzálisnak és optimálisnak kell lennie a különböző feladatokhoz. Sőt, a videokártyák is sikeresen fejlődnek.

Az egyik legtöbb rejtett funkciók, a Windows 10 legújabb frissítésében lehetővé teszi annak ellenőrzését, hogy mely alkalmazások használják a grafikus feldolgozó egységet (GPU). Ha valaha is megnyitotta a Feladatkezelőt, valószínűleg megnézte a CPU-használatot, hogy megtudja, mely alkalmazások igényelnek a legtöbb processzort. NÁL NÉL legújabb frissítések hozzáadott egy hasonló funkciót, de a GPU GPU-khoz. Harmadik féltől származó szoftverek letöltése nélkül segít megérteni, milyen intenzív szoftverek és játékok vannak a GPU-n. Van egy másik érdekes funkció, amely segít a CPU-nak a GPU-ra való lerakásában. Javaslom, hogy olvassa el a választás módját.

Miért nincs GPU a Feladatkezelőben?

Sajnos nem minden grafikus kártya képes biztosítani a Windows számára a GPU olvasásához szükséges statisztikákat. Az biztos, hogy gyorsan tesztelheti ezt a technológiát a DirectX diagnosztikai eszközzel.

1. kattintson a " Rajt"és a keresőbe írd be dxdiag a DirectX diagnosztikai eszköz futtatásához.
2. Ugrás a lapra Képernyő", közvetlenül az oszlopban járművezetők"neked kellene WDDM modell 2.0-nál nagyobb verzió, hogy a GPU-grafikonokat használja a feladatkezelőben.

A GPU Graph engedélyezése a Feladatkezelőben

Az egyes alkalmazások GPU-használatának megtekintéséhez meg kell nyitnia a Feladatkezelőt.

• Nyomja meg a gombkombinációt Ctrl + Shift + Esc a Feladatkezelő megnyitásához.
• Kattintson Jobb klikk kattintson a feladatkezelőben az üres mezőre " Név"és ellenőrizze a legördülő menüből GPU. Azt is megjegyezheti GPU mag hogy megnézze, mely programok használják.
• Most a feladatkezelőben a GPU grafikonja és a GPU magja látható a jobb oldalon.

Tekintse meg a GPU általános teljesítményét

Nyomon követheti a teljes GPU-használatot, hogy figyelemmel kísérhesse és elemezhesse nagy terhelés alatt. Ebben az esetben mindent láthat, amire szüksége van a " Teljesítmény"kiválasztásával grafikus processzor.

Minden GPU-elem egyedi grafikonokra van lebontva, hogy még több betekintést nyújtson a GPU használatába. Ha módosítani szeretné a megjelenített diagramokat, kattintson az egyes feladatok címe melletti kis nyílra. Ezen a képernyőn megjelenik az illesztőprogram verziója és dátuma is, ami jó alternatíva a DXDiag vagy az Eszközkezelő használatához.

Soha nincs túl sok mag...

A modern GPU-k szörnyen gyors vadállatok, amelyek gigabájtnyi adatot képesek megrágni. Azonban az ember ravasz, és nem számít, hogyan nő számítási teljesítmény, egyre nehezebb feladatokkal áll elő, így eljön a pillanat, amikor szomorúan kell megállapítani, hogy optimalizálás kell 🙁

Ez a cikk az alapfogalmakat ismerteti, hogy könnyebb legyen eligazodni a gpu-optimalizálás elméletében és az alapvető szabályokban, hogy ezekhez a fogalmakhoz ritkábban kelljen hozzáférni.

Az okok, amelyek miatt a GPU-k hatékonyak nagy mennyiségű, feldolgozást igénylő adat kezelésére:

• nagyszerű lehetőségeket kínálnak a feladatok párhuzamos végrehajtására (sok-sok processzor)
• nagy memória sávszélesség

Memória sávszélesség- ennyi információ - bit vagy gigabájt - vihető át időegységenként, másodpercenként vagy processzorciklusonként.

Az optimalizálás egyik feladata a maximális áteresztőképesség kihasználása – a teljesítmény növelése áteresztőképesség(ideális esetben egyenlőnek kell lennie a memória sávszélességével).

A sávszélesség-használat javítása érdekében:

• növelje az információ mennyiségét - használja a teljes sávszélességet (például minden adatfolyam a float4-el működik)
• késleltetés csökkentése – a műveletek közötti késés

Késleltetés- az időintervallum azon pillanatok között, amikor a vezérlő egy adott memóriacellát kért, és az a pillanat, amikor az adatok a processzor rendelkezésére állnak az utasítások végrehajtásához. Magát a késleltetést semmilyen módon nem tudjuk befolyásolni – ezek a korlátozások hardverszinten jelen vannak. Ennek a késleltetésnek köszönhető, hogy a processzor egyszerre több szálat tud kiszolgálni - míg az A szál memóriafoglalást kért, a B szál tud valamit számolni, a C szál pedig megvárhatja, amíg a kért adatok megérkeznek.

A késleltetés csökkentése szinkronizálás használata esetén:

• csökkentse a szálak számát egy blokkban
• növelje a blokkcsoportok számát

A GPU-erőforrások teljes kihasználása – GPU-foglaltság

Az optimalizálásról szóló, előkelő beszélgetésekben gyakran felvillan a kifejezés - gpu foglaltság vagy kernel foglaltság- tükrözi a videokártya erőforrás-kapacitások kihasználásának hatékonyságát. Külön megjegyzem, hogy még ha az összes erőforrást felhasználja is, ez nem jelenti azt, hogy helyesen használja azokat.

A GPU számítási teljesítménye a számításokra mohó processzorok százai, a program - a kernel (kernel) - létrehozásakor a rájuk háruló terhelés elosztásának terhe a programozó vállára hárul. Egy hiba azt eredményezheti, hogy ezen értékes erőforrások többsége ok nélkül tétlen marad. Most megmagyarázom, miért. Messziről kell kezdeni.

Hadd emlékeztesselek arra, hogy a vetemedés ( vetemedik az NVidia terminológiájában, hullámfront - az AMD terminológiájában) - szálak halmaza, amelyek egyidejűleg ugyanazt a kernel funkciót látják el a processzoron. A programozó által blokkokra egyesített szálakat a szálütemező (multiprocesszoronként külön-külön) vetemedésekre osztja fel - miközben az egyik vetemítés fut, a második a memóriakérések feldolgozására vár, stb. Ha a vetemítési szálak egy része még mindig számításokat végez, míg mások már megtettek minden tőlük telhetőt, akkor a számítási erőforrások nem hatékony felhasználásáról van szó – közismerten üresjárati teljesítményként emlegetve.

Minden szinkronizálási pont, a logika minden ága létrehozhat ilyen tétlen helyzetet. A maximális eltérés (a végrehajtási logika elágazása) a vetemítés méretétől függ. NVidia GPU esetén ez 32, AMD esetén 64.

A többprocesszoros állásidő csökkentése a vetemítés végrehajtása során:

• minimalizálja a várakozási idő akadályait
• minimalizálja a végrehajtási logika eltérését a kernelfüggvényben

A probléma hatékony megoldása érdekében érdemes megérteni a vetemítések kialakulását (több dimenzió esetén). Valójában a sorrend egyszerű – először X-ben, majd Y-ben, végül pedig Z-ben.

a magot 64×16-os blokkokkal indítjuk, a szálakat láncokra osztjuk X, Y, Z sorrendben - azaz. az első 64 elemet két láncra osztjuk, majd a másodikat és így tovább.

A kernel 16x64-es blokkokkal kezdődik. Az első és a második 16 elemet hozzáadjuk az első lánchoz, a harmadik és negyedik elemet a második lánchoz, és így tovább.

Hogyan csökkenthető a divergencia (ne feledje, hogy az elágazás nem mindig a kritikus teljesítményvesztés oka)

• ha a szomszédos szálaknak különböző végrehajtási útvonalaik vannak – sok feltétel és átmenet van rajtuk – keressük az újrastrukturálás módját
• keress egy kiegyensúlyozatlan szálterhelést és határozottan távolítsd el (ilyenkor nemcsak feltételeink vannak, hanem ezek miatt a feltételek miatt az első szál mindig kalkulál valamit, az ötödik pedig nem esik ebbe az állapotba és tétlen)

Hogyan hozhatja ki a legtöbbet a GPU-erőforrásokból

Sajnos a GPU-erőforrásoknak is megvannak a korlátai. És szigorúan véve a kernelfüggvény elindítása előtt érdemes korlátokat meghatározni, és ezeket figyelembe venni a terhelés elosztása során. Miért fontos?

A videokártyák korlátozzák az egy multiprocesszor által végrehajtható szálak számát, az egy blokkban lévő szálak maximális számát, az egy processzoron lévő vetemítések maximális számát, a különböző típusú memóriákra vonatkozó korlátozásokat stb. Mindezek az információk kérhetők mind programozottan, a megfelelő API-n keresztül, mind pedig korábban az SDK segédprogramjaival. (DeviceQuery modulok NVidia eszközökhöz, CLInfo modulok AMD videokártyákhoz).

Általános gyakorlat:

• a szálblokkok/munkacsoportok számának a folyamprocesszorok számának többszörösének kell lennie
• A blokk/munkacsoport méretének a vetemítés méretének többszörösének kell lennie

Ugyanakkor szem előtt kell tartani, hogy az abszolút minimum - 3-4 lánc / útfront forog egyszerre minden processzoron, a bölcs útmutatók azt tanácsolják, hogy a mérlegelésből induljanak ki - legalább hét útfront. Ugyanakkor - ne felejtse el a vasalóra vonatkozó korlátozásokat!

Mindezen részletek fejben tartása hamar unalmassá válik, ezért a gpu-foglaltság kiszámításához az NVidia egy váratlan eszközt kínált - egy makróval teli excel (!) kalkulátort. Itt megadhatja az SM szálainak maximális számát, a regiszterek számát és a megosztott (megosztott) memória méretét. stream processzor, és a függvények indításához használt paraméterek - és százalékot ad az erőforrás-felhasználás hatékonyságának (és téped a hajad, felismerve, hogy nincs elég regisztered az összes mag használatához).

használati információk:
http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/#calculating-occupancy

GPU és memória műveletek

A videokártyákat 128 bites memóriaműveletekre optimalizálták. Azok. ideális esetben minden memóriamanipulációnak egyszerre 4 négybájtos értéket kellene megváltoztatnia. A fő bosszúság a programozó számára az, hogy a GPU-ra szánt modern fordítók nem képesek optimalizálni az ilyesmit. Ezt közvetlenül a függvénykódban kell megtenni, és átlagosan a teljesítménynövekedés egy százalékának töredékét hozza. A memóriakérések gyakorisága sokkal nagyobb hatással van a teljesítményre.

A probléma a következő: minden kérés válaszként egy 128 bites többszörös adatot ad vissza. És minden szál csak a negyedét használja (normál négybájtos változó esetén). Ha a szomszédos szálak egyidejűleg a memóriacellákban egymás után elhelyezkedő adatokkal dolgoznak, ez csökkenti a memóriaelérések teljes számát. Ezt a jelenséget kombinált olvasási és írási műveleteknek nevezzük ( egyesített hozzáférés - jó! írni és olvasni egyaránt) - és a kód helyes szervezésével ( lépcsőzetes hozzáférés az összefüggő memóriadarabokhoz – rossz!) jelentősen javíthatja a teljesítményt. Amikor a rendszermagot - ne feledje - egybefüggő hozzáférést - egy memóriasor elemeibe rendezi, az oszlop elemeivel való munka már nem olyan hatékony. További részleteket szeretne? Tetszett ez a pdf - vagy google a " memória egyesülési technikák “.

A „szűk keresztmetszet” jelölésben a vezető pozíciót egy másik memóriaművelet foglalja el - adatok másolása a gazdagép memóriájából a GPU-ra . A másolás nem akárhogyan, hanem a meghajtó és a rendszer által speciálisan lefoglalt memóriaterületről történik: amikor adatmásolási kérés érkezik, a rendszer először oda másolja ezeket az adatokat, és csak ezután tölti fel a GPU-ra. Az adatátviteli sebességet a sávszélesség korlátozza PCI busz Express xN (ahol N az adatvonalak száma), amelyen keresztül a modern videokártyák kommunikálnak a gazdagéppel.

Azonban a lassú memória extra másolása a gazdagépen néha indokolatlan többletköltség. A kiút az ún rögzített memória - speciálisan megjelölt memóriaterület, hogy az operációs rendszer ne tudjon vele semmilyen műveletet végrehajtani (például kirakni, hogy saját belátása szerint cseréljen / mozgassa stb.). Az adatátvitel a gazdagépről a videokártyára az operációs rendszer részvétele nélkül történik - aszinkron módon, keresztül DMA (közvetlen memória hozzáférés).

És végül még egy kicsit a memóriáról. A többprocesszoros megosztott memóriát általában 32 bites szavakat - adatokat - tartalmazó memóriabankok formájában szervezik. A bankok száma hagyományosan GPU-generációnként változik - 16/32 Ha minden szál külön banktól kér adatokat, akkor minden rendben van. Ellenkező esetben több olvasási / írási kérés érkezik egy bankhoz, és konfliktust kapunk ( megosztott memóriabank konfliktus). Az ilyen ütköző hívások sorba vannak állítva, ezért szekvenciálisan hajtják végre, nem párhuzamosan. Ha az összes szál ugyanahhoz a bankhoz fér hozzá, akkor a rendszer „sugárzott” választ ( adás), és nincs konfliktus. Számos módja van a hozzáférési konfliktusok hatékony kezelésére, tetszett a memóriabankokhoz való hozzáférési konfliktusoktól való megszabadulás fő technikáinak leírása – .

Hogyan lehet még gyorsabbá tenni a matematikai műveleteket? Ne feledd:

• A dupla pontosságú számítások nagy üzemi terhelést jelentenek az fp64 >> fp32 esetén
• a 3.13 formájú konstansok a kódban alapértelmezés szerint fp64-ként értelmeződnek, ha nem adja meg kifejezetten a 3.14f értéket
• a matematika optimalizálásához nem lesz felesleges az útmutatókban konzultálni - és vannak-e zászlók a fordító számára
• a szállítók olyan funkciókat tartalmaznak SDK-jukban, amelyek kihasználják az eszköz jellemzőit a teljesítmény elérése érdekében (gyakran a hordozhatóság rovására)

Érdemes a CUDA fejlesztőinek nagyon odafigyelni a koncepcióra Cuda patak, amelyek lehetővé teszik több alapvető funkció futtatását egyszerre egy eszközön, vagy kombinálják az adatok aszinkron másolását a gazdagépről az eszközre a funkciók végrehajtása során. Az OpenCL még nem biztosít ilyen funkciót 🙁

Profilozási szemét:

Az NVifia Visual Profiler egy érdekes segédprogram, amely mind a CUDA, mind az OpenCL kerneleket elemzi.

Ui. Hosszabb optimalizálási útmutatóként ajánlani tudom mindenféle google-zást legjobb gyakorlati útmutató OpenCL-hez és CUDA-hoz.

• ,

Ha már a párhuzamos számítástechnikáról beszélünk a GPU-n, emlékeznünk kell arra, hogy milyen időben élünk, ma az az idő, amikor a világon minden annyira felgyorsul, hogy elveszítjük az időérzékünket, észre sem vesszük, hogyan rohan el. Minden, amit teszünk, az információfeldolgozás nagy pontosságához és gyorsaságához kapcsolódik, ilyen körülmények között minden bizonnyal szükségünk van eszközökre ahhoz, hogy a birtokunkban lévő összes információt feldolgozzuk és adatokká alakítsuk, emellett, ha már ilyen feladatokról beszélünk, emlékeznünk kell arra, hogy ezek a feladatok nem csak a nagy szervezetek vagy a megavállalatok számára szükségesek, ma már egyszerű felhasználóknak is meg kell oldaniuk az ilyen problémákat, akik otthon oldják meg a csúcstechnológiával kapcsolatos létfontosságú feladataikat. személyi számítógépek! Az NVIDIA CUDA megjelenése nem volt meglepő, inkább indokolt, mert amint az eddigieknél sokkal időigényesebb feladatokat kell majd PC-n feldolgozni. A korábban nagyon hosszú ideig tartó munka most percek kérdése, illetve ez befolyásolja az egész világ összképét!

Mi az a GPU számítástechnika

A GPU számítástechnika a GPU használata műszaki, tudományos és mindennapi feladatok kiszámítására. A GPU-n történő számítás a CPU és a GPU használatát jelenti, heterogén szelekcióval, nevezetesen: a programok szekvenciális részét a CPU veszi át, míg az időigényes számítási feladatok a GPU-nál maradnak. Ennek köszönhetően a feladatok párhuzamosak, ami gyorsabb információfeldolgozást eredményez, és csökkenti a munkavégzéshez szükséges időt, a rendszer termelékenyebbé válik, és egyszerre több feladatot tud feldolgozni, mint korábban. Az ilyen sikerek eléréséhez azonban a hardveres támogatás önmagában nem elegendő, ebben az esetben szoftveres támogatás is szükséges, hogy az alkalmazás a legidőigényesebb számításokat tudja átvinni a GPU-ra.

Mi az a CUDA

A CUDA az algoritmusok egyszerűsített C nyelven történő programozására szolgáló technológia, amely nyolcadik generációs és régebbi GeForce-gyorsítók grafikus processzorain, valamint az NVIDIA megfelelő Quadro- és Tesla-kártyáin fut. A CUDA lehetővé teszi speciális függvények felvételét egy C program szövegébe. Ezek a funkciók az egyszerűsített C programozási nyelven vannak megírva, és a GPU-n futnak. A CUDA SDK kezdeti verziója 2007. február 15-én jelent meg. A kód sikeres lefordításához ezen a nyelven a CUDA SDK saját C-fordítót tartalmaz parancs sor nvcc az NVIDIA-tól. Az nvcc fordító a nyissa meg a fordítót Open64, és arra készült, hogy a gazdagép kódot (fő, vezérlőkód) és eszközkódot (hardverkódot) (.cu kiterjesztésű fájlok) objektumfájlokká fordítsa, amelyek alkalmasak a végső program vagy könyvtár felépítésére bármilyen programozási környezetben, például Microsoft Visual stúdió.

Technológiai képességek

1. A C szabványos nyelv a GPU-alkalmazások párhuzamos fejlesztéséhez.
2. Kész numerikus elemzési könyvtárak a gyors Fourier-transzformációhoz és a lineáris algebrai programok alapcsomagja.
3. Dedikált CUDA-illesztőprogram a számítástechnikához gyors adatátvitellel a GPU és a CPU között.
4. A CUDA-illesztőprogram lehetősége együttműködni az OpenGL és a DirectX grafikus illesztőprogramokkal.
5. Műtős támogatás Linux rendszerek 32/64 bites, 32/64 bites Windows XP és MacOS.

Technológiai előnyök

1. A CUDA alkalmazásprogramozási felület (CUDA API) a szabványos C programozási nyelven alapul, néhány korlátozással. Ez leegyszerűsíti és simábbá teszi a CUDA architektúra tanulási folyamatát.
2. A szálak közötti 16 KB-os megosztott memória szélesebb sávszélességű, felhasználó által szervezett gyorsítótárhoz használható, mint a normál textúrákból történő lekéréskor.
3. Hatékonyabb tranzakciók a CPU-memória és a videomemória között.
4. Teljes hardveres támogatás egész és bitenkénti műveletekhez.

Példa a technológia alkalmazására

cRark

A program legnehezebb része a tinktúra. A program konzolos felülettel rendelkezik, de magával a programhoz tartozó utasításoknak köszönhetően használható. A következő rövid utasítás a program beállításához. Teszteljük a program teljesítményét, és összehasonlítjuk egy másik hasonló programmal, amely nem használja az NVIDIA CUDA-t, jelen esetben a jól ismert "Advanced Archive Password Recovery" programmal.

A letöltött cRark archívumból mindössze három fájlra van szükségünk: crark.exe , crark-hp.exe és password.def . A Сrark.exe egy RAR 3.0 jelszófeltörő, titkosított fájlok nélkül az archívumban (azaz az archívumot megnyitva látjuk a neveket, de jelszó nélkül nem tudjuk kicsomagolni az archívumot).

A Сrark-hp.exe egy parancssori RAR 3.0 jelszótörő segédprogram, amely a teljes archívumot titkosítja (azaz archívum megnyitásakor nem látjuk sem a nevet, sem magát az archívumot, és nem tudjuk kicsomagolni az archívumot jelszó nélkül).

A Password.def bármilyen átnevezett szövegfájl nagyon kevés tartalommal (például: 1. sor: ## 2. sor: ?* , ebben az esetben a jelszó minden karaktert használva feltörik). A Password.def a cRark program feje. A fájl tartalmazza a jelszó megnyitásának szabályait (vagy azt a karakterterületet, amelyet a crark.exe a munkájában fog használni). A karakterek kiválasztásának lehetőségeiről további részletek a cRark program szerzőjétől letöltött oldal megnyitásával kapott szöveges fájlban találhatók: russian.def .

Kiképzés

Azonnal el kell mondanom, hogy a program csak akkor működik, ha a videokártyája olyan GPU-n alapul, amely támogatja a CUDA 1.1 gyorsítási szintet. A G80 chipre épülő videokártyák sora tehát szóba sem jöhet, mint például a GeForce 8800 GTX , hiszen ezek hardveres támogatással rendelkeznek a CUDA 1.0-s gyorsításhoz. A CUDA használatával a program csak jelszavakat választ ki a 3.0+ verziójú RAR archívumokhoz. Minden CUDA-val kapcsolatos szoftvert telepíteni kell, nevezetesen:

• A CUDA-t 169.21 óta támogató NVIDIA illesztőprogramok
• NVIDIA CUDA SDK, az 1.1-es verziótól kezdve
• NVIDIA CUDA Toolkit, az 1.1-es verziótól kezdve

Bármilyen mappát létrehozunk bárhol (például a C: meghajtón), és bármilyen néven nevezzük, például "3.2". Oda tettük a fájlokat: crark.exe , crark-hp.exe és password.def, valamint egy jelszóval védett/titkosított RAR archívumot.

Ezután indítsa el a Windows parancssori konzolt, és lépjen a benne létrehozott mappába. Windows Vista és 7 esetén hívja meg a "Start" menüt, és írja be a "cmd.exe" kifejezést a keresőmezőbe, Windows XP esetén a "Start" menüből először hívja meg a "Futtatás" párbeszédablakot, és írja be a "cmd.exe" parancsot. " benne. A konzol megnyitása után írjon be egy ilyen parancsot: cd C:\folder\ , cd C:\3.2 ebben az esetben.

Toborzás be szöveg szerkesztő két sor (a szöveget .bat fájlként is elmentheti a mappába a cRarkkal), hogy kitalálja a jelszóval védett RAR archívum jelszavát titkosítatlan fájlokkal:

visszhang ki;
cmd /K crark (archívum neve).rar

a jelszóval védett és titkosított RAR archívum jelszavának kitalálásához:

visszhang ki;
cmd /K crark-hp (archívum neve).rar

Másoljon 2 sort szöveges fájl lépjen be a konzolba, és nyomja meg az Enter billentyűt (vagy futtassa a .bat fájlt).

eredmények

A visszafejtési folyamat az ábrán látható:

A kiválasztás sebessége a cRark CUDA használatával 1625 jelszó / másodperc volt. Egy perc, harminchat másodperc alatt sikerült kitalálni egy 3 karakteres jelszót: "q)$". Összehasonlításképpen: a kétmagos Athlon 3000+ processzoron az Advanced Archive Password Recovery szolgáltatásban a nyers erő maximum 50 jelszó/másodperc, a nyers erő pedig 5 órát vesz igénybe. Vagyis a RAR archívum bruteforce-val történő kiválasztása cRarkban GeForce 9800 GTX+ videokártya használatával 30-szor gyorsabb, mint egy CPU-n.

Aki Intel processzorral, jó alaplappal rendelkezik magas rendszerbusz-frekvenciával (FSB 1600 MHz), annak nagyobb lesz a CPU sebessége és a nyers erő. És ha van egy négymagos processzora és egy pár GeForce 280 GTX szintű videokártya, akkor a jelszóval történő brute force teljesítménye időnként felgyorsul. Összegezve a példát, el kell mondanunk, hogy ezt a problémát a CUDA technológia segítségével 5 óra helyett mindössze 2 perc alatt sikerült megoldani, ami nagy potenciált jelez ebben a technológiában!

következtetéseket

A párhuzamos számítástechnikai CUDA technológiáját figyelembe véve világosan láttuk a technológia fejlesztésének minden erejét és hatalmas potenciálját egy jelszó-helyreállító program példájával. RAR archívum. El kell mondanom ennek a technológiának a kilátásait, ezt a technológiát minden bizonnyal megtalálja majd a helyét minden ember életében, aki úgy dönt, hogy használja, legyen szó tudományos, vagy videófeldolgozással kapcsolatos, vagy akár gyors pontos számítást igénylő gazdasági feladatokról, mindez elkerülhetetlen munkaerő-növekedéshez vezet. termelékenység, amelyet nem lehet figyelmen kívül hagyni. A mai napig az "otthoni szuperszámítógép" kifejezés már kezd bekerülni a lexikonba; teljesen nyilvánvaló, hogy egy ilyen tárgy valósággá alakításához már minden otthonban van egy CUDA nevű eszköz. A G80 chipen alapuló kártyák megjelenése óta (2006), nagy mennyiség NVIDIA-alapú gyorsítók, amelyek támogatják a CUDA technológiát, amelyek minden otthonban valóra válthatják a szuperszámítógép álmát. A CUDA technológia népszerűsítésével az NVIDIA növeli hitelességét az ügyfelek szemében azáltal, hogy további funkciókat biztosít a berendezéseikhez, amelyeket sokan már megvásároltak. Csak azt kell hinni, hogy a CUDA hamarosan nagyon gyorsan fejlődik, és lehetővé teszi a felhasználók számára, hogy teljes mértékben kihasználják a párhuzamos számítástechnikai GPU-n nyújtott lehetőségeket.