Pathscale cerca una alternativa a CUDA e OpenCL

Pathscale cerca una alternativa a CUDA e OpenCL

PathScale è intenzionata a ritagliarsi una presenza nel settore delle elaborazioni GPU Computing, facilitando il lavoro degli sviluppatori software, con un proprio compilatore

di pubblicata il , alle 09:20 nel canale Schede Video
CUDA
 

PathScale è intenzionata ad entrare nel settore delle elaborazioni GPU Computing, proponendo un proprio approccio che, stando alle dichiarazioni, dovrebbe essere di gran lunga preferibile a OpenCL e CUDA dal punto di vista degli sviluppatori software. Tutto questo in collaborazione con altre aziende che operano nel settore, seguendo un approccio open.

PathScale opera nel contesto dei compilatori per architetture di processore x86-64, proponendo una propria soluzione per ambiente Linux estremamente ottimizzata, sviluppata per sfruttare al meglio le potenzialità delle architetture a 64bit sia Intel che AMD.

La scelta di entrare nel mondo delle elaborazioni GPU Computing, nelle quali le moderne GPU sia NVIDIA che ATI vengono utilizzate per elaborare calcoli non legati alla grafica ma di tipo general purpose, è diretta conseguenza dei notevoli incrementi prestazionali che è possibile ottenere, con alcune tipologie di applicazioni, con le GPU.

Stando a quanto dichiarato dal CTO di PathScale, Christopher Bergstrom, la finalità di PathScale in questo ambito è di sviluppare un'alternativa a OpenCL e CUDA che ne mantenga le prestazioni complessive fornendo un modello di programmazione più semplice agli sviluppatori, e quindi più facilmente utilizzabile.

PathScale considera sia CUDA sia OpenCL complessivamente troppo complessi e difficili da gestire per sviluppatori che debbano scrivere un elevato quantitativo di codice. Il riflesso diretto è osservare come buona parte delle elaborazioni di GPU Computing attualmente sul mercato siano legate al contesto della ricerca scientifica, più abituata allo sviluppo di codice specialistico per le proprie necessità di elaborazione.

Il fine di PathScale è quindi quello di fornire strumenti che possano sia ottimizzare lo switch alla GPU di quelle applicazioni che richiedano una parziale integrazione del codice per poter venir eseguito sulla GPU, sia gestire in modo completamente automatizzato il passaggio del codice dalla CPU alla GPU, di fatto semplicemente attraverso una operazione di ricompilazione fatta dallo sviluppatore.

L'operazione non è semplice: per sviluppare un prodotto di questo tipo PathScale deve gestire, con il proprio compilatore, anche il runtime e il kernel del driver: questo implica la necessità di uno stretto rapporto di collaborazione con sviluppatori open source, che possano aiutare nello sviluppo di driver specifici. Da questo deriva un primo programma di collaborazione con gli sviluppatori, che prevede la fornitura di alcune schede video della famiglia Fermi con le quali poter avviare l'operazione di scrittura e ottimizzazione dei driver. Al momento attuale l'iniziativa, sulla carta molto interessante, è ancora in piena fase di sviluppo e non sono stati coinvolti gli sviluppatori di GPU.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

16 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
chinook28 Aprile 2010, 09:40 #1
Sembra infatti che PathScale donerà 3 schede Fermi al team di Nouveau per reverse engineering.
Nouveau è il progetto più attivo ed avanzato nello sviluppo di driver nVidia open-source.
demon7728 Aprile 2010, 10:11 #2
Boh.. sinceramente a me sembra di vedee una sempre crescente frammentazione di linguaggi e soluzioni che creano ancora più confusione di quella che già c'è!

Senza contare poi il fatto che nonostante il tanto sbandierare soluzioni e kit di sviluppo ad oggi la presenza di software UTILE in ambito desktop che faccia un uso della GPU è praticamete ZERO.
elevul28 Aprile 2010, 10:15 #3
Originariamente inviato da: demon77
Boh.. sinceramente a me sembra di vedee una sempre crescente frammentazione di linguaggi e soluzioni che creano ancora più confusione di quella che già c'è!

Senza contare poi il fatto che nonostante il tanto sbandierare soluzioni e kit di sviluppo ad oggi la presenza di software UTILE in ambito desktop che faccia un uso della GPU è praticamete ZERO.


Ed il motivo è proprio la complessità di programmazione, a cui il progetto Terascale vuole porre rimedio.
ede28 Aprile 2010, 10:20 #4
Il fine di PathScale è quindi quello di fornire strumenti che possano sia ottimizzare lo switch alla GPU di quelle applicazioni che richiedano una parziale integrazione del codice per poter venir eseguito sulla GPU, sia gestire in modo completamente automatizzato il passaggio del codice dalla CPU alla GPU, di fatto semplicemente attraverso una operazione di ricompilazione fatta dallo sviluppatore.


La radicale differenza di architettura tra CPU e GPU impone una radicale differenza nel modo in cui si scrivono i programmi, a mio parere è impossibile avere un compilatore in grado di far girare lo stesso codice sull'una o sull'altra, a meno di pagare un prezzo enorme in termini di prestazioni (e in questo caso sarebbe totalmente inutile).
The_Saint28 Aprile 2010, 10:27 #5
Originariamente inviato da: demon77
Senza contare poi il fatto che nonostante il tanto sbandierare soluzioni e kit di sviluppo ad oggi la presenza di software UTILE in ambito desktop che faccia un uso della GPU è praticamete ZERO.
Questo non è vero, pian piano i software arrivano: Adobe Photoshop ed i principali software di modellazione 3D già fanno uso intenso della GPU (per citare i primi che mi vengono in mente)... non mi pare che siano software inutili...

Anche il nuovo Falsh Player utilizza la GPU per accelerare i video, per non parlare dei vari media player con supporto CUDA, etc...
fabri8528 Aprile 2010, 11:06 #6
la potenza dell'open-sources !
AleLinuxBSD28 Aprile 2010, 11:07 #7
Lato sviluppatori, almeno in ambito open, temo sia difficile riscuotere interesse:
PathScale EKO Compiler Suite

Lato utente finale, come utente linux.
nVidia e parzialmente Ati non rilasciano tutte le specifiche dei loro prodotti ma, al contempo, per lo sviluppo di questi driver è richiesta la collaborazione della community.

Quindi presumo saranno open e free.

Ma basandosi sulle specifiche open o con il reverse engine non possono essere completi di tutte le funzionalità presenti nell'hardware.

Se invece fossero completi, dovrebbero fare accordi con nvidia ed ati, ma allora non potrebbero rilasciare driver open.
publiorama28 Aprile 2010, 11:23 #8
Premetto che sviluppo su OpenGL/CL da molto tempo, mi scontro con le GPU e relativi driver dalla mattina alla sera, quindi ci tengo a precisare due cose. (Utente Linux, per precisare)

Primo: anche se le specifiche dei registri e tutta la documentazione relativa ad una famiglia di GPU fossero disponibili, sarebbe MOOLTO difficile per un team open source raggiungere i livelli qualitativi dei driver proprietari NVidia.
Il driver di una GPU (peggio ancora, di un'intera famiglia) e' un pezzo di software molto complesso, molto di piu' di quanto lo possa essere un driver per una scheda di rete e audio. Solo chi ci lavora a contatto 24H sarebbe in grado di fare un buon lavoro, e dubito che un team open source possa farlo anche se finanziato, senza contare che ad ogni piccola variazione di architettura, si dovrebbero aspettare mesi per avere qualcosa di funzionante, e questo non e' accettabile da chi spende dei soldi e pretende di avere il massimo da quello che compra, soprattutto in ambito professionale.

Secondo: il problema dello sviluppo su GPGPU e' il testing/debugging.
Su GPU e' molto facile avere l'algorimo ottimizzato, poiche' basta scrivere un kernel che opera su un oggetto e la GPU di occupa di distribuire. Pero' e' molto piu' difficile arrivare ad evere qualcosa di funzionante. Su GPU la catena di set-up dei dati, testing e debugging e' molto piu' complessa. La difficolta' arriva da questo, non dal fatto che si debba scrivere il sorgente in turco.
Su CPU scrivi un for e codice alla c****o di cane e riesci a testarlo e fare debug molto facilmente. Poi puoi passare a ottimizzarlo, in maniera incrementale.
RunAway28 Aprile 2010, 12:00 #9
Mah siamo alle solite. Si era trovato uno standard per il GPGPU, approvato in tempi record che ha cominciato da poco ad essere utilizzato, mi riferisco ad OpenCL, ed ecco che spunta un'altro che vuole reinventare la ruota.
Bho perchè non contribuire invece al miglioramento delle specifiche di OpenCL che sicuramente non è perfetto, ma almeno è standard?
JackZR28 Aprile 2010, 13:47 #10
Quoto RunAway

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^