» »

Napovedan prevajalnik CUDA C za x86

Napovedan prevajalnik CUDA C za x86

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.

15 komentarjev

zee ::

Fino. Ravno pred nekaj tedni smo nabavili prevajalnike podjetja Portland Group. 8-)
zee
Linux: Be Root, Windows: Re Boot
Giant Amazon and Google Compute Cloud in the Sky.

Izi ::

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.

kixs ::

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.

kihc ::

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.
x

Aston_11 ::

kihc je izjavil:

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.

dr.J ::

Še vedno je treba imeti CUDA kodo.

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.

Mitch ::

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...:D

kihc ::

Aston_11 je izjavil:


Nimajo že ne vem od kdaj vsi procesorji vgrajen koprocesor, tako da je emulator obsolete? Zlati zaradi x64 mi je padlo v oči.


V mislih sem imel emulator CUDA kode na x86/x64. Nevem kakšen koprocesor imaš v mislih? x64 sem omenil ker dela počasi tako na 32 kot 64 bit winsih.

dr.J: to 'avtoparaleliziranje' je sicer super, samo IMHO je v večini primerov, če hočeš res iztisnit moč grafe, konkretno spremenit algoritem.
x

filip007 ::

Oni mislijo razširiti Cudo da bo pač delala še na CPU, za Radeon se ne bo nič spremenilo.
Toshiba L650 + SSD + Ubuntu LTS.

Mitch ::

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...

Senitel ::

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.

Zgodovina sprememb…

  • spremenil: Senitel ()

dr.J ::

Tale članek je zelo zanimiv:
http://www.hpcwire.com/features/Compile...

HPC scena bo v prihodnjih dveh, treh letih pestra!

Bistri007 ::

Ne pozabiti na Intelov Larrabee!

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.

Larrabee %28microarchitecture%29 @ Wikipedia

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"...

klavdijL ::

hehe.... na tem sem diplomo delal (ok je bla 32bit očinto sam ajt) :)

noraguta ::

sam ne vidim kake bistvene razlike od opencl drajverja pri AMDju. kateri avtomatično fallbacka na procesor.
Pust' ot pobyedy k pobyedye vyedyot!


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

AMD z GPUOpen odpira orodja in gonilnike za svoje grafične čipe

Oddelek: Novice / Grafične kartice
489242 (7173) matijadmin
»

Napovedan prevajalnik CUDA C za x86

Oddelek: Novice / Procesorji
154136 (3057) noraguta
»

Zla koda v grafičnih procesorjih

Oddelek: Novice / Grafične kartice
63375 (2322) denial
»

Prihaja Android 2.2 - Froyo

Oddelek: Novice / Android
308240 (7048) SLO_Matej

Več podobnih tem