| Rubrike | Edukacija | Budućnost je hUMA
Edukacija

Budućnost je hUMA


Približavanje GPU i CPU svetova

 

Najveći razlozi za potpun prelazak na koherentni pristup memorije između GPU-a i CPU-a su znatno olakšanje prilikom primene programskog modela, isključenje potrebe za specijalizovanim API-jem, što bi trebalo da znači GPU uz adekvatan drajver i SPP biblioteku bez problema može da izvršava i CPU kod naročito tamo gde je to potrebno. Hardverska koherencija podataka je daleko efikasnije rešenje nego softverska, a ono što olakšava celu priču oko programiranja jeste isključenje potrebe za implementacijom softverske koherencije svaki put iznova kada se piše aplikacija. Pored ovoga jedan od bitnih faktora predstavlja i znatno lakše debug-ovanje koda, jer sa različitim code profiler-ima moguće je lakše pronaći adresu gde je greška u kodu. Operativni sistemi preferiraju hardversku koherenciju, a probe filteri smanjuju efikasnost i povećavaju potrošnju zbog čestih provera koherentnosti podataka. Potpuna koherencija otvara vrata za jedinstvenim kodom, nativno izvedenim za heterogenu platformu. hUMA zbog ovoga predstavlja optimalno rešenje za heterogene platforme kao što su APU i SOC (system on chip).

 

13

15

 

HSA Solution Stack predstavlja softverski nivo koji služi da premosti razlike između CPU i GPU svetova. Konkretno, na hardverskom nivou CPU i GPU „govore“ potpuno različitim jezicima. Kako je moguće da GPU „progovori“ CPU jezikom? Pa uz pomoć izvesnog softverskog layer-a. Sigurno ste pomislili da će ovo uticati na performanse? To je pitanje na koje sada ne možemo da damo precizan odgovor, ali verujemo da je AMD-ova HSA runtime biblioteka napisana na najoptimalniji moguć način, a korišćenje HUMA arhitekture umnogome će olakšati implementaciju ovog koncepta. Konkretno, HSA Runtime funkcioniše na sličnom principu kao i Java Runtime Enviroment. Dakle, generiše se neka vrsta bytecode-a, koji predstavlja prelazni kod između hardvera i softvera odnosno HSAIL – HSA intermediate language. Dalje ovaj međukod se prevodi na jezik samog hardvera, gde se izvršava. Prevođenje se izvršava u „letu“, uz pomoć LLVM – Low Level Virtual Machine-a. Ovaj najniži softverski layer napisan je u C++ programskom jeziku i kompajliran je na izvršni jezik samog hardvera. Podržava širok spektar „front-end“ jezika, kao što su npr. ActionScript, Ada, D, Fortran, GLSL, Haskell, Java bytecode, Objective-C, Python, Ruby, Rust, Scala i C#. Ono što je zajedničko za sve ove jezike je da su u pitanju jezici koji rade na virtuelnim mašinama, dakle, Java koristi JRE, C# koristi .NET framework, što im omogućava prenosivost, odnosno portabilnost. Dakle, HSA runtime obezbeđuje front end kompatibilnost sa različitim softverskim rešenjima, npr. OpenCL, C++ AMP (Accelerated Massive Paralelism) itd…dok se HSA finalizer koristi kao najniži sloj koji se stara da „međukod“ bude izvršen na odgovarajućem hardveru, npr. GPU.

 

hsa stack

 

Ukoliko napišete sotftver koji koristi neku od novijih verzija .NET framework-a, Jave, vaš softver će u HSA okruženju sa hUMA arhitekturom koristiti CPU i GPU podjednako. Dakle, stariji softver pisan u C++, koji koristi starije verzije kompajlera, NEĆE koristiti prednosti HSA, ali sav noviji softver pisan u C++ AMP, uključujući i skript jezike bi mogao lako da bude ubrzan zahvaljujući HSA.

 

Tagovi

Ivan Vujić

Software, storage, network etc editor @ AXE
Database migration @ RC ETF

Dodaj komentar

Kliknite ovde da biste poslali komentar