Confronto fra i486 e Motorola 68000

[fek]

Riporto un post interessante di un tipo che lavora all'Activision e sta studiando il Cell su dei prototipi speditigli da Sony, a quanto ho capito.

When a decision is made in a processor (an if statement) the PC (Program counter) often has to jump to a separate section of the code returning later to the commmon code. This interupts the caching of the instructions as the processor does NOT know where the code is going to jump as this is more often than not data dependant. Modern CPU's have a method they use the predict which branch will be taken. Branch prediction is extremely complex and I won't even try to explain it here BUT I can say that it often hides the caching issues I mentioned. A branch miss results in ALL the instruction cache being flushed and the cpu then starts reading from its new location... X360 HAS branch prediction on ALL its cores thus ofimes it avoids this flush. Ps3 has it only on the PPE - the spe's have ZERO branch prediction but CAN be given hints by the programmer as to which branch might be taken... this is NOT as fast as full branch prediction AND it takes longer to program. Code can be designed around this problem and no doubt it WILL be .... but it takes longer.

Futher - the spe's rely upon a LOCAL area of memory (256Kb) to store both the data they use during calculations AND the resuts of said calculations. This data is streamed in by DMA as and when needed and thus needs to be controlled either by itself or the main CPU the DMA is HEAVILY relied upon but AFAIK can only process one request at a time albeit at a VERY fast rate. Now... the DMA reads from a memory address a set number of bytes, each addres+numbytes is a single request.... consider accessing 1,000 vertices... they would normally be stored linearly in memory thus a SINGLE dma request would be used. If you're following me then you know where I'm going... consider the SPE accessing data from 100 different memory addresses in a NON linear fashion; random. Each access would represent a NEW dma, more DMA requests == further delays for ALL spe's.

There is an area of memory that is shared between the SPE's so the above example IS a worst case scenario... but like many things on the cell.. this shared memory is non-trivial and is small thus requiring manangement;more programming.

3. Cell is VERY good with large datasets requiring linear access and having a relatively simple code pathway - lighting, vertex transform, A* pathing (if designed properly), Character skinning, texture processing, animation. However to get the most out of it each will require its own specific handling and design around the SPE limitations and DMA request optimisation.

4. Information on RSX is sketchy at best... they have said 100B shader ops but haven't told us much else. It will be fast, it will be able to run most if not all the things that the ATI part in X360 will run. It DOES NOT use the same language - more work required.

5 X360's CPU == 240 Gflop with 1 thread per core, Ps3 CPU == 218 Gflop - TOTAL when you ADD the 2 threads running on the PPE... if we take the same standpoint as sony.... X360's CPU is 480Gflops... thats >2XPs3.... we just need the numbers on the GFX Cards."

"
note - "IF we take the same standpoint as Sony" in that - Sony in their comments regarding the STATS on the cell HAVE ADDED THE NUMBERS across the board in order to reach the 2.18 TFLop, they have added 2 threads on the ppe and dual issue on teh spe's.... it was MEANT to show people what the x360 numbers come out to WHEN we use the same "technique" as sony.

and - you say that it shouldn't be much more difficult than ps2 - hmm.. that puts MOST things at around 5x programming time over x360 - thanks for backing me up.

regarding branch prediction NOT being an issue - go to the cell docs IF you have them (anyone else who has them can back me up here)

/cell/0_3_0/documents/hardware/BE-Overview_e.pdf
in that pdf go to SPE->SPU Performance Characteristics and READ the section on BRANCH PREDICITION AND WHY ITS IMPORTANT.

Dice piu' o meno le stesse cose che ho detto, ma in maniera decisamente piu' corretta ed approfondita di quanto ho fatto io.

[jappilas]

MOLTO interessante... e mi ha tolto una perplessità su cui stavo per chiederti lumi...

[fantoibed]

Io trovo più interessante questi:
http://www.research.ibm.com/people/m.../2002_wced.pdf
http://www.research.ibm.com/people/m...rs/2001_tc.pdf
http://www.research.ibm.com/vliw/isc...timization.pdf

...Dove vengono mostrati i vantaggi di una traduzione e ottimizzazione dinamica via software su architetture in-order rispetto ad un branch prediction hardware su architetture OOO.

L'autore non è un tizio dell'Activision ma:
http://www.research.ibm.com/people/m/mikeg/

Dr. Gschwind is one of the originators of the STI CELL Broadband Processor Architecture and was a member of the joint architecture exploration and definition team. He was also the leading architect of the SPU architecture and the instigator of its compiled code SIMD focus. Dr. Gschwind was the developer of the first compiler targeting the BPA. His leadership and technical contributions to the S/T/I project were recognized as IBM Research Achievement Award.

Dr. Gschwind has also been a leading contributor to future PowerPC enhancements used by a Microsoft and a variety of IBM OEM customers and one of the lead architects for the BOA Binary Translation and Optimzation Architecture, an IBM PowerPC implementation based on advanced dynamic compilation techniques.

[MadRat]

Originariamente inviato da fantoibed

Sinceramente non sono convinto che lo spostamento dall'hardware al software dei sistemi di esecuzione out-of-order, branch prediction, register renaming, speculation, delle varie tecniche per ottimizzare il parallellismo ILP e TLP (tipo hyperthreading), ridurre la latenza, eccetera...............


....mi rendo conto che il discorso potrebbe aprire molti filoni e, vista anche la carenza di informazioni, resta moooolto "fumoso". Visto anche che siamo OT qui e che ci sono molti thread aperti in cui si parla di TheCell, perchè non ci accodiamo a qualche altra discussione o, ancor meglio, perché non apriamo su "Processori" un thread tipo "The Cell - il thread ufficiale" o qualcosa del genere?

Concordo con te in quasi tutto.. L'unica cosa che non ritengo logica e' l'apertura di un thread dedicato al cell.. perche'?? perche' sono d'accordo con te su cio' che hai detto!! e dunque ritengo che ci siano troppe poche informazioni al suo riguardo e troppi inutili thread gia' aperti.

[MadRat]

Originariamente inviato da fek

E questo layer che cosa dovrebbe fare? Analizzare

Io credo che in informatica esistano degli strumenti ed ogni strumento serve per uno scopo. Il Cell e' evidentemente nato con lo scopo di essere un velocissimo streaming processor, un dsp intelligente, veloce, e poco costoso.
Forzarlo a diventare un general purpose, qualcosa che non e' stato progettato per fare, sarebbe altamente inefficiente rispetto all'uso di quei transistor con lo scopo di risolvere un'altra classe di problemi. Qualunque archiettura software si possa immaginare non aiuterebbe.

Il cell non e' mai stato dichiarato come streaming processor. Almeno non mi risulta. Forse qualcuno (forse pazzo) lo considera anche in grado di operazioni GP, magari con un'implemetazione software simile a quella ipotizzata da fantoibed.
Chi vivra' vedra'.

[fantoibed]

Originariamente inviato da MadRat

Concordo con te in quasi tutto.. L'unica cosa che non ritengo logica e' l'apertura di un thread dedicato al cell.. perche'?? perche' sono d'accordo con te su cio' che hai detto!! e dunque ritengo che ci siano troppe poche informazioni al suo riguardo e troppi inutili thread gia' aperti.

Riguardo al fatto che la discussione su Cell non è inerente il topic hai ragione al 100%, ma ormai la frittata è fatta....

Riguardo al sostegno morale a chi sostiene l'una o l'altra tesi (non sto accusando te, ma parlo in generale), trovo più stimolante confrontarmi con uno che la pensa diversamente da me piuttosto con chi mi da ragione. Solo con un confronto (purché sia una discussione civile come questa senza provocazioni, battutine, offese, ecc...) vengono alla luce gli errori o le imperfezioni dell'una e dell'altra tesi e solo così si sviscera l'argomento.

[MadRat]

Ora volessero perdonarmi lor signori, ma io riprenderei momentaneamente alcune argomentazioni relative al thread!! Poi parliamo anche di pizza, non ho problemi!! (a me piace come la fanno a napoli. )

Originariamente inviato da fek

Anche se metti quel floppy dentro un Mac o un'Amiga, viene letto. Non mi risulta che un Mac sia cosi' simile ad PC degli anni '80

Fai un altro esempio

Ad un ST non succedeva nemmeno nell'85. con adeguati software o SO multitasking, l'accesso al floppy era completamente trasparente.
_________________________________-

Originariamente inviato da cdimauro

Che conferma quello che ho detto sul 68000 e sul 68008: che l'architettura è a 32 bit, non a 16 né a 16/32 bit, come sostenevi tu.

E' una TUA considerazione, non un criterio OGGETTIVO.
.......

Sì, ma è pure sbagliato, come ho già detto: i 680x0 sono fra i processori più semplici da programmare (lasciando perdere i dettagli specifici, che comunque si ritrovano in tutte le architetture), e proprio per questo chi ha avuto modo di lavorarci ne conserva ancora un gran bel ricordo.

Vedi sopra.

Comunque se qualcuno si passerà il capriccio di emulare il Falcon su questi schifosissimi PC, magari potrai finalmente metterlo da parte e continuare a non sbagliare una nota di un 128esimo...

Decisamente ora non ho tutto il tempo necessario a risponderti passo passo. Tuttavia voglio precisare che hai travisato molte cose..

In primo luogo, l'idea che i computer basati su 68000 fossero considerato dei 16 bit (e da alcuni 16/32) e' cosi' mia e personale che il nome ST vuol dire proprio 16/32, (come TT significa 32/32) e le riviste del tempo che li trattavano, portavano come sottotitolo riferimenti al mondo informatico a 16bit..
Ti risparmio decine e decine di siti nei quali si parli di 68000, ST, Amiga, Mac e storia dei computer e processori, nei quali si parla di generazione di computer a 16bit. Poi se ci tieni proprio ti do un po' di link, ma puoi anche cercare da solo su google.


L'emulatore dell'ST su amiga, era un simulatore di desktop limitato nelle funzioni ed incapace anche di far scorrere un mouse con fluidita'. L'hardware dell'amiga era piu' massiccio, non piu' complesso. Molto meno armonioso e bilanciato di quello ST.. Del resto sono nati dalle stesse mani e sono solo due interpretazioni differenti di comuter simili.

Che l'emulatore mac su st girasse a quella velocita' e' risaputo da chi ha usato quelle macchine, addirittura fecero pure un'interfaccia esterna contenente le rom del mac e vendettero (vendemmo, visto che eravamo centro atari ed l'assistenza ufficiale assieme alla sede di milano e torino) molti atari a tutti coloro i quali fossero indecisi tra uno (mac) e l'altro, inquanto la compatibilita' era totale, la velocita' superiore e la risoluzione video anche. Questo e' indice di spueriorita'. Nel caso dell'amiga io parlerei di diversita'.

Seguiti a parlarmi di velocita' di trasmissione della midi.. Il 68000 dell'st programmava solamente l'hardware dedicato alla gestione dma dell'interfaccia midi.. Hai le idee un po' confuse al riguardo, e' ovvio che una simile velocita' di trasmissione sia gestibile con poche risorse. Forse non si tratta solo di quello . E NESSUN programma midi per quelle macchine soffriva di scarsa precisione o rallentamenti, non credo proprio che fossero tutti in assembler!!

Poi mi dici che un falcon senza l'hardware dedicato non saprebbe fare nulla.. IL FALCON SENZA HW DEDICATO NON ESISTE. E' nato superiore/migliore, come se nascesse oggi un computer nuovo, sarebbe superiore/migliore anche (e soprattutto) concettualmente a qualunue architettura gia' inventata.

Seguiti a sostenere che io ritenga i pc odierni simili ad un 386.. non e' vero, so che hanno poco e nulla a che spartire con loro. Ritengo solamente che siano partiti dalla piu' sbagliata delle basi informatiche.

Se non capisci perche' abbia parlato di schede video, te lo rispiego in una riga.
Perche' hanno portato i giochi a 256 colori al grande pubblico, diventando cosi' commerciali e soppiantanto amiga ed st. (grazie a taiwan e non certo alla superiorita' del mondo pc-comp).

Oggi un 68000 farebbe ridere come architettura quanto un 2/386.. Un evoluzione di questo (68000) sarebbe notevole e porterebbe con se i propri "difetti, nella stessa misura rilevata con gli x86.
Come capisci bene e ci tieni a precisare, che i processori di oggi poco c'entrino con un 386, dovresti intuire che la stessa qualita' evolutiva avrebbe coinvolto qualunque altra cpu al posto delle x86, ma come giustamente dici tu, sono solo dei se.

Metto un'ultima piccola aggiunta riguardo ad Halo..
Questo non dimostra cio' che sostieni tu, dimostra soltanto che (come sostengo da sempre) un hw dedicato e non soggetto a cambiamenti sia piu' "spremibile" ed a parita' di HW una console rispetto ad un pc e' piu' efficiente. Da qui i problemi a far girare Halo decentemente su pc di faccia bassa.. molto bassa direi.Per non parlare di doom3!!. Politica per altro anticonsumistica, perche' credo che comuqnue piu' o meno TUTTI i giochi principali per pc, potrebbero girare meglio se affinati nella programmazine.
Poco tempo fa lessi un commento di non ricordo chi, che analizzava il codice di unreal (e o di far cry), mostrando la quantita' di righe inuliti e pesanti presenti.

Comunque se non erro prima sostenevi che il 68000 manderebbe al manicomio chiunque ed ora sostieni che sia piu' semplice di un x86. Forse mi e' sfuggito qualcosa.
Non puoi dire prima una cosa e poi un'altra diversa, altrimenti dimostri di non avere adeguate conoscenze o di non avere un'idea precisa di ciò di cui stai parlando. (questa frase l'ho gia' sentita..)


Dici che il dsp 56001 sia in grado di eseguire instruzioni gp.. non piu' di un qualunque altro dsp (cell docet).

Per quanto riguarda la corsa alle frequenze di AMD, vorrei farti notare come sia rimasta intorno ai 2ghz per quasi due anni.

P.S.
Fallo tu un emulatore del Falcon se pensi sia possibile. Per ora non ci riesce nessuno ed in ogni caso avrebbe gli stessi rallentamenti del vst in fase di forti carichi ide.
Comuqnue non sarebbe una soluzione per me, perche' il cubase audio non e' mai stato sprotetto bene, le versioni pirata crashano che e' una bellezza ed il mio ha la chiave di protezione hardware!!

[MadRat]

Originariamente inviato da fantoibed

Riguardo al fatto che la discussione su Cell non è inerente il topic hai ragione al 100%, ma ormai la frittata è fatta....

Riguardo al sostegno morale a chi sostiene l'una o l'altra tesi (non sto accusando te, ma parlo in generale), trovo più stimolante confrontarmi con uno che la pensa diversamente da me piuttosto con chi mi da ragione. Solo con un confronto (purché sia una discussione civile come questa senza provocazioni, battutine, offese, ecc...) vengono alla luce gli errori o le imperfezioni dell'una e dell'altra tesi e solo così si sviscera l'argomento.

Ragionissima.. Ma per me qui si puo' parlare tranquillamente anche di cell.. ovviamente tenendo presente che nessuno dei sottoscritti abbia ancora mai avuto l'onore di programmarlo e/o utilizzarlo. Insomma, mi irrita un po' l'arroganza di chi sostiene con estrema fermezza delle tesi riguardanti l'efficacia di un qualcosa che non ha mai provato.

Se ne puo' parlare facendo ipotesi, illazioni.. non le si puo', pero', porre come punti fissi e pretendere che gli altri ragionino basandosi su di essi.

A parer mio il Cell, se ben programmato distruggera' il trialcore del 360 anche in GP.
Continuo a sostenere che quanto ipotizzato da fantoibed (17-06-2005, 22:09 ) nell'ultima parte del post, sia alquanto probabile, magari e' proprio in base a questo che Sony dichiara grandi capacita' di GP per il Cell.

C'e' da considerare anche, quanto veramente servira' l'utilizzo degli altri core in qualita' di GP-cpu ed ancora non possiamo saperlo.

[fek]

Originariamente inviato da MadRat

Il cell non e' mai stato dichiarato come streaming processor. Almeno non mi risulta. Forse qualcuno (forse pazzo) lo considera anche in grado di operazioni GP, magari con un'implemetazione software simile a quella ipotizzata da fantoibed.
Chi vivra' vedra'.

Sicuro?

A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Direttamente dal sito IBM:
http://www-306.ibm.com/chips/techlib...256FC00074A13A

[fek]

Originariamente inviato da fantoibed

L'autore non è un tizio dell'Activision ma:
http://www.research.ibm.com/people/m/mikeg/

E' il tizio che lo ha disegnato, ti pare che avrebbe detto: "No guardate, ho progettato un'architettura in-order che va piu' piano nel general purpose di una out-of-order"?

Almeno le parole che ho riportato sono di qualcuno che ha messo le mani sull'hardware e sembra avere un po' di esperienza di programmazione a riguardo.

[fek]

Originariamente inviato da fantoibed

Io trovo più interessante questi:
http://www.research.ibm.com/people/m.../2002_wced.pdf
http://www.research.ibm.com/people/m...rs/2001_tc.pdf
http://www.research.ibm.com/vliw/isc...timization.pdf

...Dove vengono mostrati i vantaggi di una traduzione e ottimizzazione dinamica via software su architetture in-order rispetto ad un branch prediction hardware su architetture OOO.

Quegli articoli parlano di compilazione Just In Time, e riportano esplicitamente che la traduzione viene effettuata al momento della prima esecuzione e poi conservata per ammortizzarne il costo. Nessuno nega che sia una buona idea in generale (.NET si basa proprio su quel principio), ma ancora non e' stato dimostrato sul campo che sia piu' efficiente mentre e' dimostrato che lo e' meno. .NET viaggia a circa il 90% dell'efficienza di codice precompilato, perche' soffre dei problemi di cui abbiamo gia' parlato, il fatto che il profilo di esecuzione del codice dipende non solo dal codice eseguito, ma da quando e' eseguito e dai dati sui quali e' eseguito, cosa che nessun compilatore JIT e' in grado di prevedere, ma che solo un'architettura OOO e' in grado di analizzare fino ad un certo punto.

Inoltre non riportano alcun dato pratico, parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare

Tanto e' vero che AMD e Intel dicono l'esatto contrario ed esaltano le architetture OOO e fino a questo punto hanno ragione loro, perche' nel campo delle prestazioni General Purpose a parita' di transistor sono al top e si sono lasciati indietro i Power PC. All'atto pratico non c'e' alcuna architettura in-order in circolazione veloce come le architetture out-of-order a parita' di transistor e questo e' l'unico dato che conta.

Ripeto, parlo di applicazioni GP qui

[fek]

Originariamente inviato da MadRat

A parer mio il Cell, se ben programmato distruggera' il trialcore del 360 anche in GP.

Questo e' decisamene fuori da ogni logica visto che si parla di un solo core GP nel Cell contro 3 core GP nel 360. Per quanto possa pilotare bene Schumacher con una Fiat Punto non andra' mai piu' veloce di un pilota su una Ferrari. E nel GP la differenza fra le due CPU non e' tanto lontana da quella fra una Punto ed una Ferrari.

[fek]

Ok, il paragone Cell/X360 e Punto/Ferrari e' un po' esagerato, ma rende l'idea

C'e' un consenso abbastanza diffuso fra gli sviluppatori sul fatto che il Cell abbia un deciso vantaggio sui calcoli in floating point e l'X360 nei calcoli GP.

[fantoibed]

Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III

Originariamente inviato da fek

Inoltre non riportano alcun dato pratico, parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare

...Questo è la tua traduzione della parte sopra?

A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

riportano esplicitamente che la traduzione viene effettuata al momento della prima esecuzione e poi conservata per ammortizzarne il costo...

Con questo di riferisci all'ottimizzatore dinamico?

[fek]

Originariamente inviato da fantoibed

...Questo è la tua traduzione della parte sopra?

Non letterale. Il concetto e' comunque chiaro.

Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

Ovviamente una memoria locale non puo' essere un processore.

Con questo di riferisci all'ottimizzatore dinamico?

No, al JIT.

[fantoibed]

Originariamente inviato da fek

Non letterale. Il concetto e' comunque chiaro.

Non è letterale e non è nemmeno una traduzione, direi piuttosto una mistificazione... Chi ha scritto il paper non si è preso la responsabilità di un simile paragone, ma si dice "Transmeta claimed..." e poi "about the same" non significa "va più piano". Se il Pentium-III 500 andasse molto più veloce del Crusoe 667 l'errore sarebbe di Transmeta e non di chi ha scritto quel paper. Dico "se", perché ci sono benchmark che dimostrano che tale affermazione non è poi così campata in aria come vorresti far credere:
http://www.geocities.com/crusoeVpent...omparisons.htm

Originariamente inviato da fek

Ovviamente una memoria locale non puo' essere un processore.

...E soprattutto che si stanno parlando del SPE e non di Cell, quindi nella frase che hai riportato è il SPE ad essere definito "stream processor", non il Cell.

Originariamente inviato da fek

No, al JIT.

Chi se ne frega del jit? Parliamo dell'ottimizzatore/traduttore dinamico!

[fek]

Originariamente inviato da fantoibed

Non è letterale e non è nemmeno una traduzione, direi piuttosto una mistificazione...

Quando ci si mette a sindacare parola per parola per il solo gusto di farlo, per me la discussione finisce. Il concetto era chiaro, nessuna mistificazione.

...E soprattutto che si stanno parlando del SPE e non di Cell, quindi nella frase che hai riportato è il SPE ad essere definito "stream processor", non il Cell.

Le SPE usano l'80% dei transistor del Cell. Anche qui si vuole sindicare parola per parola quando il concetto e' chiaro.

Chi se ne frega del jit? Parliamo dell'ottimizzatore/traduttore dinamico!

No, perche' non esiste. Quei paper parlano solo di JIT. Stai parlando di fantomatica ottimizzazione dinamica da tre pagine, ma e' solo una tua invenzione/speranza della quale non parla nessun altro, si parla sempre e solo di JIT.

Stiamo girando in tondo, per me il discorso e' chiuso. Sicuramente non ne sei convinto, ma a quanto ho capito la tua e' piu' che altro solo una speranza non fondata su alcun dato tecnico visto che hai piu' volte travisato anche cio' che tu stesso hai postato e mi sembra tu stia andando avanti piu' per il gusto di contraddirmi anche sui singoli termini che per vero interesse.

Penso di aver dimostrato i miei punti al di la' di ogni ragionevole dubbio, e tutto quello che hai postato li ha confermati, chiunque laovora ne settore conferma piu' o meno quello che ho scritto, non ritengo necessario aggiungere altro.

Ti lascio l'ultima parola.

[fantoibed]

Originariamente inviato da fek

Quando ci si mette a sindacare parola per parola per il solo gusto di farlo, per me la discussione finisce. Il concetto era chiaro, nessuna mistificazione.

La tua traduzione dice qualcosa di completamente diverso da quello che viene detto nel testo originale. E' proprio il senso del discorso ad essere storpiato e lo sai benissimo.

Originariamente inviato da fek

Le SPE usano l'80% dei transistor del Cell. Anche qui si vuole sindicare parola per parola quando il concetto e' chiaro.

Quindi la mia macchina è solo una scocca con un motore perché questi 2 elementi pesano l'80% del peso complessivo della macchina?

Il Cell dovrebbe avere circa 250milioni di transistor (o giù di lì). Ogni SPE ha 7 milioni di transistor + 14 milioni per la sram locale e anche se fossero di più non è corretto attribuire ad un processore una frase in cui si parla solo di un componente di tale processore.

Originariamente inviato da fek

No, perche' non esiste. Quei paper parlano solo di JIT. Stai parlando di fantomatica ottimizzazione dinamica da tre pagine, ma e' solo una tua invenzione/speranza della quale non parla nessun altro, si parla sempre e solo di JIT.

Certo il titolo del primo documento è "Inherently Lower Complexity Architectures using Dynamic Optimization". Già il titolo è eloquente.
Nelle pagina di "Michael Karl Gschwind" http://www.research.ibm.com/people/m/mikeg/ riportano:
Dynamic compilation. Michael Gschwind is a member of the DAISY group which performed ground-breaking work in the field of binary translation and dynamic optimization. Michael Gschwind has been a leading contributor to BOA, the Binary translation and Optimization Architecture, which was a joint project with IBM Server group.

[MadRat]

Originariamente inviato da fek

Ok, il paragone Cell/X360 e Punto/Ferrari e' un po' esagerato, ma rende l'idea

C'e' un consenso abbastanza diffuso fra gli sviluppatori sul fatto che il Cell abbia un deciso vantaggio sui calcoli in floating point e l'X360 nei calcoli GP.

Io non vedo l'ora di vederli all'opera.. c'e' da dire che SICURAMENTE, se non coadiuvato da qualche formula d'utilizzo (tipo quelle ipotizzate qui in precedenza), il Cell perdera' dal punto di vista GP. Vincendo in atri segmenti (FP).
Quello che intendo dire pero', e' che il divario tra la potenza GP del processore del 360 e quella del Cell e' sì notevole, ma assolutamente non si paragona alla differenza che possono fare gli altri core del Cell nei loro segmenti di calcolo. Per tanto a parer mio, le due cpu "quasi" si equivalgano, anche se alle fine direi che siano semplicemente "differenti".
Ritengo che le possibilita' del Cell, previa buona programmazione, potrebbero essere decisamente piu' alte. Mi riferisco al fatto che, se da una parte e' ipotizzabile l'utilizzo GP dei core del Cell, non lo e' altrettanto un eventuale utilizzo efficace del trialcore come DSP.
Spero di esser stato chiaro.
Insomma, credo che il Cell sia piu' legato ad un buon sotware, ma decisamente piu' flessibile e potente.

[MadRat]

Originariamente inviato da fek

Sicuro?

A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Direttamente dal sito IBM:
http://www-306.ibm.com/chips/techlib...256FC00074A13A

Questo dimostra solo che il cel sia un ottimo stream processor.. Non vedo dichiarazioni cosi' palesi.
Io non ho mai detto che non sia un potente stream processor.