NVIDIA promuove la GPU Computing in ambito universitario

[nexor]

Ma Apple per snow leopard (o come si chiama), che dovrebbe usare le gpu per alcune operazioni, si sa che linguaggio stia usando?
Non credo si pieghino a usare cuda se li costringe a legarsi ad nvidia, perciò magari stanno usando soluzioni alternative che si potrebbero espandere a linux e poi altrove come è successo in passato, possibile?

[Marco71]

...dal numero di transistor disponibili/deputati in questo caso al calcolo in virgola mobile/calcolo vettoriale precipuo degli ambienti di supercomputing.
Una c.p.u general purpose come quelle che equipaggiano gli odierni (diciamo in ambito x86 a partire dall'8080 in poi...anche se la prima c.p.u con I.S.A x86 fu l'8086 e la sua variante con bus dati ad 8 bit 8088) nostri personal computer dovendo essere un "uomo per tutte le stagioni" possiede al suo interno un numero ridotto di unità f.p.u, s.i.m.d (queste molto spesso funzionano utilizzando un microcodice con relativo sequencer invece di una implementazione hard-wired che farebbe aumentare il numero di transistor (M.O.S) a dismisura).
Questo ante-Nehalem...se con Nehalem Intel riproporrà un paradigma già sperimentato con l'80860 (e suoi derivati) di nuovo la c.p.u tornerà ad essere e caratterizzarsi per ciò che esprime il suo acronimo: central processing unit...
Personalmente io sono (problemi tecnologici a parte) per la massima integrazione possibile...come per l'unità (o le unità) centrali a rete neurale con elementi non specializzati tipici dell'universo "Terminator" per intenderci ove sono possibili elaborazioni di ogni tipo e su qualsiasi dominio: grafico, di calcolo balistico, di elaborazione di dati provenienti da sensori, di calcolo numerico puro ecc. ecc.
Ovviamente la fame di dati da elaborare presuppone che la c.p.u o g.p.u che sia, non abbia uno dei limiti delle architetture di computer secondo Von Neumann e cioè la velocità, ampiezza di banda da e verso i banchi di memoria centrale...che sarebbe auspicabile poter un giorno integrae pure essi in una c.p.u...
Un Intel i800 con memoria interna (a questo punto non "cache" come intesa oggi) di qualche PiB, qualche centinaia di migliaia di unità di processo general purpose connesse secondo un ipercubo a dimensioni (fate voi quante) potrebbe divenire una ottima "piattaforma" per un "calcolatore universale" che probabilmente potrebbe superare il test di Turing.
Il sistema C.U.D.A di NVidia Corp. mi "intrippa" non poco...slurp...
Peccato che A.M.D ancora latiti in questo settore...per B.O.I .N.C sarebbe una vera rivoluzione...in Seti@home si potrebbe finalmente fare uso della trasformata di Karhunen-Loève in luogo dell'ubiquo utilizzo che si fa invece della trasformata discreta con algoritmi di F.F.T.
Grazie.

Marco71.

[!fazz]

Originariamente inviato da nexor

Ma Apple per snow leopard (o come si chiama), che dovrebbe usare le gpu per alcune operazioni, si sa che linguaggio stia usando?
Non credo si pieghino a usare cuda se li costringe a legarsi ad nvidia, perciò magari stanno usando soluzioni alternative che si potrebbero espandere a linux e poi altrove come è successo in passato, possibile?

un suo linguaggio: openCL

[nexor]

Originariamente inviato da !fazz

un suo linguaggio: openCL

Ok, grazie!
Vedo su Wikipedia che lo supporta anche AMD, e su linux già ci si muove... quindi forza openCL e abbasso CUDA!

Comunque sia spero che il gpgpu prenda piede presto.

[!fazz]

Originariamente inviato da nexor

Ok, grazie!
Vedo su Wikipedia che lo supporta anche AMD, e su linux già ci si muove... quindi forza openCL e abbasso CUDA!

Comunque sia spero che il gpgpu prenda piede presto.

io aspetto snow leopard, lascio passare un paio di mesi e abbandono tiger se il gpgpu fà quel che promette

[II ARROWS]

Ero rimasto che qualche mese fa annunciavano il lavoro sulle schede nVidia, non avevo letto nulla sulla disponibilità del programma funzionante.

E poi, dire che va meglio dipende sempre dalle schede che usi. Se prendi una 280 e la metti a confronto con una X1900 è normale. Se lo fai da 280 contro HD4870x2 è un altro.

[oclla]

Bello. Mooolto molto bello.
Mi piacerebbe finire a lavorare sulle schedozze video.. anche se mettere le mani su veri supercomputer è stato entusiasmante..

Originariamente inviato da lowenz

Da quel che mi dicono dalla regia ci sono già 10 tesi al PoliMI sul GPU Computing.....e se per caso poi si allacciassero agli applicativi più classicamente da informatici quelli di telecomunicazioni e biomedica (bioimmagini ad esempio) il gioco è fatto

per esempio...

Originariamente inviato da giovannifg

Scusate l'ignoranza, ma qualcuno potrebbe con calma e ordine elencare i vantaggi di far eseguire certe operazioni alla GPU anzinchè alla CPU? E quali sono esattamente queste operazioni? A quanto ho capituo, il transcoding di video è sicuramente una di queste... ma le altre?

Originariamente inviato da giovannifg

Grazie per la risposta! E questo non è possibile con le CPU? Insomma, a livello costruttivo, quali sarebbero le differenze principali? Perchè una GPU è più indicata per questo tipo di calcoli rispetto ad una CPU?

Estremamente concentrato:
Un processore ha una (anche due) unità di calcolo, una scheda video ne ha centinaia. (112 la mia per esempio.. 240 la gtx280).

Quando si tratta di fare tante tante operazioni (simili), una vga ne fa appunto centinaia alla volta

[SwatMaster]

Mhmh... And where's Ati?

[wlog]

Originariamente inviato da nexor

Ok, grazie!
Vedo su Wikipedia che lo supporta anche AMD, e su linux già ci si muove... quindi forza openCL e abbasso CUDA!

Comunque sia spero che il gpgpu prenda piede presto.

il problema è che opencl non è ancora maturo e adatto alla produzione di codice

[Mercuri0]

Chi porta soldi è sempre ben accetto. Venghino venghino che abbiamo bisogno!

Originariamente inviato da nexor

Ma Apple per snow leopard (o come si chiama), che dovrebbe usare le gpu per alcune operazioni, si sa che linguaggio stia usando?
Non credo si pieghino a usare cuda se li costringe a legarsi ad nvidia, perciò magari stanno usando soluzioni alternative che si potrebbero espandere a linux e poi altrove come è successo in passato, possibile?

Apple sta per lanciare un linguaggio chiamato OpenCL che sarà supportato da AMD & nVidia. E direi pure lntel.

La cosa molto figa, è che Apple (bontà sua!) ha proposto OpenCL come standard al Khronos Group, un'organizzazione a cui partecipano tutti (i tre di sopra più tanti altri tra hardwaristi e softwaristi. C'è anche Blizzard, per dire), e che tra le altre cose gestisce anche OpenGL.

Il supporto di OpenCL su Linux è legato solo alla volontà di AMD e nVidia di scrivere i driver, che di certo non mancherà.

Su Windows è uguale, non c'è nessun problema tecnico ma al massimo politico.

edit: in effetti, mi sento di essere grato ad Apple, per questa volta.

edit2: Blizzard ha le mani in pasta nel gruppo che decide le specifiche dell'OpenGL, e i suoi programmatori vanno in giro a fare conferenze su come si programma la grafica dei giochi. Non si direbbe, eh?

Simpaticissime le risposte quando il loro uomo posta sui forum di OpenGL. "Si, si, grazie Rob ma adesso fila a lavorare a Diablo 3"

[Mercuri0]

Originariamente inviato da giovannifg

Scusate l'ignoranza, ma qualcuno potrebbe con calma e ordine elencare i vantaggi di far eseguire certe operazioni alla GPU anzinchè alla CPU? E quali sono esattamente queste operazioni? A quanto ho capituo, il transcoding di video è sicuramente una di queste... ma le altre?

In campo scientifico troverà di certo interessanti applicazioni, sopratutto per quei conti che tipicamente durano ore o giorni.

In campo desktop, "boh". Si parla di trascodifica video, editing immagini (su questo ho molte speranze), forse editing video, e se tutto va bene rendering 3D.

Del resto quali sono le altre applicazioni Desktop per cui serve potenza di calcolo al giorno d'oggi? (per l'editing audio ormai abbiamo CPU da buttare)

Però siamo ancora ai primissimi passi, e bisogna aspettare che il "fumo" si diradi per vedere dove sarà davvero utile la GPU, e dove conviene un buon procio.

Ci sta inoltre che le GPU future saranno ancora più flessibili, proprio per facilitare queste applicazioni.

[^^lee]

...dal numero di transistor disponibili/deputati in questo caso al calcolo in virgola mobile/calcolo vettoriale precipuo degli ambienti di supercomputing.
Una c.p.u general purpose come quelle che equipaggiano gli odierni (diciamo in ambito x86 a partire dall'8080 in poi...anche se la prima c.p.u con I.S.A x86 fu l'8086 e la sua variante con bus dati ad 8 bit 8088) nostri personal computer dovendo essere un "uomo per tutte le stagioni" possiede al suo interno un numero ridotto di unità f.p.u, s.i.m.d (queste molto spesso funzionano utilizzando un microcodice con relativo sequencer invece di una implementazione hard-wired che farebbe aumentare il numero di transistor (M.O.S) a dismisura).
Questo ante-Nehalem...se con Nehalem Intel riproporrà un paradigma già sperimentato con l'80860 (e suoi derivati) di nuovo la c.p.u tornerà ad essere e caratterizzarsi per ciò che esprime il suo acronimo: central processing unit...
Personalmente io sono (problemi tecnologici a parte) per la massima integrazione possibile...come per l'unità (o le unità) centrali a rete neurale con elementi non specializzati tipici dell'universo "Terminator" per intenderci ove sono possibili elaborazioni di ogni tipo e su qualsiasi dominio: grafico, di calcolo balistico, di elaborazione di dati provenienti da sensori, di calcolo numerico puro ecc. ecc.
Ovviamente la fame di dati da elaborare presuppone che la c.p.u o g.p.u che sia, non abbia uno dei limiti delle architetture di computer secondo Von Neumann e cioè la velocità, ampiezza di banda da e verso i banchi di memoria centrale...che sarebbe auspicabile poter un giorno integrae pure essi in una c.p.u...
Un Intel i800 con memoria interna (a questo punto non "cache" come intesa oggi) di qualche PiB, qualche centinaia di migliaia di unità di processo general purpose connesse secondo un ipercubo a dimensioni (fate voi quante) potrebbe divenire una ottima "piattaforma" per un "calcolatore universale" che probabilmente potrebbe superare il test di Turing.
Il sistema C.U.D.A di NVidia Corp. mi "intrippa" non poco...slurp...
Peccato che A.M.D ancora latiti in questo settore...per B.O.I .N.C sarebbe una vera rivoluzione...in Seti@home si potrebbe finalmente fare uso della trasformata di Karhunen-Loève in luogo dell'ubiquo utilizzo che si fa invece della trasformata discreta con algoritmi di F.F.T.
Grazie.

Marco71.


ahem....eh????

[yossarian]

Originariamente inviato da ^^lee

...dal numero di transistor disponibili/deputati in questo caso al calcolo in virgola mobile/calcolo vettoriale precipuo degli ambienti di supercomputing.
Una c.p.u general purpose come quelle che equipaggiano gli odierni (diciamo in ambito x86 a partire dall'8080 in poi...anche se la prima c.p.u con I.S.A x86 fu l'8086 e la sua variante con bus dati ad 8 bit 8088) nostri personal computer dovendo essere un "uomo per tutte le stagioni" possiede al suo interno un numero ridotto di unità f.p.u, s.i.m.d (queste molto spesso funzionano utilizzando un microcodice con relativo sequencer invece di una implementazione hard-wired che farebbe aumentare il numero di transistor (M.O.S) a dismisura).
Questo ante-Nehalem...se con Nehalem Intel riproporrà un paradigma già sperimentato con l'80860 (e suoi derivati) di nuovo la c.p.u tornerà ad essere e caratterizzarsi per ciò che esprime il suo acronimo: central processing unit...
Personalmente io sono (problemi tecnologici a parte) per la massima integrazione possibile...come per l'unità (o le unità) centrali a rete neurale con elementi non specializzati tipici dell'universo "Terminator" per intenderci ove sono possibili elaborazioni di ogni tipo e su qualsiasi dominio: grafico, di calcolo balistico, di elaborazione di dati provenienti da sensori, di calcolo numerico puro ecc. ecc.
Ovviamente la fame di dati da elaborare presuppone che la c.p.u o g.p.u che sia, non abbia uno dei limiti delle architetture di computer secondo Von Neumann e cioè la velocità, ampiezza di banda da e verso i banchi di memoria centrale...che sarebbe auspicabile poter un giorno integrae pure essi in una c.p.u...
Un Intel i800 con memoria interna (a questo punto non "cache" come intesa oggi) di qualche PiB, qualche centinaia di migliaia di unità di processo general purpose connesse secondo un ipercubo a dimensioni (fate voi quante) potrebbe divenire una ottima "piattaforma" per un "calcolatore universale" che probabilmente potrebbe superare il test di Turing.
Il sistema C.U.D.A di NVidia Corp. mi "intrippa" non poco...slurp...
Peccato che A.M.D ancora latiti in questo settore...per B.O.I .N.C sarebbe una vera rivoluzione...in Seti@home si potrebbe finalmente fare uso della trasformata di Karhunen-Loève in luogo dell'ubiquo utilizzo che si fa invece della trasformata discreta con algoritmi di F.F.T.
Grazie.

Marco71.


ahem....eh????

hai la signature irregolare

[yossarian]

Originariamente inviato da gabi.2437

Si spiega col fatto che sei rimasto PARECCHIO indietro, folding@home supporta nvidia da parecchi mesi, e pure in modo più efficiente (purtroppo... ma avremo la rivincita presto )

ATI deve svegliarsi, ha CAL, che è come CUDA, ci butta su un pò di marketing e combatte CUDA... perchè tanto a efficienza di codice siamo lì lì quindi non c'è un "meglio"

Ma certo che finchè CUDA di qua e CUDA di là, hai voglia che ATI non la caga nessuno......

Poi, la CPU fa TUTTO quello che una GPU può fare, il succo è la velocità, la GPU può fare solo alcune cose, ma quelle poche cose che fa le fa MOLTO velocemente (decine o centinaia di volte più veloce)

CAL e CUDA sono cose differenti: CAL è simil assembly CUDA è C-like. L'equivalente di CUDA è brooks (open, sviluppato da stanford) o brooks+ (proprietario, basato su brooks e sviluppato in collaborazione con stanford). Brooks è l'interfaccia di alto livello tra programmatore e CAL. Chi ha buone conoscenze dell'architettura della gpu può utilizzare direttamente CAL (che diventa, in questo caso, uno strumento molto più potente di quanto non siano i linguaggi C-like)

Originariamente inviato da Mercuri0

Chi porta soldi è sempre ben accetto. Venghino venghino che abbiamo bisogno!



Apple sta per lanciare un linguaggio chiamato OpenCL che sarà supportato da AMD & nVidia. E direi pure lntel.

La cosa molto figa, è che Apple (bontà sua!) ha proposto OpenCL come standard al Khronos Group, un'organizzazione a cui partecipano tutti (i tre di sopra più tanti altri tra hardwaristi e softwaristi. C'è anche Blizzard, per dire), e che tra le altre cose gestisce anche OpenGL.

Il supporto di OpenCL su Linux è legato solo alla volontà di AMD e nVidia di scrivere i driver, che di certo non mancherà.

Su Windows è uguale, non c'è nessun problema tecnico ma al massimo politico.

edit: in effetti, mi sento di essere grato ad Apple, per questa volta.

edit2: Blizzard ha le mani in pasta nel gruppo che decide le specifiche dell'OpenGL, e i suoi programmatori vanno in giro a fare conferenze su come si programma la grafica dei giochi. Non si direbbe, eh?

Simpaticissime le risposte quando il loro uomo posta sui forum di OpenGL. "Si, si, grazie Rob ma adesso fila a lavorare a Diablo 3"

c'è anche ID; e pure Epic

[yossarian]

Originariamente inviato da Marco71

...dal numero di transistor disponibili/deputati in questo caso al calcolo in virgola mobile/calcolo vettoriale precipuo degli ambienti di supercomputing.
Una c.p.u general purpose come quelle che equipaggiano gli odierni (diciamo in ambito x86 a partire dall'8080 in poi...anche se la prima c.p.u con I.S.A x86 fu l'8086 e la sua variante con bus dati ad 8 bit 8088) nostri personal computer dovendo essere un "uomo per tutte le stagioni" possiede al suo interno un numero ridotto di unità f.p.u, s.i.m.d (queste molto spesso funzionano utilizzando un microcodice con relativo sequencer invece di una implementazione hard-wired che farebbe aumentare il numero di transistor (M.O.S) a dismisura).
Questo ante-Nehalem...se con Nehalem Intel riproporrà un paradigma già sperimentato con l'80860 (e suoi derivati) di nuovo la c.p.u tornerà ad essere e caratterizzarsi per ciò che esprime il suo acronimo: central processing unit...

mi sfugge questo passaggio: per quale motivo le cpu ante nehalem non sarebbe delle c.p.u.? Quali sono le caratteristiche di un processore che permettano di definirlo cpu? E comunque gli approcci di intel al calcolo parallelo sembrano andare in direzione opposta rispetto a quanto tu ha indicato: così è per l'architettura EPIC di Itanium e così per il terascale computing (larrabee)

Originariamente inviato da Marco71

Personalmente io sono (problemi tecnologici a parte) per la massima integrazione possibile...come per l'unità (o le unità) centrali a rete neurale con elementi non specializzati tipici dell'universo "Terminator" per intenderci ove sono possibili elaborazioni di ogni tipo e su qualsiasi dominio: grafico, di calcolo balistico, di elaborazione di dati provenienti da sensori, di calcolo numerico puro ecc. ecc.

preferisco la gnocca

Originariamente inviato da Marco71

Ovviamente la fame di dati da elaborare presuppone che la c.p.u o g.p.u che sia, non abbia uno dei limiti delle architetture di computer secondo Von Neumann e cioè la velocità, ampiezza di banda da e verso i banchi di memoria centrale...che sarebbe auspicabile poter un giorno integrae pure essi in una c.p.u...

intendi integrare l'intero frame buffer, oltre alle cache, i buffer e i registri (già presenti dentro una cpu)?

Originariamente inviato da Marco71

Un Intel i800 con memoria interna (a questo punto non "cache" come intesa oggi) di qualche PiB,

i spe del cell hanno memoria interna non cache; però hanno anche registri e buffer interni ed il ppe ha persino una memoria di tipo cached (chissà perchè ).

Originariamente inviato da Marco71

qualche centinaia di migliaia di unità di processo general purpose connesse secondo un ipercubo a dimensioni (fate voi quante) potrebbe divenire una ottima "piattaforma" per un "calcolatore universale" che probabilmente potrebbe superare il test di Turing.

e potrebbe occupare uno spazio pari alla basilica di san pietro, soprattutto se la tua idea è quella di intelligenza artificiale "forte"

[Marco71]

...parlo di "A.I strong"...e forse non occuperà un volume pari alla basilica di S. Pietro...
Forse grazie al D.A.R.P.A basterà il volume occupato da due cubi di Rubik affiancati (od anche meno).
Ho la firma irregolare ?
Grazie.

Marco71.

[Mercuri0]

Originariamente inviato da yossarian

c'è anche ID; e pure Epic

Sì ma Id ed Epic non fanno notizia, mentre Blizzard non è famosa per la "tecnologia grafica" dei suoi giochi.

Il mio piccolo OT era per osservare che non c'è bisogno di fare giochi con grandi requisiti hardware, per essere grandi programmatori di motori grafici.

[yossarian]

Originariamente inviato da Marco71

...parlo di "A.I strong"...e forse non occuperà un volume pari alla basilica di S. Pietro...
Forse grazie al D.A.R.P.A basterà il volume occupato da due cubi di Rubik affiancati (od anche meno).

quella della basilica era una battuta, ma hai idea di quanti transistor servano per simulare una rete neurale con connessioni point to point tra circa 100 miliardi di neuroni, considerando l'ipotesi di riuscire ad utilizzare un transistor a sinapsi?
E, in ogni caso, i detrattori dell'ipotesi dell'I.A. sono dell'avviso che neppure realizzando una rete neurale che simuli perfettamente la strutture del cervello se ne riuscirà a riprodurre il corretto funzionamento (quest'ultima cosa, ovviemente da dimostrare). In ogni caso, finora la letteratura scientifica riporta di simulazioni di sinapsi ma non di simulazine di rete neurale completa.

Originariamente inviato da Marco71

Ho la firma irregolare ?
Grazie.

Marco71.

non tu, ma lee (ho quotato lui)

Sono curioso di approfondire le tue idee sulla ram embedded nelle cpu.

[gabi.2437]

Originariamente inviato da Marco71

...dal numero di transistor disponibili/deputati in questo caso al calcolo in virgola mobile/calcolo vettoriale precipuo degli ambienti di supercomputing.
Una c.p.u general purpose come quelle che equipaggiano gli odierni (diciamo in ambito x86 a partire dall'8080 in poi...anche se la prima c.p.u con I.S.A x86 fu l'8086 e la sua variante con bus dati ad 8 bit 8088) nostri personal computer dovendo essere un "uomo per tutte le stagioni" possiede al suo interno un numero ridotto di unità f.p.u, s.i.m.d (queste molto spesso funzionano utilizzando un microcodice con relativo sequencer invece di una implementazione hard-wired che farebbe aumentare il numero di transistor (M.O.S) a dismisura).
Questo ante-Nehalem...se con Nehalem Intel riproporrà un paradigma già sperimentato con l'80860 (e suoi derivati) di nuovo la c.p.u tornerà ad essere e caratterizzarsi per ciò che esprime il suo acronimo: central processing unit...
Personalmente io sono (problemi tecnologici a parte) per la massima integrazione possibile...come per l'unità (o le unità) centrali a rete neurale con elementi non specializzati tipici dell'universo "Terminator" per intenderci ove sono possibili elaborazioni di ogni tipo e su qualsiasi dominio: grafico, di calcolo balistico, di elaborazione di dati provenienti da sensori, di calcolo numerico puro ecc. ecc.
Ovviamente la fame di dati da elaborare presuppone che la c.p.u o g.p.u che sia, non abbia uno dei limiti delle architetture di computer secondo Von Neumann e cioè la velocità, ampiezza di banda da e verso i banchi di memoria centrale...che sarebbe auspicabile poter un giorno integrae pure essi in una c.p.u...
Un Intel i800 con memoria interna (a questo punto non "cache" come intesa oggi) di qualche PiB, qualche centinaia di migliaia di unità di processo general purpose connesse secondo un ipercubo a dimensioni (fate voi quante) potrebbe divenire una ottima "piattaforma" per un "calcolatore universale" che probabilmente potrebbe superare il test di Turing.
Il sistema C.U.D.A di NVidia Corp. mi "intrippa" non poco...slurp...
Peccato che A.M.D ancora latiti in questo settore...per B.O.I .N.C sarebbe una vera rivoluzione...in Seti@home si potrebbe finalmente fare uso della trasformata di Karhunen-Loève in luogo dell'ubiquo utilizzo che si fa invece della trasformata discreta con algoritmi di F.F.T.
Grazie.

Marco71.

Per BOINC c'è GPUGrid, che però per ora è limitato alle nvidia

[!fazz]

Originariamente inviato da yossarian

mi sfugge questo passaggio: per quale motivo le cpu ante nehalem non sarebbe delle c.p.u.? Quali sono le caratteristiche di un processore che permettano di definirlo cpu? E comunque gli approcci di intel al calcolo parallelo sembrano andare in direzione opposta rispetto a quanto tu ha indicato: così è per l'architettura EPIC di Itanium e così per il terascale computing (larrabee)



preferisco la gnocca



intendi integrare l'intero frame buffer, oltre alle cache, i buffer e i registri (già presenti dentro una cpu)?



i spe del cell hanno memoria interna non cache; però hanno anche registri e buffer interni ed il ppe ha persino una memoria di tipo cached (chissà perchè ).



e potrebbe occupare uno spazio pari alla basilica di san pietro, soprattutto se la tua idea è quella di intelligenza artificiale "forte"

yossirian, penso che intendeva che in nahalem si è assistito ad una diminuzione delle istruzioni gestire da microcodice ed un'aumento di quelle gestite da "circuiteria" dedicata rispetto ai core