X-Bit Labs - Nvidia in Portland Group sta objavila, da razvijata prevajalnik CUDA C za platformo x86. Aplikacije, napisane za platformo CUDA, se namreč izredno hitro izvajajo na sistemih z grafičnimi procesorji Nvidia, medtem ko se na tistih brez zelo težko ali pa sploh ne. Nov prevajalnik bo to popravil, saj se bodo v odsotnosti Nvidiinih GPU-jev aplikacije izvajale z AMD-jevimi ali Intelovimi procesorji s podporo SIMD (Single Instruction Multiple Data). Nov prevajalnik bodo predstavili na konferenci SC10 Supercomputing, ki bo med 13. in 15. novembrom v New Orleansu. Takrat bomo tudi dobili prve vtise o hitrosti izvajanja, ki utegne biti problematična, če bodo aplikacije slabo prevedene iz nabora CUDA v x86 ali obratno.
Nvidia in Portland Group skupaj razvijata prevajalnik. In ker ima Nvidia trenutno monopol, ker zadeva deluje samo na njihovih GPU-jih, je nemogoče pričakovati, da bo na CPU-jih zadeva kakorkoli konkurenčna izvajanju na GPU-jih, ker jo bo sedaj mogoče poganjati tudi na AMD-jevih CPU-jih. Ne gre pričakovati, da si bodo pljuvali v lastno skledo.
Ne vem, ce ima to kaksen smisel. Tako kot pred leti, ko si imel sofverski emulator matematicnega koprocesorja. Program, ki sicer brez matematicnega koprocesorja ni delal, je potem delal. Vendar ni bilo za uporabljat, ker je delal zelo pocasi.
IMO je to mišljeno za debug, da se bo malo lažje(hitreje) izvajalo na emulatorju, ne vem kaj ima smisel zadevo spravljat na x86, če gre za popolnoma drugačno arhitekturo (SIMT).
Pa kolikor imam izkušenj emulator dela čisto spodobno (tako x86 kot x64), samo počasen je.
IMO je to mišljeno za debug, da se bo malo lažje(hitreje) izvajalo na emulatorju, ne vem kaj ima smisel zadevo spravljat na x86, če gre za popolnoma drugačno arhitekturo (SIMT).
Pa kolikor imam izkušenj emulator dela čisto spodobno (tako x86 kot x64), samo počasen je.
Nimajo že ne vem od kdaj vsi procesorji vgrajen koprocesor, tako da je emulator obsolete? Zlati zaradi x64 mi je padlo v oči.
PGI pa je že lani jeseni naredil akcelerator, kjer v fortranski program vstaviš nekaj ukazov, podobnih tistim v OpenMP. Prevajalnik nato naredi program, kjer nekatere stvari računa na grafični kartici.
Samo problem mora biti dovolj velik, sicer se preveč časa izgubi na sami komunikaciji z grafično kartico. Moja izkušnja je bila taka; prav veliko se pa v to zaradi pomanjkanja časa žal nisem več poglabljal.
Poskusil sem en podprogram za faktorizacijo matrik (www.culatools.com); v enojni floating-point natančnosti dela CUDA podprogram cca 30-krat hitreje kot z vsemi otimizacijami prevedena serijska koda. (Nvidia 275 GTX in C2Q 2.93 GHz; GTX 470 je še za 10% hitrejša od GTX 275 v single precision). Seveda je tule delalo eno jedro od štirih in pa cela grafična kartica.
Haha... Sem mislil, da bo zadeva v odsotnosti Nvidia GPUja program prevedla v OpenCL ali Ati Stream program in omogočila strojno pospeševanje na AMDjevih GPUjih... Tako bo pa zadeva funkcionirala podobno kot Nvidia Physics, ki fiziko poganja na CPUju, če ni Nvidia čipa notri... Pa še to uporablja x87 matematični koprocesor namesto SIMD inštrukcij...
Zadeva bi bila lahko zasnovana kot Cg, ki prevaja v OpenGL (GLSL) ali pa v DirectX (HLSL), samo da bi tukaj prevajala v DirectCompute ali pa v OpenCL...
Torej... Kot je že kihc omenil: CUDA ima x86/64 compiler že od samega začetka. Ta compiler je relativno dobro optimiziran za x86/64. Sicer zadeva ni multithreaded ampak uporablja pa SSE. Multithreading je v tem primeru treba delat ročno, torej poganjat kernele vzporedno iz večih niti. Tudi je treba kodo eksplicitno prevesti za to emulacijo. Ta koda potem ne bo tekla na GPU-ju, niti nima istih omejitev!
Kar PGI dela je nov compiler za HPC uporabnike. Oziroma bolje rečeno: dodal bodo "C for CUDA" razširitve še za svoje C/C++ compilerje, kar so že naredili za Fortran. Portland ima cel ekosistem za poganjat/debugirat/optimizirat HPC aplikacije. Kar konkretno ta compiler pomeni je, da bodo lahko vsi uporabljal "C for CUDA" razširitve na svojih clustrih, tudi če (še) nimajo GPU-jev v rackih.
Ampak en kup ljudi še vedno ne ve kaj vse zajema CUDA. Kar se NV tiče je CUDA (Compute Unified Device Architecture) in vključuje VSE kar ima veze z izvajanjem "compute" problemov na GPU-ju, nima veze a je DX Compute, C for CUDA, Python, Matlab... Nekako tako kot je danes povsem samoumnevno, da pridejo grafični driverji s podporo za Direct3D 9/Direct3D 10/11/OpenGL 2.x/3.x in obenem še čez par bistveno različnih generacij GPU-jev (trenutno so za NV to: Curie, Tesla in Fermi). V konkretnem primeru se pogovarjamo o "C for CUDA" razširitvah. Torej, da lahko v C/C++ kodi direkt programiraš za GPU. Da ti ni treba klicat nekega API-ja, ter mu dat neko kodo, ki jo potem on prevede,... ampak lahko vse skup kombiniraš tako kot lahko kombiniraš C in C++. Ala C koda gre čez gcc, C++ gre čez g++, C for CUDA gre pa čez NVCC potem se objektna koda še linka skup in zapakira v en lep executable ali knjižnico. OpenCL tega ne ponuja. DirectCompute je pa za HPC tako ali tako neuporaben.
On May 25, 2010 the Technology@Intel blog announced that Larrabee would not be released as a GPU, but instead would be released as a product for High Performance Computing competing with the Nvidia Tesla.
V trenutni inkarnaciji Larrabee ne bo v GPUjih, bo pa v prihodnjih izdajah.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...
