NVIDIA illustra il progetto Echelon

[!fazz]

Someone, il fatto di non poter usare un cluster per valutare le performance di una singola componente è palese

daltronde non si possono neanche confrontare direttamente le due architetture per "via numerica" (n° shader ecc ecc) in quanto le architteture sono troppo diverse.

rimane solo la possibilità di testare mediante bench una singola gpu ma anche qui bisogna stare attenti in quanto le architetture fondamentalmente diverse permettono facilmente di taroccare il risultato in base a come viene svolto il benchmark


e comunque a cappello di tutto visto il tuo storico messaggi diciamo non super partes chiederei gentilmente di dimostrare ogni tua tesi in maniera oggettiva e documentata

[yossarian]

Originariamente inviato da Someone

Scusa riassumiamo un attimo.

ok, riassumiamo

Originariamente inviato da Someone

Scusa riassumiamo un attimo.

I bench delle Quadro non vanno bene perchè mostrano che una Quadro Basata su Fermi va il doppio di una basata su Cypress, e non si sa il perchè dato che in ambito videoludico i due chip sono quasi alla pari.

si parla di GPGPU e tesla e tu tiri fuori bench delle quadro che con alcune applicazioni vanno meglio e con altre peggio della controparte ATi e concludi che vanno il doppio e consumano di meno. Vengono postati bench in cui si analizza la capacità matematica dei chip singoli e li bolli come dati teorici, cominciando a sproloquiare di HPC (e riproponendo i test delle quadro che non c'entrano una mazza con i supercomputer).

Originariamente inviato da Someone

In ambito con i super computer (che sono usati per fare calcoli matematici) i bench non vanno bene perchè i limiti sono della banda.

quali bench? Quelli che dicono che il tianhe-1A è molto più veloce del tianhe? A parte il fatto che il primo ha molti più core del secondo, il primo ha anche una banda doppia rispetto al secondo per mettere in comunicazione questi processori. Se per te questo non significa niente è un problema tuo e non mio.

Originariamente inviato da Someone

Siamo sempre ai soliti discorsi di teoria vs pratica.

la pratica non significa niente senza teoria.

Originariamente inviato da Someone

Io vedo dei numeri che dall'altra parte non ci sono.

dall'altra parte ci sono ma tu fai finta di ignorarli o li bolli come "teoria". Quelli sono test pratici e reali quanto e più di un vantage o di qualunque altro test perchè permettono di far luce sull'architettura di un chip cosa che con il punteggio finale del 3dmark o con gli fps di crysis non vedi.

Originariamente inviato da Someone

Sarà perché l'architettura AMD non è all'altezza di quella nvidia nell'atto pratico (non teorico dove sfoggia numeri più grandi) o perchè AMD non è in grado di fare driver all'altezza di sfruttare i propri transistor tanto sudatamente progettati. O una combinazione delle due.
Fatto sta che nella pratica, cioè per quello che riguarda l'uso di programmi usati in ambito professionale/HPC non c'è alcun riferimento oggettivo che tutta questa potenza sia espressa. Anzi, mi sembra che proprio non ci sia.

hai parlato di architettura inferiore; adesso tiri in ballo i driver; mancano solo le ottimizzazioni del SW da parte di terzi e il quadro è completo.
Ti consiglio un'approfondita lettura dell'articolo di B3D, comprese le conclusioni. Forse ti servirà per chiarirti di più le idee.

Originariamente inviato da Someone

Dimmi in poche parole perché le Quadro fanno quei numeri e perché nei bench OpenCL nvidia surclassa in quasi tutti i bench le schede ATI anche se dai grafici che hai postato tu le schede ATI dovrebbero essere sensibilmente più veloci in linea teorica. Dove sta il problema? Sempre e solo nei driver?

dimmelo tu che hai parlato di architettura inferiore in certi ambiti che compete alla pari in altri. Anzi, a dirla tutta, avevi anche affermato, senza lo straccio di una prova, che le quadro (cosa c'entrino con le tesla lo sai solo tu) consumano anche meno della controparte. Questo a prescindere dal fatto che dai test che ho postato io non risulta che i chip ATi sono sensibilmente più veloci ma che sono più veloci in certi ambiti e meno in altri e risulta anche che da quei test si può capire in che modo scrivere codice che avvantaggi l'una o l'altra architettura.

[Pleg]

Comunque, per tornare alla parte tecnica dell'articolo e' interessante valutare quei numeri: prendendo per buono il valore citato di 200 pJ/istruzione, significa 5 miliardi di istruzioni per Joule, cioe' 5 teraFLOPS per Watt, mentre dai dati citati da Yossarian dovremmo essere intorno a mezzo teraFLOPS per... boh, diciamo 300 watt (regime, non picco) per un GF100

Quindi 3mila volte meno di quanto citato. Il che significa che purtroppo l'energia spesa per effettivamente fare le operazioni numeriche (cioe' quello che ci interessa) e' una frazione trascurabile dell'energia consumata dal chip. Questo non sorprende, il grosso dell'energia e' spesa nel trasferire i dati da e verso la memoria (specie off-chip). Se potessimo davvero spendere energia solo per fare la comptazione, un solo GF100 sarebbe potente circa quanto tutto il nuovo Tianhe

In quest'ottica va letta la seconda parte dell'articolo, quando Dally parla di cache multilivello programmabili e tenere i dati il piu' vicino possibile alle unita' funzionali.

[yossarian]

Originariamente inviato da Pleg

Comunque, per tornare alla parte tecnica dell'articolo e' interessante valutare quei numeri: prendendo per buono il valore citato di 200 pJ/istruzione, significa 5 miliardi di istruzioni per Joule, cioe' 5 teraFLOPS per Watt, mentre dai dati citati da Yossarian dovremmo essere intorno a mezzo teraFLOPS per... boh, diciamo 300 watt (regime, non picco) per un GF100

Quindi 3mila volte meno di quanto citato. Il che significa che purtroppo l'energia spesa per effettivamente fare le operazioni numeriche (cioe' quello che ci interessa) e' una frazione trascurabile dell'energia consumata dal chip. Questo non sorprende, il grosso dell'energia e' spesa nel trasferire i dati da e verso la memoria (specie off-chip). Se potessimo davvero spendere energia solo per fare la comptazione, un solo GF100 sarebbe potente circa quanto tutto il nuovo Tianhe

In quest'ottica va letta la seconda parte dell'articolo, quando Dally parla di cache multilivello programmabili e tenere i dati il piu' vicino possibile alle unita' funzionali.

quello che dici è terribilmente vero. Ormai, all'interno di un chip, la quasi totalità dello spazio è occupato soprattutto da registri, cache e circuiti di controllo e gestione dei thread e del flusso dei dati tra unità funzionali e da e verso la memoria. Il che significa che anche la stragrande maggioranza dei cicli di clock è speso per operazioni di controllo e di load/store. Ovviamente anche il bilancio energetico è influenzato da questi fattori. Le operazioni fatte con la memoria esterna sono anche quelle più "dispendiose" e da qui la necessità di riuscire ad avere tutto a "portata delle unità funzionali" che ormai rivestono un ruolo marginale nel bilancio energetico di un chip..

[Pleg]

Ho scritto una cazzata
5 miliardi di istruzioni per Joule sono 5 gigaFLOPS, non teraFLOPS, quindi 1.5 teraFLOPS per 300 Watt, quindi un rapporto di 3, non 3mila

Cmq il problema di fondo e' quello: l'energia per i bus (specie off-chip), il clock, il controllo, la decodifica delle sitruzioni eccetera e' ben maggiore dell'energia usata per fare i calcoli in se'. Questo e' un bel problema... e di non facile soluzione

[yossarian]

Originariamente inviato da Pleg

Ho scritto una cazzata
5 miliardi di istruzioni per Joule sono 5 gigaFLOPS, non teraFLOPS, quindi 1.5 teraFLOPS per 300 Watt, quindi un rapporto di 3, non 3mila

Cmq il problema di fondo e' quello: l'energia per i bus (specie off-chip), il clock, il controllo, la decodifica delle sitruzioni eccetera e' ben maggiore dell'energia usata per fare i calcoli in se'. Questo e' un bel problema... e di non facile soluzione

succede e io non ho controllato perchè mi sono fidato
in questi anni sono stati fatti diversi passi avanti: trasferimento di dati in batch dalla ram di sistema alla ram video e da questa all'interno dei registri, per ridurre l'impatto degli accessi a memorie esterne, soprattutto a quella di sistema che passa attraverso il collo di bottiglia del bus pci express); aumento esponenziale del numero di registri per avere più thread on fly (questo porta due vantaggi: riduzione degli accessi all'esterno e, soprattutto, miglior mascheramento delle latenze); introduzione di cache all'interno delle gpu (inizialmente solo per le texture che erano le più problematiche da gestire per le latenze, poi anche per i dati di altra natura); aumento dei bus verso l'esterno e, soprattutto, verso l'interno dei chip, con architetture di tipo asimmetrico sempre più complesse. I memory controller sono diventati, in molti ambiti, i veri arbitri delle prestazioni di un chip.
I chip hanno aumentato notevolmente la loro efficienza passando agli shader unificati ma questo aumento è dovuto ad una diversa gestione del lavoro delle alu e non ad un aumento dell'efficienza della singola alu. Il rovescio della medaglia è stato l'aumento della complessità dei circuiti che si occupano di gestire e controllare il lavoro delle unità funzionali.
Quella di tentare di ridurre al minimo la necessità di accedere alla memoria esterna è una delle scommesse del futuro ma tu sai bene che anche la gestione di una gran mole di traffico all'interno del chip presenterebbe non poche criticità.
Adesso si sta perseguendo la strada di strutturare le architetture interne su più livelli; così hai 2, 3, 4 macro blocchi di alu, ciascuno diviso, a sua volta, in gruppi più piccoli e via dicendo, fino ad arrivare alla singola alu. Ma anche questo tipo di architettura comporta problemi. Una logica a più livelli significa che tutti i circuiti che gestiscono i vari livelli devono dialogare tra di loro (il che si traduce in più cicli impiegati in operazioni che non coinvolgono le unità funzionali).

[Pleg]

Gia', ma alla fine ci tocchera' probabilmente rivedere tutta l'interazione hardware/software per raggiungere quei livelli di prestazioni (exascale e oltre). Ad esempio, ci sono tentativi di cambiare il paradigma di programmazione (sempre per applicazioni numeriche, ovviamente) in cui si programma direttamente la gerarchia di memoria: non e' tanto piu' una questione di dispacciare istruzioni alle unita' funzionali, ma una questione di portare i dati il piu' vicino possibile alle unita' funzionali e tenerli li', per ridurre i trasferimenti di memoria. Un esempio:
http://sequoia.stanford.edu/

e se guardi la documentazione, il backend e' in... CUDA! Surprise
Cos'e' che si diceva nell'articolo?

[Someone]

e comunque a cappello di tutto visto il tuo storico messaggi diciamo non super partes chiederei gentilmente di dimostrare ogni tua tesi in maniera oggettiva e documentata

Ho postato dei link.
In OpenCL l'architettura nvidia mostra una efficienza migliore.

Poi mi fa strano che tu chieda a me di dare dimostrazione di tesi quando dall'altra parte non ci sono link e si continua a distorcere il discorso su consumi e teorie varie per non rispondere alla semplice domanda posta: i problemi OpenCL di AMD sono di driver o di architetttura HW?
E ripeto, come è possibile che due architetture apparentemente simili nel campo consumer poi mostrino tante differenze quando si tratta di usare programmi professionali? Come si vede questi programmi usano qualcosa di diverso rispetto ai videogiochi, dato che è ben visibile la differenza tra una Quadro e una GeForce con lo stesso chip. I driver sbloccano queste funzionalità sulle schede Quadro/FireStream, ma perchè da una parte queste funzioni vanno il doppio? Perché il Cypress spesso non raggiunge nemmeno le prestazioni del G200?

Perchè? Pronto, dall'altra parte, invece di confondere il discorso con argomenti senza senso, rispondere a queste domande. Magari anche solo alla prima relativamente all'OpenCL.
Grazie.

[yossarian]

Originariamente inviato da Pleg

Gia', ma alla fine ci tocchera' probabilmente rivedere tutta l'interazione hardware/software per raggiungere quei livelli di prestazioni (exascale e oltre). Ad esempio, ci sono tentativi di cambiare il paradigma di programmazione (sempre per applicazioni numeriche, ovviamente) in cui si programma direttamente la gerarchia di memoria: non e' tanto piu' una questione di dispacciare istruzioni alle unita' funzionali, ma una questione di portare i dati il piu' vicino possibile alle unita' funzionali e tenerli li', per ridurre i trasferimenti di memoria. Un esempio:
http://sequoia.stanford.edu/

e se guardi la documentazione, il backend e' in... CUDA! Surprise
Cos'e' che si diceva nell'articolo?

faccio l'avvocato del diavolo (mi riferisco al modello per gpu, ovviamente ). Nella documentazione c'è scritto che con la versione 3.0 di CUDA si fa uso di 4 livelli di memoria (due di tipo dram, ovvero ram di sistema e vram) e 2 di tipo sram (le cache L2 e L1). I primi due non sono direttamente accessibili alle unità interne della gpu e questa è già una prima limitazione al modello sequoia (L1 ed L2 sono, tra l'altro, di dimensioni piuttosto ridotte). In ogni caso, anche qualora fossero direttamente accessibili, le latenze sarebbero piuttosto elevate. Nella gpu ATi, da R5x0 in poi, è stata aggiunta la funzionalità memexport e dalla serie 4xx0 in poi anche la memimport che consentono alla gpu di accedere direttamente ad una porzione della ram di sistema. Tra i suggerimenti dati per ottimizzare i chip ATi c'è quello di far ricorso a queste funzionalità solo in casi particolari.
Anche il fatto che non ci possa agire direttamente sui registri è un'altra limitazione. Le unità funzionali delle gpu lavorano quasi esclusivamente con i registri.
Facendo un passo indietro ed ammettendo che siano accessibili direttamente anche L1 ed L2, a quali unità interne le si potrebbe abbinare? L2, magari, alle RBE o utilizzata in un sistema dual gpu sulla stessa vga ma per L1 l'unico uso che mi viene in mente è quello nell'ambito di un sistema multichip, magari anche di tipo asimmetrico, con cpu e gpu.
In sintesi, al momento, non mi sembra l'ideale per gestire il lavoro di processori che fanno del parallelismo e del multithreading i loro punti di forza.
Altra cosa, non mi pare (ma forse mi è sfuggito) di aver letto nulla riguardo alla gestione delle texture cache. Questo significa che Sequoia è progettato solo per il gpgpu? In caso contrario, ritengo che il modello di programmazione per gpu debba esporre anche le texture cache.
Infine, ho letto che, la comunicazione tra livelli è limitata alla copia dei dati dalla cache di un livello a quella di un altro livello col meccanismo dei DMA. In tal caso, però, rischi di scontrarti con gli stessi limiti dei sistemi attuali. Un DMA è gestito dal memory controler in maniera trasparente al programmatore e quindi bus e MC potrebbero diventare, di nuovo, il collo di bottiglia.

Queste sono considerazioni fatte dopo una lettura al volo del documento di presentazione di Sequoia (di cui avevo solo sentito parlare) e, ovviamente, qualcosa può essermi sfuggita.
In quanto all'utilizzo di CUDA per il backend, la cosa non deve sorprendere, visto che, al momento, per le gpu, l'unico modello proposto si basa su CUDA ed è stato progettato basandosi su gt200 prima e gf100 poi.

[yossarian]

Originariamente inviato da Someone

Ho postato dei link.
In OpenCL l'architettura nvidia mostra una efficienza migliore.

Poi mi fa strano che tu chieda a me di dare dimostrazione di tesi quando dall'altra parte non ci sono link e si continua a distorcere il discorso su consumi e teorie varie per non rispondere alla semplice domanda posta: i problemi OpenCL di AMD sono di driver o di architetttura HW?
E ripeto, come è possibile che due architetture apparentemente simili nel campo consumer poi mostrino tante differenze quando si tratta di usare programmi professionali? Come si vede questi programmi usano qualcosa di diverso rispetto ai videogiochi, dato che è ben visibile la differenza tra una Quadro e una GeForce con lo stesso chip. I driver sbloccano queste funzionalità sulle schede Quadro/FireStream, ma perchè da una parte queste funzioni vanno il doppio? Perché il Cypress spesso non raggiunge nemmeno le prestazioni del G200?

Perchè? Pronto, dall'altra parte, invece di confondere il discorso con argomenti senza senso, rispondere a queste domande. Magari anche solo alla prima relativamente all'OpenCL.
Grazie.

non viene sbloccato un bel niente perchè non ci sono funzionalità "nascoste" da sbloccare; si tratta solo di ottimizzazioni e se tu non continuassi ad ignorare i link che ho postato, magari arriveresti anche a capirne qualcosa di più. Forse (e il forse è d'obbligo perchè le quadro/firegl non c'entrano una mazza con il gpgpu, cosa che, evidentemente, non ti entra in testa). In quanto ai consumi, forse dimentichi che sei stato tu a tirarli in ballo a sproposito
Tra l'altro, sei talmente preso dal tentativo ridicolo di dimostrare l'esistenza di "armi segrete" che non ti sei neppure reso conto di quanto, in questi test, la 480 GTX faccia, insolitamente, schifo anche rispetto alla 5870 da cui le prende sonoramente ovunque. Considerato che si parla sempre e solo di "muovere poligoni" e che il chip è lo stesso IDENTICO delle quadro, trai tu le tue conclusioni. Per la cronaca, in nessuno di quei bench si fa uso di fp64 e queste
Cinebench OpenGL testing reveals similar performance between the Quadro 6000 and 5000 videocards. Looking at the rest of the scores, its apparent that ATI has optimized their drivers for this particular benchmark, while NVIDIA has yet to do so. As new drivers are released, we expect to see Cinebench scores of the Quardo cards increase.
che tu hai preso per verità assoluta, sono solo pippe mentali del recensore

[Pleg]

Originariamente inviato da yossarian

faccio l'avvocato del diavolo (mi riferisco al modello per gpu, ovviamente ). Nella documentazione c'è scritto che con la versione 3.0 di CUDA si fa uso di 4 livelli di memoria (due di tipo dram, ovvero ram di sistema e vram) e 2 di tipo sram (le cache L2 e L1). I primi due non sono direttamente accessibili alle unità interne della gpu e questa è già una prima limitazione al modello sequoia (L1 ed L2 sono, tra l'altro, di dimensioni piuttosto ridotte). In ogni caso, anche qualora fossero direttamente accessibili, le latenze sarebbero piuttosto elevate. Nella gpu ATi, da R5x0 in poi, è stata aggiunta la funzionalità memexport e dalla serie 4xx0 in poi anche la memimport che consentono alla gpu di accedere direttamente ad una porzione della ram di sistema. Tra i suggerimenti dati per ottimizzare i chip ATi c'è quello di far ricorso a queste funzionalità solo in casi particolari.

Beh il modello e' uan gerarchia ad albero di memorie ed eventuali unita' funzionali che operano su di esse (una per memoria), quindi semplicemente RAM e VRAM non hanno unita' funzionali... per ora e' facile pensare ad un modello "Fusion" in cui la CPU e' l'unita' funzionale della RAM e la GPU quella dei livelli sotto la VRAM (dico "sotto" perche' come fai notare operare direttamente sulla VRAM non e' uan buona idea, la latenza e' troppo alta).

Originariamente inviato da yossarian

Anche il fatto che non ci possa agire direttamente sui registri è un'altra limitazione. Le unità funzionali delle gpu lavorano quasi esclusivamente con i registri.

Questa puo' essere vista come: 1. uan limitazione temporanea, limitata da CUDA, o 2. una cosa desiderabile: uan volta che hai spostato un certo task sul livello piu' basso (i registri) e' meglio che sia l'hardware a gestirli direttamente, senza micro-management da parte del software, perche' a quel punto l'hardware puo' andare alla massima velocita'.

Originariamente inviato da yossarian

Altra cosa, non mi pare (ma forse mi è sfuggito) di aver letto nulla riguardo alla gestione delle texture cache. Questo significa che Sequoia è progettato solo per il gpgpu? In caso contrario, ritengo che il modello di programmazione per gpu debba esporre anche le texture cache.

Nei primi capitoli, dove parla del modello, dice che e' un modello astratto che viene poi compilato per macchine specifiche, SMP / CMP / GPGPU ecc.

Originariamente inviato da yossarian

Infine, ho letto che, la comunicazione tra livelli è limitata alla copia dei dati dalla cache di un livello a quella di un altro livello col meccanismo dei DMA. In tal caso, però, rischi di scontrarti con gli stessi limiti dei sistemi attuali. Un DMA è gestito dal memory controler in maniera trasparente al programmatore e quindi bus e MC potrebbero diventare, di nuovo, il collo di bottiglia.

Credo per con DMA intenda piu' che altro "bulk transfer": il programma specifica cosa va e dove, e il DMA fa si' che i dati vengano trasferiti in un colpo solo tra i diversi livelli (supporta anche gather/scatter, lo dice da qualche parte). Cmq si' alla fine il bus e' il collo di bottiglia... ma quello e' desiderabile: vuoi che la computazione vada alla massima velocita' resa possibile dalla memoria, cioe' che la memoria sia l'unico collo di bottiglia.

[Someone]

Tra l'altro, sei talmente preso dal tentativo ridicolo di dimostrare l'esistenza di "armi segrete" che non ti sei neppure reso conto di quanto, in questi test, la 480 GTX faccia, insolitamente, schifo anche rispetto alla 5870 da cui le prende sonoramente ovunque.

Testimonianza che non leggi quello che scrivo ma vai per conto tuo. Prova a cercare:

dato che è ben visibile la differenza tra una Quadro e una GeForce con lo stesso chip

Ancora non hai risposto alle domande comunque. Sei su dei binari morti e non sei in grado di uscirne.
Se vuoi te la ripeto un'altra volta, con parole diverse, non si sa mai che tu non l'abbia capita: perchè in OpenCL, sistema dove AMD sta impiegando tutte le proprie forze mentre nvidia è ben più interessata a lanciare CUDA, le schede nvidia vanno di più in praticamente tutti i bench che vengono mostrati? Compresi quelli preparati da AMD insieme a SiSoft?

[yossarian]

Originariamente inviato da Pleg

Beh il modello e' uan gerarchia ad albero di memorie ed eventuali unita' funzionali che operano su di esse (una per memoria), quindi semplicemente RAM e VRAM non hanno unita' funzionali... per ora e' facile pensare ad un modello "Fusion" in cui la CPU e' l'unita' funzionale della RAM e la GPU quella dei livelli sotto la VRAM (dico "sotto" perche' come fai notare operare direttamente sulla VRAM non e' uan buona idea, la latenza e' troppo alta).

infatti, nel precedente intervento ho scritto che l'unico impiego che mi viene in mente per L1 è quello di un sistema multichip asimmetrico (cpu con una o più gpu a fare da coprocessori). E, anche in quel caso, l'accesso diretto da parte della cpu lo limiterei ad operazioni quale trasferimento di dati verso la gpu o le cache interne alla cpu e, solo in casi eccezionali all'accesso diretto ad L1. In tal caso, L1 sarebbe una ram condivisa tra cpu e gpu e non riesco a vedere l'utilità di una VRAM.

Originariamente inviato da Pleg

Questa puo' essere vista come: 1. uan limitazione temporanea, limitata da CUDA, o 2. una cosa desiderabile: uan volta che hai spostato un certo task sul livello piu' basso (i registri) e' meglio che sia l'hardware a gestirli direttamente, senza micro-management da parte del software, perche' a quel punto l'hardware puo' andare alla massima velocita'.

vero; lo spostamento iniziale (il riempimento dei registri costanti) avviene prima del lancio dell'applicazione e, in seguito, i successivi trasferimenti sono gestiti sia dal thread processor, man mano che si riempiono di nuovo i suoi instruction buffer, che dai MC in modalità OoO e in real time e, quindi, sicuramente in maniera più efficiente di quanto non si potrebbe fare at compile time. A quel punto, solo lo scheduler di ogni singolo stream processor (chiamo SP un intero cluster di alu, per ntenderci ) lavorerebbe in order ma sempre in real time. Forse, a questo punto, sarebbe da valutare se non sia conveniente far lavorare in modalità OoO anche gli scheduler dei singoli SP (ma questo non ha a che fare con Sequoia ). In ogni caso, a questo punto, non vedo grandi rivoluzioni rispetto al modello attuale, almeno con questo tipo di architetture per le gpu.......

Originariamente inviato da Pleg

Nei primi capitoli, dove parla del modello, dice che e' un modello astratto che viene poi compilato per macchine specifiche, SMP / CMP / GPGPU ecc.

si, però mi riferivo alla gerarchia di cache del modello gpgpu, dove fa riferimento a 4 livelli, citando esplicitamente ram di sistema, vram, L1 ed L2, in riferimento all'architettura di GF100. Ora, L2 è la cache condivisa tra tutti gli SP ed L1 è una porzione della memoria condivisa tra le alu di ogni singolo SP. Ma ogni SP ha anche accesso ad una texture cache. Quindi l'idea che mi sono fatto è che il modello di programmazione sia limitato al gpgpu e non alla programmazione di una gpu per altri usi (gaming o grafica pro). In tal caso non c'è alcun motivo per fare uso di texture cache, visto che non si usano le TMU. Anche se la cosa che non mi torna è che, mentre nel modello sequoia si parla di 16 KB di L1 per SP, secondo il modello di allocazione della memoria previsto per GF100, in caso di operazioni di rendering la memoria a disposizione del singolo SP viene divisa in modo da avere 16 KB di L1 e 48 KB di memoria condivisa tra le alu dello SP mentre per il GPGPU avviene il contrario (48 KB di L1 e 16 KB di shared memory).

Originariamente inviato da Pleg

Credo per con DMA intenda piu' che altro "bulk transfer": il programma specifica cosa va e dove, e il DMA fa si' che i dati vengano trasferiti in un colpo solo tra i diversi livelli (supporta anche gather/scatter, lo dice da qualche parte). Cmq si' alla fine il bus e' il collo di bottiglia... ma quello e' desiderabile: vuoi che la computazione vada alla massima velocita' resa possibile dalla memoria, cioe' che la memoria sia l'unico collo di bottiglia.

la gerarchia di memorie di gf100 (ad esempio) al momento, prevede una L1 a disposizione del singolo SP e una L2 condivisa tra i 16 SP che sostituisce la texture cache L2, la cache a disposizione delle ROP's e la cache di tipo FIFO delle precedenti architetture. Se si deve operare un trasferimento da L1 a L2 o viceversa, o tra la L1 di uno SP e quella di un altro SP, si deve passare attraverso L2 (che immagino sarà servita da un ring bus) il cui accesso non può che essere gestito da un local arbiter o da uno dei MC presenti nelle ROP's (sul modello di quanto avviene, ad esempio, con l'EIB nel cell). Altrimenti non vedo come si possa risolvere il problema della concorrenza nell'accesso alle risorse condivise da parte dei diversi SP, soprattutto alla luce del fatto che la gestione dei thread avviene, a livello di registri, dinamicamente e in maniera trasparente al programmatore. Uno dei problemi che determinano le latenze nell'accesso a risorse condivise (compresa la memoria) è proprio nello smaltimento delle code relative alle richieste di accesso. Quindi gli arbiter (e il loro principio di funzionamento) e i criteri di arbitrato impostati diventano un elemento di elevata criticità e la loro ottimizzazione è decisiva ai fini delle prestazioni. Poi, ovviamente, ci sono altri fattori, come l'ampiezza del bus e la velocità di ricerca (in lettura) e trasferimento dei dati. Di fatto, la velocità delle memorie, intesa in senso lato, è influenzata anche da tutti questi elementi. L'unico trasferimento gestito, teoricamente, in un solo ciclo, è quello dai registri alla alu e viceversa, ma solo perchè ogni alu ha i suoi registri dedicati e non si pone il problema di gestire richieste concorrenti.

[yossarian]

Originariamente inviato da Someone

Se guardi al mondo dei videogiochi allora le soluzioni nvidia non sono il max per quanto riguarda performance/watt. D'altronde i loro chip si portano dietro una serie di funzionalità per il GPGPU che per i videogiochi non sono usati ma che comunque consumano (e rendono il loro chip delle mattonelle).
Se guardi invece in campo GPGPU non c'è alcuna soluzione che faccia meglio.
Basta guardare le prestazioni della concorrenza nella applicazioni professionali. Le loro schede consumano di più e vanno meno anche se nell'eseguire i soli compiti grafici sono più efficienti.

Originariamente inviato da Someone

Per quanto riguarda i consumi avevo visto un benchmark che mostrava consumi inferiori per schede nvidia con potenza simile a quelle ATI. Probabilmente non è il caso della serie QUadro 6000 che consuma una cinquantina di watt in più.
Però non so come tu faccia a dire che le capacità sono le stesse quando i benchmark su prodotti reali, non benchmark fatti ad hoc per mostrare una particolare ottimizzazione all'esecuzione di una sola istruzione (o tipo di istruzioni) è questa:
http://hothardware.com/Reviews/NVIDI...Review/?page=8

Ed è solo un esempio, tra tutti quelli che sono riportati in quella recensione, che evidenzia in maniera chiara la differenza tra le due architetture e mette in mostra anche la differenza con l'architettura vecchia di nvidia (che spesso sorpassa comunque quella nuova di AMD).
Ora, o i numeri teorici che hai riportato sono appunto solo teorici e molto ma molto distanti poi dalla efficienza vera che si ottiene oppure in AMD hanno una architettura stratosferica (secondo i numeri che hai dato) ma che non sanno sfruttare per via di driver penosi.
Ripeto, non si capisce perchè in campo videoludico il Cypress sarebbe solo leggermente inferiore ad un Fermi, quando invece nel campo professionale, dove entrano in gioco altre caratteristiche, gli stessi piombino dietro addirittura al così tanto bistrattato G200.

da uno dei tuoi link



il resto dei test hanno andamento analogo (in alcuni anche peggiore per la geforce)

come spieghi le prestazioni della 480 GTX anche in rapporto alla 5870 (due chip di tipo consumer)? Quanto devo aspettare per avere la risposta?
A questo intervento, per altro pertinente

Originariamente inviato da cenit

non voglio scatenare flame, ma parli per sentito dire o per conoscenza diretta?
Secondo me parli per sentito dire.

CUDA è un ottimo toolkit che manca alla concorrenza, ma se uno si fa il programma in casa senza bisogno di toolkit (facendo però più fatica) i risultati che si hanno con le schede della concorrenza (leggasi ATi) molte volte sono equiparabili, spesso migliori, solo poche volte sono meno efficienti.

Ah, consumano anche molto meno.

hai risposto in questo modo, linkando un test delle quadro quando si stava parlando di CUDA e GPGPU

Originariamente inviato da Someone

Nessun flame. Solo questioni di numeri. Vedi i benchmark eseguiti sui programmi professionali che non fanno solo texturing ma implicano l'uso delle capacitò di calcolo per fare qualcosa di più.
Qui trovi qualche test: http://tech.icrontic.com/articles/re...6000-reviewed/
In conclusione dell'articolo:
The Quadro 6000 managed to score higher than the FirePro V8800 in all of the tests, and in roughly half of the tests on average, it managed to double the performance of the V8800. That is quite the impressive increase. Professionals who work with incredibly intensive projects should take note.

In alcuni test la concorrenza è indietro davvero di tantissimo.

ripeto le domande: cosa fanno le gpu utilizzate in grafica pro di diverso rispetto a quelle utilizzate per i giochi? E cosa c'entrano le quadro con il gpgpu? Quanto devo aspettare per avere le risposte?

Originariamente inviato da Someone

Non è un caso che nvidia abbia il 90% del mercato professionale con le Quadro in un mercato più che maturo e che sa valutare quello che viene offerto.
Le capacità di calcolo delle sue architetture sono oggettivamente superiori. Se poi tu ti fai l'applicazione a casa per calcolarti una specifica cosa è probabile che trovi il modo di sfruttare meglio l'architettura AMD per quella particolare cosa. Ma per il calcolo scientifico, quello generale che implica l'uso di diverse strutture e metodi di calcolo, per ora la concorrenza non c'è.

ripeto la domanda: cosa c'entrano le quadro con il calcolo scientifico? Quanto devo aspettare per avere la risposta?

Originariamente inviato da Someone

I bench del secondo link sono interessanti, ma sono specifici per singola operazione. Nei calcoli veri non si esegue la stessa istruzione un milione di volte e basta saturando in maniera artificiale tutti gli SP alla loro massima efficienza. Entrano in gioco molte altre cose, come ad esempio la capacità di passare i risultati da un thread al successivo o di mixare istruzioni diverse.
Nei bench OpenCL, gli unici che permettono di avere un confronto diretto tra le due architetture, si vede che l'architettura Fermi funziona meglio in quasi tutti gli scenari.
Negli algoritmi dove non si fa solo moltiplicazioni di matrici in DP ad hoc per mostrare la massima efficienza dell'architettura, si vede dove le capacità dell'architettura nvidia vs quella AMD prevale.


Nel campo professionale si usano le capacità di calcolo per fare cose che non sono sole ed esclusivamente quello di muovere poligoni sullo schermo come nei videogiochi.
Potresti spiegare altrimenti come è possibile che il Cypress che nel campo videoludico praticamente sta un solo passo dietro al GF100, nel campo professionale sta 5 o 10 passi indietro. E le specifiche delle schede Quadro non sono quelle GeForce. Nelle Quadro si usa il chip della 470 con frequenze inferiori. I bench dei consumi indicano addirittura che queste schede consumano meno delle schede AMD e vanno di più. Una cosa che a guardare i bench dei videogiochi nessuno crederebbe.

e, infatti, qui di seguito ci mostri un esempio di applicazione OpenCL reale

Originariamente inviato da Someone

In OpenCL, che dovrebbe essere il cavallo di battaglia di AMD contro CUDa questi sembrano essere i risultati. Ovviamente stiamo parlando solo di alcuni bench, ma questo è quello che uno si trova davanti quando deve valutare un prodotto:

http://blog.cudachess.org/2010/03/nv...ncl-benchmark/

E ti anticipo con questa nota:
The OpenCL GPGPU benchmark suite forms part of SiSoftware Sandra 2010. AMD believes it is the only company that can provide a complete OpenCL development platform for GPGPUs - essentially a combination of graphics chip and microprocessor.

Ovvero il test di SiSoft Sandra è già ottimizzato per le GPU ATI poichè ci hanno lavorato assieme.

dal tuo stesso link This is the basic “MAD” or “FMAD” test that didn’t correspond to any real-world use of OpenCL

hai idea di cosa sia un loop di fma di tipo scalare a fp32 e chi avvantaggi? Ovviamente no, perchè per te la teoria non serve a niente, l'importante è la pratica che equivale a dire ile "barrette colorate" (anche se poi non capisci neppure a cosa facciano riferimento)


hai tirato in ballo gli HPC e presunti test che dimostrerebbero non so cosa. Se ti riferivi a quest'articolo che, tra l'altro, contiene dati sbagliati, devo ripeterti quanto già detto: non dimostra un bel niente e, per quanto possa darti fastidio, da questo link si legge: "Un notevole incremento delle prestazioni del sistema è da imputare al sistema di comunicazione custom sviluppato internamente dal NUDT. Questo sistema permette comunicazioni a 160 Gigabit, il doppio del precedente sistema InfiniBand".

Originariamente inviato da Someone

Se vuoi te la ripeto un'altra volta, con parole diverse, non si sa mai che tu non l'abbia capita: perchè in OpenCL, sistema dove AMD sta impiegando tutte le proprie forze mentre nvidia è ben più interessata a lanciare CUDA, le schede nvidia vanno di più in praticamente tutti i bench che vengono mostrati? Compresi quelli preparati da AMD insieme a SiSoft?

http://hothardware.com/Reviews/NVIDI...Review/?page=4

da uno dei tuoi link

p.s. nVidia fa parte del consorzio che sviluppa OpenCL, non è affatto indietro con il supporto e OpenCL non è in competizione con CUDA come non lo è con CAL (chi è il tuo informatore, Paperino?)

Ora, prova a cercare, le risposte alle tue domande ci sono tutte. Quelle che non vedo sono le risposte alle mie

Originariamente inviato da Someone

Ancora non hai risposto alle domande comunque. Sei su dei binari morti e non sei in grado di uscirne.

se io sono su dei binari morti tu sei deragliato da un pezzo

[Someone]

Tutti i test che io ho linkato mostrano che Fermi, sia nelle applicazioni professionali che in quelle di calcolo è nettamente superiore al Cypress. Tu hai postato solo link a test sintetici o particolarmente studiati per eseguire solo un determinato tipo di calcolo.
Ora, ripeto, magari la colpa è dell'ottimizzazione dei driver da parte di AMD, ma il risultato finale è che le schede nvidia vanno di più.

Che la GTX480 vs 5870 vada meno può avere milioni di motivi, come detto, anche il fatto che nvidia sulle versioni consumer delle proprie schede blocca una serie di funzionalità (calcolo DP per esempio)
mentre le sblocca nella versione professionale del chip ottenendo prestazioni più che doppie rispetto alla versione ottimizzata di Cypress. Continui a girare il manico in un paiolo vuoto. Non ha nessuna importanza per chi acquista una Quadro che la GTX480 va una schifezza. Gli interessa che la scheda che acquista faccia il suo mestiere al max, e visti i risultati direi che la concorrenza è una generazione indietro (forse con raddoppio ulteriore degli SP e contorno raggiungerà le performance).
Comunque ti rigiro la frittata: se nel campo professionale le operazioni fatte sono le stesse di quelle usate nei videogiochi, come mai due architetture così simili nei videogiochi poi hanno performance così diverse quando operano (sbloccate, ottimizzate quello che vuoi) nel campo professionale dove ovviamente si cerca di fare in modo che il proprio prodotto dia il massimo senza limitazioni di
sorta?

Il link di Sisandra che mostra la potenza del Cypress maggiore di quella di Fermi è frutto proprio di uno di quei bench semplici che sfruttano le potenzialità dell'architettura 4+1 di AMD (a la 3D Mark).
Ma se guardi i test specifici dove vengono fatti dei bench meno semplici, il Fermi mostra di avere capacità decisamente diverse. Cioè è come se le schede AMD nel 3D mark segnassero il doppio dei punti e poi nei giochi andassero la metà della concorrenza.

Ora, dato che sei tu l'esperto, non è che l'efficienza totale di una architettura non si misura solo nella capacità pura di fare calcoli nella condizione ottimale (come nei bench che TU hai postato) mentre è
un qualcosa che prende in esame anche altre cose che a quanto pare, visti i risulti sul campo, AMD non ha? Prendi per esempio F@H che è un'applicazione a cui sia ATI che nvidia hanno dato grande supporto
per avere un client ottimizzato. Come la spieghi la questione che le schede nvidia siano 3 o 4 volte più veloci? Eppure non è una applicazione sviluppata da nvidia in CUDA e basta. E non è in sviluppo da ieri.
D'altronde, io da puro ignorante al tuo cospetto, mi chiedo che cosa facciano quei 600 milioni di transistor in più in Fermi rispetto al Cypress (o i 500 milioni in più che aveva il G200 rispetto all'RV870)
che lo rendono una piastrella da bagno... forse nvidia aveva voglia di contribuire al riscaldamento globale o ha fatto un accordo con qualche produttore di silicio per consumarne di più senza alcun apparente motivo?

OpenCL non è un concorrente a CUDA? Secondo il marketing AMD lo è. E a guardare i risultati non si direbbe che abbia una grande arma in mano.
Perchè anche se domani le applicazioni (consumer) invece che in CUDA scritte specificatamente per HW nvidia fossero scritte in OpenCL per supportare anche AMD la differenza di prestazioni sarebbe comunque elevata e non favorirebbe certo AMD.

E mi (ti) chiedo. Dove sta il problema di AMD? Architettura (intesa non solo come tipo di scelta per gli SP vettoriali vs scalari) o driver? O per te non ci sono problemi e AMD offre le stesse capacità di nvidia nei settori dove le due architetture vengono spremute? A parte i bench sintetici con moltiplicazioni vettoriali, hai qualche altro link dove mostri che AMD è a questo livello? Io per ora vedo le "famose" barrette mostrare risultati migliori per nvidia invece che per AMD.

[yossarian]

Originariamente inviato da Someone

Tutti i test che io ho linkato mostrano che Fermi, sia nelle applicazioni professionali che in quelle di calcolo è nettamente superiore al Cypress. Tu hai postato solo link a test sintetici o particolarmente studiati per eseguire solo un determinato tipo di calcolo.
Ora, ripeto, magari la colpa è dell'ottimizzazione dei driver da parte di AMD, ma il risultato finale è che le schede nvidia vanno di più.

anche i tuoi sono test sintetici

Originariamente inviato da Someone

Che la GTX480 vs 5870 vada meno può avere milioni di motivi, come detto, anche il fatto che nvidia sulle versioni consumer delle proprie schede blocca una serie di funzionalità (calcolo DP per esempio)
mentre le sblocca nella versione professionale del chip ottenendo prestazioni più che doppie rispetto alla versione ottimizzata di Cypress.

la DP non c'entra una mazza con la grafica pro. Sto aspettando ancora la risposta alla domanda: che differenza c'è tra un chip per quadro ed uno per geforce?

Originariamente inviato da Someone

Continui a girare il manico in un paiolo vuoto. Non ha nessuna importanza per chi acquista una Quadro che la GTX480 va una schifezza. Gli interessa che la scheda che acquista faccia il suo mestiere al max, e visti i risultati direi che la concorrenza è una generazione indietro (forse con raddoppio ulteriore degli SP e contorno raggiungerà le performance).

direi, viste le prestazioni della 480, che hai dimostrato che la 5870 è la miglior vga per rapporto prezzo/prestazioni anche nel professionale. Era questo il tuo intento?

Originariamente inviato da Someone

Comunque ti rigiro la frittata: se nel campo professionale le operazioni fatte sono le stesse di quelle usate nei videogiochi, come mai due architetture così simili nei videogiochi poi hanno performance così diverse quando operano (sbloccate, ottimizzate quello che vuoi) nel campo professionale dove ovviamente si cerca di fare in modo che il proprio prodotto dia il massimo senza limitazioni di
sorta?

le risposte te le ho date; se tu non le cogli è colpa della tua ignoranza e non ci posso fare niente. Ora sto aspettando le tue risposte.

Originariamente inviato da Someone

Il link di Sisandra che mostra la potenza del Cypress maggiore di quella di Fermi è frutto proprio di uno di quei bench semplici che sfruttano le potenzialità dell'architettura 4+1 di AMD (a la 3D Mark).

hai affermato che fermi andava di più con sandra; il tuo stesso link ti ha smentito

Originariamente inviato da Someone

Ma se guardi i test specifici dove vengono fatti dei bench meno semplici, il Fermi mostra di avere capacità decisamente diverse. Cioè è come se le schede AMD nel 3D mark segnassero il doppio dei punti e poi nei giochi andassero la metà della concorrenza.

tu non sai niente delle specificità di quei test; hai fatto una figura barbina spacciando per "test pratico, diverso da quelli che fanno ripetere la stessa operazioni fino a saturare tutti gli SP" (parole tue) un test dove c'è scritto chiaramente che si tratta di un loop di fma fp32. Che attendibilità hai quando parli di test in calce ai quali non c'è scritto niente?

Originariamente inviato da Someone

Ora, dato che sei tu l'esperto, non è che l'efficienza totale di una architettura non si misura solo nella capacità pura di fare calcoli nella condizione ottimale (come nei bench che TU hai postato) mentre è
un qualcosa che prende in esame anche altre cose che a quanto pare, visti i risulti sul campo, AMD non ha? Prendi per esempio F@H che è un'applicazione a cui sia ATI che nvidia hanno dato grande supporto
per avere un client ottimizzato. Come la spieghi la questione che le schede nvidia siano 3 o 4 volte più veloci? Eppure non è una applicazione sviluppata da nvidia in CUDA e basta. E non è in sviluppo da ieri.

che tipo di operazioni richiede FH?

Originariamente inviato da Someone

D'altronde, io da puro ignorante al tuo cospetto, mi chiedo che cosa facciano quei 600 milioni di transistor in più in Fermi rispetto al Cypress (o i 500 milioni in più che aveva il G200 rispetto all'RV870)
che lo rendono una piastrella da bagno... forse nvidia aveva voglia di contribuire al riscaldamento globale o ha fatto un accordo con qualche produttore di silicio per consumarne di più senza alcun apparente motivo?

a causa della finta professione di umiltà da parte di chi, poco sopra, ha scritto: "sei su binari morti e non sai come uscirne" (purtroppo sono bastardo e vendicativo ), non perderò tempo a spiegarti quello che ho già detto decine di volte. Però, siccome non sono bastardo fino in fondo, ti dò una dritta: cerca qualcosa su vliw, epic e superscalare.

Originariamente inviato da Someone

OpenCL non è un concorrente a CUDA? Secondo il marketing AMD lo è.

di quale marketing parli? Di quello delle chiacchiere da bar del forum o di quello delle dichiarazioni di qualche PR? OpenCL sta a CUDA e CAL come un paio di jeans una felpa e un paio di scarpe stanno ad un coordinato di mutande, calzini e maglietta della salute. Tu ti metti i pantaloni senza mutande?

Originariamente inviato da Someone

E a guardare i risultati non si direbbe che abbia una grande arma in mano.
Perchè anche se domani le applicazioni (consumer) invece che in CUDA scritte specificatamente per HW nvidia fossero scritte in OpenCL per supportare anche AMD la differenza di prestazioni sarebbe comunque elevata e non favorirebbe certo AMD.

parli sempre dei test con loop di fma fp32? O di quelli che fanno integer bitshift?

Originariamente inviato da Someone

E mi (ti) chiedo. Dove sta il problema di AMD? Architettura (intesa non solo come tipo di scelta per gli SP vettoriali vs scalari) o driver? O per te non ci sono problemi e AMD offre le stesse capacità di nvidia nei settori dove le due architetture vengono spremute? A parte i bench sintetici con moltiplicazioni vettoriali, hai qualche altro link dove mostri che AMD è a questo livello? Io per ora vedo le "famose" barrette mostrare risultati migliori per nvidia invece che per AMD.

io, invece, mi chiedo dove stia il tuo di problema. AMD va per la sua strada con i suoi prodotti; vende e anche tanto. nVidia fa altrettanto. Il problema non è né di AMD né di nVidia ma di chi guarda le barrette senza capirci un accidente

[Someone]

hai affermato che fermi andava di più con sandra; il tuo stesso link ti ha smentito

Il link che tu hai messo in mostra è il bench sintetico di Sisandra (equivalente ad 3D mark) ed è un bench messo a punto insieme ad AMD. Nei test singoli, dove non si fa semplicemente un loop di una singola istruzione, le prestazioni cambiano.
Cypress scheda con prezzo/prestazioni migliore nel professionale? Ahahah... sìsì, perchè va il doppio dell GF100 montato su una GTX480 e 1/20 dello stesso su una Quadro?
Il chip tra GTX e Quadro è lo stesso, cambia le funzionalità che sono possibili tramite i driver. Ora ti ripeto la domanda, che è di una semplicità disarmante: se i chip sono gli stessi (e lo sono) e con i driver ad hoc si abilitano tutte le funzionalità di cui questi sono capaci (e ci mancherebbe, con quello che si pagano quelle schede) perchè Fermi va il doppio del Cypress? Stiamo parlando di 2 soluzioni che stanno dando (o dovrebbero dare) il massimo delle prestazioni. Dove sta il limite di AMD?

che tipo di operazioni richiede FH?

Usa istruzioni necessarie per fare quello che deve. O uno deve volere una soluzione a seconda dell'architettura che usa? O fare un applicativo che fa un loop infinito di FMA32 per mostrare che una scheda va di più di un'altra? E' una semplice applicazione che fa calcoli (e ne fa tanti) che mostra che l'architettura nvidia funziona meglio. E non è una applicazione fatta da un tizio qualsiasi che si è svegliato la mattina e ha detto: oggi voglio fare una applicazione GPGPU. E' un progetto più che serio dove entrambe AMD e nvidia hanno partecipato attivamente per offrire il meglio. Il risultato non è di qualche punto percentuale di differenza.

Poi ascolta, cerchiamo di recuperare la situazione perchè mi sembra che sia abbastanza degenerata. Tu non hai dato alcuna risposta. Fai solo accenni a cose che tu solo capisci.
Io ho fatto delle domande ben precise, a cui normalmente una persona informata e seria risponde in maniera chiara e comprensibile. Cosa che non è avvenuta.
I test che ho postato come questi: http://www.anandtech.com/show/4008/nvidias-geforce-gtx-580/16 non sono tutti sintetici. In uno di questi si vede che AMD ha un vantaggio rispetto a nvidia, ma in tutti gli altri, dove sono coinvolti operazioni molto complesse come la transcodifica H264 nvidia è decisamente avanti.
Allora, pongo la domanda in maniera diversa: l'approccio VLIW di ATI è efficiente in generale? Ovvero, quanta probabilità c'è in generale che un problema generico possa essere risolto più efficientemente con un approccio vettoriale rispetto a uno scalare?
Guardando le prestazioni di alcuni benchmark, con un calcolo a spanne, sembra che in media gli SP di AMD siano impegnati meno della metà delle loro capacità massime (tenendo conto di numero e frequenza rispetto a quelli nvidia, intendendo come shader proprio le unità singole di calcolo non i gruppi 4+1, ovvero i 1600 shader contro i 512 Cuda core).
Quindi di quelle 5 unità di calcolo solo 2 (più o meno) vengono usate in media. Se i conti spannometrici che ho fatto sono esatti (correggili pure se ho fatto errori), secondo te, è un approccio efficiente rispetto a quello nvidia che li satura sempre tutti magari usando 2 cicli per completare le stesse operazioni che l'architettura AMD fa in un ciclo solo?

[yossarian]

Originariamente inviato da Someone

Il link che tu hai messo in mostra è il bench sintetico di Sisandra (equivalente ad 3D mark)

veramente sei tu che hai postato quei bench. Memoria corta? Inoltre, vedo che si tratta di bench su memory bandwidth e compute shader: ti risulta che abbiano qualcosa a che fare con 3dmark? Nei link che hai postato per avvalorare la tesi che con sandra le amd andavano meno sono questi

Originariamente inviato da Someone

ed è un bench messo a punto insieme ad AMD.

dov'è scritto?

Originariamente inviato da Someone

Nei test singoli, dove non si fa semplicemente un loop di una singola istruzione, le prestazioni cambiano.

quali sarebbero questi test singoli; nei link non ne vedo (a parte il loop di fma fp32 che, sicuramente, non è stato messo a punto insieme ad amd )

Originariamente inviato da Someone

Cypress scheda con prezzo/prestazioni migliore nel professionale? Ahahah... sìsì, perchè va il doppio dell GF100 montato su una GTX480 e 1/20 dello stesso su una Quadro?

http://www.ciao.it/Nvidia_Quadro_6000__3161202

i tuoi conti non tornano

Originariamente inviato da Someone

Il chip tra GTX e Quadro è lo stesso, cambia le funzionalità che sono possibili tramite i driver. Ora ti ripeto la domanda, che è di una semplicità disarmante: se i chip sono gli stessi (e lo sono) e con i driver ad hoc si abilitano tutte le funzionalità di cui questi sono capaci (e ci mancherebbe, con quello che si pagano quelle schede)

allora, facendo uso degli stessi driver, una 480 va quanto una quadro.........

Originariamente inviato da Someone

perchè Fermi va il doppio del Cypress? Stiamo parlando di 2 soluzioni che stanno dando (o dovrebbero dare) il massimo delle prestazioni. Dove sta il limite di AMD?

Qui e qui ci sono tutte le risposte. Cercale, visto che sei tanto bravo

Originariamente inviato da Someone

Usa istruzioni necessarie per fare quello che deve. O uno deve volere una soluzione a seconda dell'architettura che usa? O fare un applicativo che fa un loop infinito di FMA32 per mostrare che una scheda va di più di un'altra? E' una semplice applicazione che fa calcoli (e ne fa tanti) che mostra che l'architettura nvidia funziona meglio. E non è una applicazione fatta da un tizio qualsiasi che si è svegliato la mattina e ha detto: oggi voglio fare una applicazione GPGPU. E' un progetto più che serio dove entrambe AMD e nvidia hanno partecipato attivamente per offrire il meglio. Il risultato non è di qualche punto percentuale di differenza.

che risposta sarebbe?

Originariamente inviato da Someone

Poi ascolta, cerchiamo di recuperare la situazione perchè mi sembra che sia abbastanza degenerata. Tu non hai dato alcuna risposta. Fai solo accenni a cose che tu solo capisci.

io le risposte lo ho date tutte; se non capisci è un tuo problema, grand'uomo

Originariamente inviato da Someone

Io ho fatto delle domande ben precise, a cui normalmente una persona informata e seria risponde in maniera chiara e comprensibile. Cosa che non è avvenuta.

anche io ho fatto domande chiare e precise che tu hai evitato addirittura di quotare. Il tuo scopo non è quello di ottenere risposte ma di dimostrare una tesi indimostrabile. In più non hai le basi teoriche per sostenere una discussione ma hai l'atteggiamento di chi sa tutto. Hai fatto una serie di affermazioni categoriche smontate dai fatti ma, nonostante tutto, insisti. Allora tieniti le tue convinzioni, visto che ti rifiuti di vedere tutto quello che potrebbe farle crollare. Oppure fai uno sforzo e cerca di studiare un po' di teoria (che schifo!!!!) e non limitarti a guardare le barrette colorate che neppure comprendi.

Originariamente inviato da Someone

I test che ho postato come questi: http://www.anandtech.com/show/4008/n...rce-gtx-580/16 non sono tutti sintetici. In uno di questi si vede che AMD ha un vantaggio rispetto a nvidia, ma in tutti gli altri, dove sono coinvolti operazioni molto complesse come la transcodifica H264 nvidia è decisamente avanti.

la transcodifica h264 non è un'operazione complessa e nei link che ti ho postato c'è la risposta anche a questo. Cercala.

Originariamente inviato da Someone

Allora, pongo la domanda in maniera diversa:

ok, adesso si inizia a ragionare.

Originariamente inviato da Someone

l'approccio VLIW di ATI è efficiente in generale?

no, come non lo è nessun tipo di approccio. L'architettura con alu di tipo vliw permette di ottenere un'elevata efficienza di tipo performance/watt e, ancora di più, performance/area ma non di avere un'elevata efficienza in valore assoluto.

Originariamente inviato da Someone

Ovvero, quanta probabilità c'è in generale che un problema generico possa essere risolto più efficientemente con un approccio vettoriale rispetto a uno scalare?

dipende; in realtà l'approccio vettoriale è ancora differente da uno di tipo vliw. In ogni caso, se guardi le due tabelle di inizio pagina http://www.beyond3d.com/content/reviews/55/11
puoi farti un'idea del tipo di codice che può favorire una o l'altra architettura. Apparentemente, l'architettura vliw ha più situazioni in cui è in vantaggio. Però queste situazioni coinvolgono sempre operazioni di tipo vettoriale. Nelle operazioni scalari (tipo la fma fp32 più volte citata), solo una delle 5 vie di ogni alu è occupata nell'esecuzione dell'istruzione. I SW sono un mix di istruzioni di tipo scalare e vettoriale, in floating point o con interi. Se ho un SW che propone un loop di fma o mad fp32, fermi andrà alla massima velocità mentre cypress ad 1/5 della velocità possibile. Diciamo che l'architettura vliw è più dipendente rispetto alle ottimizzazioni del codice ed alla bontà del compilatore, perchè per avere il maggior numero di alu attive è necessario trovare più istruzioni, relative allo stesso thread, indipendenti tra loro (in modo che possano essere chiamate contemporaneamente). In caso di istruzioni scalari dipendenti le une dalle altre (devo aspettare il termine dell'esecuzione di una perchè nella successiva devo inserire il risultato della precedente) l'approccio vliw è molto penalizzato.
Un esempio pratico è quello che hai fatto sulle transcodifiche. In quel tipo di operazioni, si fa molto ricorso all'utilizzo di interi e, dalle tabelle, puoi vedere che, ad esmepio, nell'escuzione dei calcoli con interi fermi, tranne il caso di mad di tipo vect4 (poco usata in questo contesto) è alla pari con cypress e, addirittura, si avvantaggia nell'uso della mad di tipo scalare.

Originariamente inviato da Someone

Guardando le prestazioni di alcuni benchmark, con un calcolo a spanne, sembra che in media gli SP di AMD siano impegnati meno della metà delle loro capacità massime (tenendo conto di numero e frequenza rispetto a quelli nvidia, intendendo come shader proprio le unità singole di calcolo non i gruppi 4+1, ovvero i 1600 shader contro i 512 Cuda core).
Quindi di quelle 5 unità di calcolo solo 2 (più o meno) vengono usate in media.

molto dipende dalle ottimizzazioni del SW. A spanne, l'impiego varia dalle 3 alle 4 con una media di poco inferiore alle 3,5 vie di un'alu 5-way vliw (motivo per cui si sta valutando l'ipotesi di alu 4-way). In ogni caso, in un'elaborazione complessa entrano in gioco altri fattori di limitazione.
Se guardi, sempre nella stessa pagina, i grafici (con esclusione di quelli DP che è usata solo per il gpgpu), puoi vedere che, a parte i domain shader (una delle componenti dell'operazione di tessellation), in tutte le operazioni di tipo geometrico fermi è mediamente avanti, mentre nelle operazioni di pixel shading è avanti solo con valori scalari (lo stesso puoi vederlo qua e qua). Sia i grafici (sperimentali) che le tabelle (teoriche) comprendono tutte le situazioni possibili (scalari, vettoriali con 2, con 3, con 4 istruzioni indipendenti per ciclo). Ad esempio, un singolo thread con 3 istruzioni indipendenti, su cypress è eseguito in un solo ciclo su fermi in 3 cicli. Quindi, in quel caso, avere 3 alu in parallelo è vantaggioso rispetto ad averne una sola per thread. Sulle operazioni di tipo trascendentale è avvantaggiato cypress perchè ha una unità per ogni alu, dedicata a quel tipo di operazioni, mentre fermi ne ha solo 4 per ogni cluster di alu. Nelle operazioni con interi, invece, fermi ha una unità dedicata ogni due alu floating point mentre cypress una ogni 5.
Poi ci sono le operazioni di texturing dove è avvantaggiato cypress; questo perchè il texture filtering è eseguito dallo shader core e nei chip nVidia le texture arrivano compresse e devono essere decompresse prima dell'applicazione. Però, all'aumentare delle dimensioni delle texture, il vantaggio di cypress diminuisce a causa del fatto che le texture sono decompresse nel passaggio in L1 e, di conseguenza, occupano più spazio, mentre fermi le decomprime solo quando prima di effettuare l'interpolazione. .
Nelle operazioni di branching fermi utilizza una granularità inferiore (quad di 16 vertex value o 32 pixel vs 16 vertici o 64 pixel) e risulta più efficiente mentre nelle operazioni di color blendong è in vantaggio cypress.
Infine ci sono gli accessi alle varie memorie e il triangle setup engine in cui è in vantaggio fermi grazie alla possibilità di caricare più di un triangolo per ciclo di clock.
Le variabili in gioco sono tantissime e non è possibile ridurre tutto ad un confronto tra l'efficienza delle sole alu, fermo restando che un'architettura vliw è, in assoluto, meno efficiente se si fa il confronto con i limiti teorici, rispetto ad una superscalare. La diminuzione di efficienza dipende, come detto, in massima parte d come è ottimizzato il SW (per questo un bench che prevede un loop di mad fp32 non può essere stato studiato insieme ad amd, ad esempio).
La cosa curiosa di tutto questo è che c'è stata un'inversione in molti campi rispetto al passato; ad esempio, fino a G70 ed R5x0, il dynamic branching di nVidia era un disastro mentre era in vantaggio con le operazioni di texture filtering. Discorso analogo per le operazioni geometriche e per le raster operation (color e alpha blending). Nelle prime era in vantaggio ATi e nelle seconde nVidia.

Originariamente inviato da Someone

Se i conti spannometrici che ho fatto sono esatti (correggili pure se ho fatto errori), secondo te, è un approccio efficiente rispetto a quello nvidia che li satura sempre tutti magari usando 2 cicli per completare le stesse operazioni che l'architettura AMD fa in un ciclo solo?

AMD punta ad avere un elevato rapporto performance/area e performance/watt, in modo da ridurre i costi di produzione. Ovviamente, parte di quello che non si spende a livello di progettazione e ricerca per l'hardware lo si spende per il SW, poichè l'architettura vliw sposta parte del lavoro di parallelizzazione a livello di compilatore (quanto di questo lavoro è spostato a livello di software dipende dal tipo di architettura, poichè esistono 3 tipi riconducibili al modello vliw, uno detto "statico", uno "dinamico" e, infine la epic). Sui chip AMD il bilanciamento dei carichi di lavoro è gestito via hardware, come in quelli nVidia; quello che è gestito via SW è l'ILP (instruction level parallelism) ovvero il compilatore si deve occupare di cercare il maggior numero di istruzioni relative ad uno stesso thread che siano indipendenti. Se l'applicazione è scritta pprivilegiando poerazion scalari e istruzioni dipendenti, il lavoro del compilatore non è per nulla avvantaggiato .
Dal canto suo, invece, nVidia ha spostato la maggiore complessità a livello di hardware. Questo significa che i suoi chip sono meno dipendenti dall'ottimizzazione del SW ed è più semplice ottimizzare via driver. Lo svantaggio di questo approccio è che gran parte dei transistor sono utilizzati per circuiti che svolgono compiti non funzionali ai calcoli (circuiti di controllo, feedback, gestione dei clock, instruction e data fetch). Inoltre, un altro vantaggio di cypress è che per mascherare le latenze necessità di un numero inferiore di thread in circolazione all'interno della pipeline, il che si traduce in un minor ricorso a buffer di registri atti temporanei, atti a contenere i risultati intermedi delle elaborazioni. Il core di un chip come fermi, quindi, rispetto a cypress, ha, in percentuale, un'area di molto inferiore dedicata alle unità di calcolo vere e proprie. La scelta è stata dettata principalmente dal fatto che nVidia è obbligata a spingere sul gpgpu non potendo realizzare architetture x86 (che resta, nonostante tutto, il modello più utilizzato anche nei sistemi HPC) mentre AMD può puntare su apu asimmetriche con una cpu e una o più gpu come coprocessori
Di conseguenza, da un lato hai una maggiore efficienza che paghi con il poco spazio da poter dedicare alle unità di calcolo (da qui la necessità di differenziare il clock degli shader rispetto al resto del core del chip). Dall'altro una minor efficienza che compensi potendo, ad ogni nuovo processo produttivo, inserire un numero molto maggiore di unità di calcolo rispetto alla concorrenza.
Chiudo con la conclusione dell'articolo di B3D

Great performance with the newest games is in great part-owed to developer relations superiority -- we're sure we'll get some hate-mail over this statement, but we're at a point where we can call them as they are, rather than cater to anyone's sensibilities -- rather than some intrinsic mystic hardware unit that exists only in NVIDIA's products.

And all of this put together underlines the truth that some still choose to ignore: great hardware is nothing without software. We dare say that NVIDIA's great software stack made Fermi look a bit better competitively than its hardware would have allowed (just look at sheer measured throughput!) -- luckily for them, it appears that this particular situation won't be changing soon, with no competitive pressure on the horizon on the software front.

We think that going forward, the major challenges for NVIDIA's architects will be to get all of the nice ideas they've implemented trimmed down in order to descend into the more palatable die-size/thermal envelope area required by smaller chips, as well as smooth off some of the rougher corners: more L2 bandwidth, better GDDR5 memory controllers and better performance for atomics depending on where they're stored in the memory hierarchy spring to mind as viable avenues to pursue, and all would benefit both graphics and compute workloads.

quello che è riportato per i giochi lo si può estendere al SW in generale, compreso quello pro. Migliori relazioni con gli sviluppatori significa, tradotto in parole povere, miglior ottimizzazione del codice per l'hardware nVidia.
In quanto all'ultima parte, sono curioso di vedere se e come sarà affrontato il problema di cercare di ridurre le dimensioni dei chip. Per quanto detto prima, se nVidia mantiene questa tipologia di architettura avrà sempre poco spazio sul die da poter dedicare alle unità funzionali. Ridurre ancora la granularità dei cluster (dai 16+16 attuali) porterebbe ad un incremento dell'efficienza del singolo cluster ma anche ad un ulteriore aumento dello spazio da dedicare a elementi non funzionali.

[Someone]

Sono finalmente riuscito a leggere tutta la review di Beyond3D riguardo a Fermi (il lavoro, questa rottura...)
Premesso che questi test estremamente sintetici hanno solo valore indicativo, dato che come hai detto tu le variabili in gioco sono tantissime e sarebbe bello avere un bench in cui si faccia qualcosa di concreto che prenda in esame la collaborazione delle varie parti della pipeline di calcolo/3D invece che una sola parte specifica, aggiungo solo che i valori di performance nel calcolo DP in quei test è 1/4 e il setup dei triangoli è una frazione di quello che Fermi è in grado di fare per via proprio dei driver "consumer" a cui le GTX sono relegati. Relativamente agli apparenti risultati deludenti dei bench della GTX470 in esame:

In fact, we struggled with many potential theories, until a fortuitous encounter with a Quadro made the truth painfully obvious: product differentiation, a somewhat en vogue term over at NVIDIA, it seems. The Quadro, in spite of being pretty much the same hardware (this is a signal to all those that believe there's magical hardware in the Quadro because it's more expensive – engage rant mode!), is quite happy doing full speed setup on the untessellated plebs.

allora, facendo uso degli stessi driver, una 480 va quanto una quadro.........

Premesso che le Quadro sono fatte con i chip delle 470 non delle 480, l'hack del bios delle schede consumer per farle "sembrare" delle vere Quadro è noto da tempo. nvidia ha deciso di difendere il proprio mercato professionale dall'uso dello stesso HW che vende nel mercato consumer in questo modo. Quando compri una GTX sai che avrai 1/4 delle capacità di calcolo DP e una limitata capacità di gestione delle viewport che vengono completamente sbloccate se paghi di più.

Ecco perchè Fermi su una GTX480 nei test professionali è una schifezza assoluta, mentre montato su una Quadro risulta essere decisamente più veloce anche della concorrenza che secondo i test di Beyond3d dovrebbe essere teoricamente molto (ma molto) più veloce.

L'unica cosa che sembra non essere all'altezza con la concorrenza è il fillrate e la gestione delle texture, sempre secondo i test riportati. Poi per via della diversa modalità di gestione delle texture sarebbe interessante capire quanto di quel vantaggio che i grafici mostrano siano reali in una applicazione reale dove le texture non sono normalmente completamente contenibili nella L1 del Cypress (oltre a verificare che impatto ha la trasmissione di più dati nel Cypress o lo switching di thread che necessitano della L1 che deve essere liberata).

A parte questi dettagli, quello che sembra è che Fermi sia pensato veramente come un sistema General Purpose senza "additivi" vari specialistici. Per quanto è possibile nvidia ricicla le unità standard presenti nel chip per eseguire in maniera generica tutte le possibili computazioni, mentre AMD sembra aver aggiunto HW apposito là dove lo riteneva opportuno.
I due approcci sono equivalentemente validi, ma quello nvidia (sebbene non particolarmente performante in alcune situazioni) sembra permettere una gestione più facile del proprio HW dato che percorsi e inevitabili conflitti sono più facilmente prevedibili e lo scheduler può in questa maniera essere più efficiente. E la logica di gestione la può fare in HW.
Ecco perchè ritengo che la valutazione delle performance andrebbe fatta con un bench che implichi l'uso reale delle risorse per evidenziare l'architettura meglio bilanciata (più efficiente) invece che un'ispezione particolare di ogni sottoparte. Queste analisi sono molto interessanti, ma non danno il senso di quello che è poi il risultato finale, che come in tutti i sistemi complessi (e questi sono forse la cosa più complessa che l'uomo abbia mai creato) non sono la semplice somma dei risultati parziali.
Premesso che la soluzione VLIW sia 4 volte più veloce della soluzione scalare di nvidia in alcune istruzioni, se queste però sono il 5% del totale delle istruzioni eseguite (faccio una ipotesi di quello che potrebbe essere un algoritmo generico) allora il vantaggio prestazionale non sarà evidente e si manterrà un misurabile vantaggio solo se il resto delle istruzioni vengono eseguite almeno con la stessa efficacia della concorrenza. Basta un punto che faccia da collo di bottiglia (o semplicemente il fatto che i risultati ottimali mostrati dai test non si riesca mai a ottenerli in condizioni reali) e tutta la teoria va a escort.

La pratica per ora dice che le Quadro vanno il doppio delle FirePro anche se i test fin qui mostrati suggerirebbero proprio il contrario. Più difficile valutare la parte di computazione dove l'implementazione dell'algoritmo è fondamentale , ma quelli OpenCL mostrano una situazione analoga.

Domanda finale: e' possibile la situazione futura in cui AMD "restringe" la sua architettura VLIW (oltre a quello fatto con Cayman) mentre nvidia "espande" la sua magari a 2 unità in parallelo? O per nvidia la cosa sarebbe troppo difficoltosa e la preferenza sarebbe piuttosto quella i raddoppiare le proprie unita scalari (a discapito della logica HW necessaria a connetterli e gestirli)?

[yossarian]

Originariamente inviato da Someone

Sono finalmente riuscito a leggere tutta la review di Beyond3D riguardo a Fermi (il lavoro, questa rottura...)
Premesso che questi test estremamente sintetici hanno solo valore indicativo, dato che come hai detto tu le variabili in gioco sono tantissime e sarebbe bello avere un bench in cui si faccia qualcosa di concreto che prenda in esame la collaborazione delle varie parti della pipeline di calcolo/3D invece che una sola parte specifica, aggiungo solo che i valori di performance nel calcolo DP in quei test è 1/4

e questo lo avevamo già detto con pleg. Infatti, in quei test, una tesla pareggia, all'incirca il conto in molti test dove la 470 è sotto.

Originariamente inviato da Someone

e il setup dei triangoli è una frazione di quello che Fermi è in grado di fare per via proprio dei driver "consumer" a cui le GTX sono relegati. Relativamente agli apparenti risultati deludenti dei bench della GTX470 in esame:

Premesso che le Quadro sono fatte con i chip delle 470 non delle 480, l'hack del bios delle schede consumer per farle "sembrare" delle vere Quadro è noto da tempo. nvidia ha deciso di difendere il proprio mercato professionale dall'uso dello stesso HW che vende nel mercato consumer in questo modo. Quando compri una GTX sai che avrai 1/4 delle capacità di calcolo DP e una limitata capacità di gestione delle viewport che vengono completamente sbloccate se paghi di più.

Ecco perchè Fermi su una GTX480 nei test professionali è una schifezza assoluta, mentre montato su una Quadro risulta essere decisamente più veloce anche della concorrenza che secondo i test di Beyond3d dovrebbe essere teoricamente molto (ma molto) più veloce.

finalmente
ora è chiaro che con SW pro vengono castrate le gpu consumer (nVidia lo fa in maniera molto più pesante ma lo fa anche ati) e viceversa (guarda caso, con i giochi, le schede pro vanno sempre "un po' di meno" a parità di specifiche

Originariamente inviato da Someone

L'unica cosa che sembra non essere all'altezza con la concorrenza è il fillrate e la gestione delle texture, sempre secondo i test riportati. Poi per via della diversa modalità di gestione delle texture sarebbe interessante capire quanto di quel vantaggio che i grafici mostrano siano reali in una applicazione reale dove le texture non sono normalmente completamente contenibili nella L1 del Cypress (oltre a verificare che impatto ha la trasmissione di più dati nel Cypress o lo switching di thread che necessitano della L1 che deve essere liberata).

direi anche i calcoli che prevedono l'utilizzo di vettori anzichè scalari.
Per le operazioni di texturing, quando si fa un accesso a texture la pipeline non va in stallo in attesa del completamento dell'operazione ma il relativo thread vìene "parcheggiato" in attesa del dato mancante (la texture nella fattispecie) e si passa ad un altro thread (indipendente dal risultato di quello in esecuzione, ovviamente). Un altro fattore che non hai considerato nella generazione delle operazioni di texture e non solo è la gerarchia delle memorie interne. In questo l'architettura vliw è superiore i quanto i dettagli dell'architettura sono completamente esposti. Il risultato è una maggiore efficienza che si traduce in una maggiore velocità nelle operazioni di load e store dai registri e un miglior mascheramento delle latenze (dovuto soprattutto alla maggior velocità di accesso ai vari ordini di memoria).
In quanto al discorso sulla L1, questo è valido solo in caso di cache miss, piuttosto improbabile con gerarchia delle cache di tipo fully associative associata ad algoritmi di branching. .

Originariamente inviato da Someone

A parte questi dettagli, quello che sembra è che Fermi sia pensato veramente come un sistema General Purpose senza "additivi" vari specialistici. Per quanto è possibile nvidia ricicla le unità standard presenti nel chip per eseguire in maniera generica tutte le possibili computazioni, mentre AMD sembra aver aggiunto HW apposito là dove lo riteneva opportuno.

rispetto a nvidia, l'unico hardware dedicato di amd è quello relativo a hull e domain shader. Per il resto, pixel, vertex e geometry shader, nonchè texture filtering, sono svolte dalle alu. Le operazioni di texture fetch e address sono svolte da unità dedicate nelle tmu; lo stesso vale per le operazioni a livello di ROP's. Questo perchè è molto più efficiente un approccio di questo tipo (unità dedicate di tipo fixed function) piuttosto che unità generiche (come si proponeva intel con larrabee). Entrambe hanno aggiunto alu di tipo integer per le operazioni con interi (amd una per ogni alu 5-way, nvidia una ogni due unità floating). Anche per le operazioni trascendentali ci sono unità dedicate (amd ne ha una per ogni alu 5-way nvidia 4 ogni cluster di alu; questo spiega il fatto che in questo tipo di operazioni i chip ati sono più veloci).

Originariamente inviato da Someone

I due approcci sono equivalentemente validi, ma quello nvidia (sebbene non particolarmente performante in alcune situazioni) sembra permettere una gestione più facile del proprio HW dato che percorsi e inevitabili conflitti sono più facilmente prevedibili e lo scheduler può in questa maniera essere più efficiente. E la logica di gestione la può fare in HW.

anche nei chip ati il bilanciamento dei carichi è gestito in hardware. Solo la parallelizzazione è affidata al compiler; in pratica il compiler "cerca" istruzioni non indipendenti relative ad un thread, le impacchetta e le passa al thread processor. Fisicamente di questa operazione si occupa un thread generator
La differenza la possono fare applicazioni difficilmente parallelizzabili che favoriscono l'HW nvidia.

Originariamente inviato da Someone

Ecco perchè ritengo che la valutazione delle performance andrebbe fatta con un bench che implichi l'uso reale delle risorse per evidenziare l'architettura meglio bilanciata (più efficiente) invece che un'ispezione particolare di ogni sottoparte. Queste analisi sono molto interessanti, ma non danno il senso di quello che è poi il risultato finale, che come in tutti i sistemi complessi (e questi sono forse la cosa più complessa che l'uomo abbia mai creato) non sono la semplice somma dei risultati parziali.

Il problema di un sw del genere è che dovrebbe essere del tutto scevro da ottimizzazioni di sorta. Il che è praticamente impossibile per diversi motivi. Se scrivi codice facilmente parallelizzabile favorisci ati, se lo scrivi con forte prevalenza di operazioni seriali nvidia, con la tessellation favorisci nvidia, con le testure ati. E basta poco a spostare l'equilibrio anche di tanto (hai visto cosa si può fare a livello di driver, soprattutto per "castrare" un chip. E non è finita. Due architetture identiche ma con differente ID (in modo che siano riconoscibili) possono comportarsi in maniera molto differente con o stesso SW. Questo perchè a livello di driver o di hal (hardware later abstraction) ho la possibilità di individuare e inibire alcune funzionalità su un chip e non s su un altro. Basta, ad esempio, agire sulla gestione degli accessi alla memoria per creare disastri (è uno dei modi più semplici per far crollare le prestazioni di un chip)

Originariamente inviato da Someone

Premesso che la soluzione VLIW sia 4 volte più veloce della soluzione scalare di nvidia in alcune istruzioni, se queste però sono il 5% del totale delle istruzioni eseguite (faccio una ipotesi di quello che potrebbe essere un algoritmo generico) allora il vantaggio prestazionale non sarà evidente e si manterrà un misurabile vantaggio solo se il resto delle istruzioni vengono eseguite almeno con la stessa efficacia della concorrenza. Basta un punto che faccia da collo di bottiglia (o semplicemente il fatto che i risultati ottimali mostrati dai test non si riesca mai a ottenerli in condizioni reali) e tutta la teoria va a escort.

hai centrato il punto; dipende da come è scritto il codice. Le istruzioni assimilabili ad un vettore possono essere il 5 o il 95%. Tutto dipende dal programmatore. Si può anche aggiungere che l'architettura nvidia ha prestazioni più lineari. Ovvio che le ottimizzazioni sono importanti, ma non avrai mai picchi in negativo o in positivo che puoi avere con quella amd. Una hd5870 che elabora solo istruzioni seriali (mi limito ai soli calcoli matematici) ha l'equivalente di 320 e non più 1600 alu a 850 MHz.

Originariamente inviato da Someone

La pratica per ora dice che le Quadro vanno il doppio delle FirePro anche se i test fin qui mostrati suggerirebbero proprio il contrario. Più difficile valutare la parte di computazione dove l'implementazione dell'algoritmo è fondamentale , ma quelli OpenCL mostrano una situazione analoga.

il fatto è che dovremmo sapere che tipo di codice elaborano quando eseguono quei test.

Originariamente inviato da Someone

Domanda finale: e' possibile la situazione futura in cui AMD "restringe" la sua architettura VLIW (oltre a quello fatto con Cayman) mentre nvidia "espande" la sua magari a 2 unità in parallelo? O per nvidia la cosa sarebbe troppo difficoltosa e la preferenza sarebbe piuttosto quella i raddoppiare le proprie unita scalari (a discapito della logica HW necessaria a connetterli e gestirli)?

no per entrambe. AMD perderebbe il vantaggio dell'architettura vliw (architettura semplice con elevato livello di ILP. Al contrario, se nVidia punta ad un'architettura CPU-like deve avvicinarsi il più possibile ad un modello tipo MIMD (ossia molte istruzioni in ingresso per molti dati in uscita). Il modello a cui si rifà il singolo cluster è quello SIMD, ovvero, pur operando su thread differenti, ogni alu esegue lo stesso tipo di istruzione delle altre dello stesso cluster (lo stesso vale per AMD). Con g80 ogni cluster aveva 16 alu che sono diventate 24 con GT200. Con fermi si è passati a 32 per problemi di gestione nello scambio dati tra cluster (16 stream processor sono un numero considerevole (considera che io definisco stream processor un intero cluster)). Per ridurre l'impatto negativo di avere 32 alu ad eseguire lo stesso tipo di istruzione e, quindi, per ricreare una "granularità" simile a quella di g80, è stato introdotto un doppio schedule per ogni cluster.