NoRemorse
09-11-2007, 16:52
evitiamo i commenti inutili dati da una lettura superficiale e senza alcuna ricerca in rete. Alcuni punti sono chiari:
Il prodotto di AMD è una buona notizia per avere competizione con i sistemi Tesla di NVidia (W la concorrenza)!
L'ambito di utilizzo è chiarissimo: elaborazione parallela di grossa mole di dati; i case studies pubblicati da NVidia e HWupgrade, e molti altri in rete sono chiarissimi.
Le chiacchere sulle CPU in questo ambito stanno a zero... meglio un cluster di 10 server o stà scheda? Eddai!
E strutture, mantenimento, condiz, alim elettrica......
Non confondiamo DPFP, MTBF, SMART supercomputer e amenità varie... Wiki please.
Numerosi spunti per la trasformazione delle comuni GPU in GPGPU ci sono, e saranno una interessante prospettiva, ma qui la richiesta è MOLTO diversa.
Un po di chiarezza
Le gpu vengono usate "solo" per i giochi perchè sono progettate per quello: quello sanno fare bene, e quello fanno. Punto.
Che poi riescano a fare anche dell'altro, ok, siamo contenti, ma non significa che riescono a farlo bene quanto una cpu, per quanto sulla carta siano più "potenti". Una cpu è progettata per essere flessibile, in un certo senso si "adatta" al software. Nel caso della gpu, invece, e il software a doversi adattare, se e solo se è possibile farlo: di conseguenza una gpu può eseguire efficientemente solo quei software, o parti di essi, che si adattino alle sue caratteristiche, quindi può fare da coprocessore e svolgere alcuni compiti "in delega" dalla cpu, ma solo se il software è stato scritto apposta; in tutti gli altri casi, la gpu sarebbe ampiamente sottosfruttata, quindi di quel "10 volte più potente" non ce ne facciamo nulla; al limite, quando non è utilizzata per fare ciò che sa fare meglio (i giochi) potrebbe svolgere alcuni compiti che non farà in maniera eccellente, ma gioverebbe, in parte, alla cpu, sgravata di qualche calcolo.
Tuttavia, siccome a livello di istruzioni cpu e gpu sono, in genere, totalmente incompatibili, una soluzione ibrida che non usi esclusivamente o solo parzialmente (come mi pare faccia kaspersky) la gpu, ma preveda l'esecuzione dell'intero software sia sulla gpu, sia sulla cpu (passando, all'occorrenza, dall'una all'altra), o la fai perchè ti serve davvero (ad esempio, le directx sono scritte per poter sopperire all'assenza di una gpu compatibile mediante emulazione software, cioè tramite la cpu, con tutte le conseguenze del caso), o perchè sei una softwarehouse supercaxxuta e ti aspetti un ritorno pubblicitario notevole, oppure perchè sei completamente pazzo: in soldoni, stiamo parlando di scrivere lo stesso software 2 volte, fare il doppio del testing per "combattere", grossomodo, il doppio dei bug, impiegare il doppio del tempo e/o il doppio delle risorse (umane, tecnologiche, ecc.) e spendere il doppio dei soldi, senza avere buone probabilità di cavare un ragno dal buco, specialmente in ambito desktop. In ambito professionale, invece, le speranze ci sono, ma si ha a che fare con esigenze più specifiche e probabilmente con (parti di) algoritmi che ben si adattano alle caratteristiche tecniche di una gpu, quindi ricadiamo nel caso "sensato": una parte del software ottimizzata per la cpu, il resto per la gpu che fa da coprocessore.
Una soluzione potrebbe consistere in un compilatore jit che traduca al volo le istruzioni della cpu in istruzioni per la gpu (facile a dirsi, molto meno a farsi, perchè alcune cose potrebbero essere difficili o impossibili da fare, e poi bisogna considerare anche il diverso modo di usare la memoria, l'eventuale necessità di un supporto da parte del sistema operativo, che a sua volta dovrebbe essere in grado di girare in parte sulla gpu - e molte cose necessarie al s.o. le gpu non possono farle, ecc.). Il jit potrebbe far parte dei driver ed essere eseguito dalla stessa gpu; tuttavia, comporterebbe delle latenze, latenze che comunque si ritroverebbero, forse anche maggiori, nello scenario con il software nativamente compilato sia per la cpu, sia per la gpu (ad ogni cambio, bisognerebbe sostituire porzioni di codice più o meno grosse, che potrebbero non rientrare in ram: sarebbe come tornare al meccanismo degli overlay autoescludenti, dvendo swappare continuamente, nella peggiore delle ipotesi, dal disco alla ram e dalla ram alla vram, e viceversa...).
Il discorso potrebbe essere diverso per Larrabee, visto che nasce come multicore x86 (in buona sostanza, si tratta di una grossa cpu, con i core un po' castrati e adattati a svolgere i compiti di una gpu/di un coprocessore), però bisognerà vedere come si comporterà in ambito videoludico (visto che stavamo parlando di normali gpu desktop usate per il general purpose, e sempre in ambito desktop). Comunque, spostare un intero processo o un gruppo di thread (assimilabili a un unico processo: altrimenti sarebbe come voler spostare singoli thread da una unità all'altra in un cluster, non è proprio la cosa migliore da farsi) dalla cpu alla gpu, nel caso di Larrabee, non dovrebbe essere particolarmente difficile.
Chiarito questo, veniamo alla differenza tra le schede in oggetto e le normali gpu desktop: a parte la memoria e altri probabili accorgimenti, la selezione dei componenti, ecc. la news dice una cosa fondamentale, che è già stata sottolineata debitamente in precedenza, ma che qualcuno ha contestato, quindi è opportuno chiarire: la doppia precisione. Nella vita siamo liberi di credere tutto quello che vogliamo, però questo, purtroppo (e non lo dico ironicamente: sarebbe veramente bello poter realizzare un desiderio solo... desiderandolo!), non implica che le cose stiano necessariamente come pensiamo. Le unità in doppia precisione, in una gpu, o ci sono, oppure non ci sono: non si possono implementare "dopo". Fpga, ovvero field programmable gate array, è tutta un'altra tecnologia: si usa per realizzare circuiti elettronici "programmabili", cioè modificabili in maniera analoga a quella usata per riscrivere una eeprom; questo consente di riutilizzare uno stesso processore in contesti diversi, o di realizzare rapidamente macchine specializzate partendo da una "base" preconfezionata, e senza grandissime pretese prestazionali. Una cpu e una gpu (ma soprattutto la cpu) hanno circuiterie molto ma molto ottimizzate, cosa che un integrato in logica programmabile non può consentire, quindi sono realizzate in maniera TOTALMENTE divera!
Ma perchè le schede per il mercato di massa non sono in double precision, mentre queste si? Non sarebbe più facile realizzare un solo progetto, e risparmiare sui costi di produzione? La risposta è no, perchè le gpu sono progettate pensando specificamente ai giochi, e i giochi non hanno bisogno, per ora, di andare oltre i 32 bit. Facciamo un piccolo salto indietro. Fino a pochi anni fa, la massima precisione richiesta dalle librerie grafiche (per implementare particolari shader, o per applicare texture) era a 16 bit (la metà di adesso, e parlando di numeri reali approssimati la differenza non è poca!), e le schede video si fermavano a 16bit. Poi, sono arrivati nuovi shader model, che hanno introdotto la precisione a 32bit, cosa che richiedeva l'adeguamento delle schede video (delle nuove generazioni, non quelle già in vendita!), e per farlo erano possibili due strade: creare unità di calcolo indipendenti, alcune a 16, altre a 32, oppure farle tutte solo a 32bit. Ma perchè tanto sbattimento? Perchè il raddoppio di precisione implica una (relativamente piccola) perdita prestazionale, che poteva farsi sentire molto con i giochi che non avevano bisogno dei 32bit. Però, fare delle unità dedicate ai calcoli a 16 bit, altre per quelli a 32 implicava un costo, perchè si tratta di mettere sul chip dei transistor in più (cioè farlo più grande); tuttavia, siccome inizialmente i giochi non usavano/usavano poco i 32bit, allora si potevano limitare le risorse dedicate a quei calcoli, a vantaggio dei 16 bit; l'altra soluzione (tutto a 32bit) era più semplice, ma rischiava di portare delle penalizzazioni (naturalmente, in questi casi si può cercare di ovviare con ottimizzazioni particolari, aumenti di clock ecc.). Alla fine, la situazione si è normalizzata, con giochi più "pesanti" e graficamente "migliori", che sfruttano appieno e prevalentemente la precisione a 32 bit. Lo stesso, naturalmente, vale anche oggi: se una gpu è prodotta e venduta, principalmente, per i videogames, e se nessun videogames userà la doppia precisione ancora per parecchio tempo, perchè mai una vga di oggi dovrebbe essere capace di calcoli sui double? Se la concorrenza non fa la stessa cosa che succede? succede che le tue schede andranno sicuramente almeno un po' più lente!
Diverso il discorso per il gpgpu di un certo livello, per il quale i calcoli in doppia precisione possono essere necessari, quindi ha senso produrre delle schede dedicate, che implementano la doppia precisione e che, naturalmente, saranno prodotte a parte, in quantità limitatà e costeranno di più (anche molto di più). In realtà, ci sono molti scenari di calcolo "pesante" (matriciale), in cui può bastare la precisione a 32 bit (specialmente se è possibile approssimare le formule con degli sviluppi numerici interi). In questi ambiti, si usano in genere dei dsp (digital signal processor)/degli stream processor, che appunto elaborano o solo interi (in genere fino a 32 bit), o solo floating point (a 16 o 32 bit, di solito), oppure sono ibridi (e continuano a "fermarsi", nella maggioranza dei casi, a 32 bit), e in questi casi una normalissima gpu può fare la sua "porca" figura (basti pensare ai risultati di folding@home con le ati 19xx, ma anche con cell, le cui spe non sono altro che dei dsp). Ma se sono stati introdotti i 64 bit nelle schede destinate al gpgpu di alto livello, si vede che c'è/si prevede una certa richiesta di queste schede anche per tutte quelle elaborazioni scientifiche che necessitano appunto della double precision (la quale, in realtà, di solito non si implementa a 64 bit, ma a 80, per avere una maggiore precisione nei calcoli prima dell'approssimazione a 64).
Spenderei le ultime 2 parole sulla possibilità di usare schede di questo tipo come "semplici" gpu: salvo complicazioni lato driver (verisimili, ma non troppo), la cosa si dovrebbe poter fare appoggiandosi ad un'ulteriore scheduzza 2d su pci (meglio se limitando la risoluzione - su pcie a 2/4x non dovrebbero esserci problemi), o una seconda scheda entry-level in sli/crossfire (se compatibile), o semplicemente una vga integrata. Mi spiego: lo standard pci express per le vga, prevede una banda non solo maggiore rispetto all'agp, ma anche simmetrica, la quale dovrebbe consentire una più "abbondante" comunicazione non solo verso la gpu, ma anche dalla gpu alla memoria centrale, quindi una migliore cooperazione tra gpu e cpu, che nei giochi dovrebbe portare ad effetti grafici/fisici migliori, più realistici; tuttavia, non mi pare che questa possibilità sia attualmente sfruttata (molto, e comunque quello che ho in mente non richiederebbe una banda eccessiva), quindi si potrebbe usare la scheda gpgpu per calcolare la grafica, quindi "tirare" fuori i frame prodotti e indirizzarli alla scheda dotata di uscite video, sia che si sfrutti un eventuale sli/cf (cioè veicolando i dati su pcie), sia che si debba passare per la memoria centrale e indirizzare i frame verso la scheda aggiuntiva o l'integrata (in ogni caso, meglio se si usa della memoria dedicata e si passa da hyper transport, così da non impegnare troppo il sistema). Ma è un discorso fine a se stesso, per dire che, in fondo, se si vuol fare qualcosa, un modo si trova; sta a vedere se conviene. ;)
Se bastassero delle librerie matematiche scritte ad hoc per risolvere tutti i problemi del mondo, allora smetterebbero di esistere programmatori e software house... il produttore (di qualsiasi cosa) fornirebbe le librerie e un semplicissimo wizard per realizzare qualsiasi tipo di programma che faccia funzionare l'hardware... ma le cose nel mondo reale funzionano diversamente... algoritmi specifici richiedono implementazioni specifiche A SECONDA DELLA MACCHINA SU CUI DEVONO GIRARE, altrimenti le prestazioni vanno a farsi fottere...
CPU e GPU sono cose diverse, funzionano in maniera diversa, e vanno programmate in maniera diversa. Le librerie non c'entrano una mazza, perchè possono aiutare ma non fare miracoli: alla fine il programma sarà ottimizzato O per la cpu O per la gpu: girerà velocemente solo su una delle due; però, per poter fare questo, mi serve il mio bellissimo switch software: devo scrivere due volte il programma, con TUTTE le conseguenze che ho scritto prima, nessuna esclusa, ma soprattutto, il programma sarà grande il doppio (almeno - algoritmo di esplorazione grafi per p4/cell docet! 1200 linee di codice (cell) contro 60!), userà nei due casi strutture dati in parte differenti, e per poter passare dalla cpu alla gpu bisognerà swappare come dannati e copiare dati su dati da un tipo di struttura all'altra, col rischio di sbagliare, far saltare sincronizzazioni, ecc., ma soprattutto, a mio modo di vedere, si perderebbe ogni vantaggio prestazionale derivante dall'uso congiunto di cpu e gpu.
Provo a fare un esempio (limitato, ma spero chiaro), così forse ci capiamo... Immaginate di avere un'ipotetico computer con due processori: un G4 e un Core2Duo. I programmi sono scritti per ppc, ma grazie a Rosetta riusciamo a farli girare sul core2, e qui quasi quasi ci stiamo, perchè infondo la differenza architetturale non è eccessiva (stiamo parlando di cpu general purpose con logica ooo e tutto il resto), e inoltre la maggiore velocità del Core2 ci consente di surclassare la latenza del jit compiler: fin qui ci abbiamo guadagnato, almeno in apparenza. Però noi vogliamo usare indifferentemente entrambi i processori, quindi dovremo avere sempre a disposizione sia la copia per x86, sia quella per ppc: se il programma è grosso, una parte del codice finirà su disco, quindi bisognerà swappare in continuazione, e sappiamo bene che i page fault si mangeranno tutto il vantaggio di avere due processori e non uno solo. Ma adesso aggiungo un'altra complicazione, così ci avviciniamo un po' di più al contesto che ci interessa (sto cercando di rendere il paragone tra le difficoltà più realistico): diciamo anche che il processore x86 è impostato per lavorare in modalità x86-64. Che succede adesso? succede che saltano un po' di cose... ad esempio, raddoppiano le dimensioni dei puntatori, quindi le strutture dati dovranno essere cambiate... Provo ad essere più preciso: limitiamoci ad un semplice array di puntatori (che può essere la virtual table di un oggetto in c++ oppure un "pezzo" di array multidimensionale), e rendiamoci conto che ogni qual volta sposterò il processo da un processore all'altro, oltre ai problemi relativi al codice (possibili page fault continui) dovrò anche ricreare strutture dati importanti e perdere tempo a ricopiare dati, aggiustandoli ogni volta... Ma allora dove sta il guadagno? Semplice: pensando di usare quella macchina in questo modo non c'è nessun guadagno, anzi...
Ma allora qual'è il modo più intelligente di programmare un'architettura hardware eterogenea, come una macchina dotata di cpu e gpgpu? L'unico modo serio per farlo è capire quale tipo di software (o quali parti del mio software) si adatta meglio alla cpu e quale alla gpgpu, e realizzare il mio software (parti di esso) in modo che sfrutti pienamente o la cpu, oppure la gpu. Entrambe contemporaneamente, non è che non si possa, ma è controproducente, sotto tutti i punti di vista. AMEN!!!!!!!
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.