SpursEngine dimostrato al CEATEC

[xeal]

Una cpu x86 è compatibile solo con se stessa, proprio perchè ha praticamente lo stesso istruction set da quando sono nati gli x86: non è come un processore con una sua isa specifica "costretto" a eseguire codice non nativo (come itanium o i transmeta rispetto al codice x86 emulato). La complessità di alcune parti del processore e la natura per certi versi ibrida cisc-risc ne sono in realtà il punto di forza. L'unità di esecuzione interna "risc-like" ha la funzione di velocizzare l'esecuzione del codice cisc proprio di un x86, ma non la si può considerare come una specie di emulazione, bensì rimane una implementazione nativa, perchè il set delle microop esiste in funzione del set x86, è pensato, studiato, progettato, come l'unità di esecuzione interna, in funzione del set "esterno", esiste in funzione di esso, per implementarlo in maniera ottimizzata (per eseguire velocemente le istruzioni, mascherare la complessità - e quindi le eventuali latenze - del decoder, ecc. ), ed esiste in sua funzione. Detto altrimenti, non potremmo prendere una cpu x86 attuale, togliere tutta la presunta compatibilità con il passato e ottenere una cpu migliore, perchè non è semplicemente una questione di retrocompatibilità, ma di progetto: non è pensata per eseguire codice diverso da quello x86 tradotto in microop (cosa che è inevitabilmente diversa dal pensare di avere a che fare con le sole micoop, quando vai a progettare il processore), quindi per ottenere una cpu "completa" e "stand-alone" bisognerebbe reingegnerizzare il tutto, creando qualcosa di profondamente diverso, dalle prestazioni ignote e presumibilmente più difficile da programmare. D'altro canto, le tanto blasonate cpu PPC, sono risc nel nome, ma nei fatti hanno un'architettura complessa, un set di istruzioni veramente molto esteso (anche più degli x86), e sono implementate all'interno allo stesso modo, con un'unità di esecuzione "ancora-più-risc". Se entrambe le filosofie sono finite per convergere sullo stesso tipo di implementazione, evidentemente si tratta di una implementazione vincente, altro che zavorra... Per il resto, la complessità di un x86 è legata principalmente alla logica ooo, al branch predictor ecc. che ne sono il punto di forza nel general purpose, perchè la stessa complessità in un RISC "puro", come per certi versi è il CELL, ricadrebbe per intero sulle spalle del programmatore, rendendone il lavoro particolarmente ostico, prova ne sia l'algoritmo di esplorazione di un grafo adattato e ottimizzato da un gruppo di ricerca, che dalle circa 60 linee di codice in C, tranquillamente eseguibili decentemente su un x86 (e diciamo che, ottimizzato per tirare fuori da un x86 il massimo delle prestazioni, a stare larghi, non supererebbe le 200), è passato a oltre 1200 linee, con molte parti in assembly e, nel complesso, a detta degli stessi ricercatori, praticamente illegibile.

Il problema principale del cell non è la difficoltà nel creare algoritmi fortemente paralleli, ma la sua natura, che restringe notevolmente il cerchio degli algoritmi "papabili" e il tipo di parallelismo ottenibile. Una SPE, non è un vero "core", ma piuttosto un grosso DSP, o uno stream processor: non va bene per elaborare blocchi di dati logicamente indipendenti, ma invece per istruzioni identiche su grossi blocchi di dati continui. Guardacaso, le applicazioni multimediali (elaborazioni di suoni, immagini, video) richiedono operazioni ripetitive su grandi moli di dati organizzati in memoria in maniera continua (contrariamente alle strutture dinamiche sparpagliate in memoria ed elaborate, ad esempio, nel rendering). Per tutto il resto, anche pensando di sfruttare poche spe, bisogna fare i salti mortali (senza addentrarsi, poi, nelle difficoltà che possono sorgere nella gestione del local storage di una spe, specialmente per strutture dati variabili).

Ma veniamo al test in oggetto: trattandosi dell'elaborazione di un modello tridimensionale, non dovrebbe essere esattamente "pane per i denti" di un cell, a meno di fare i salti mortali, e sono sicuro che un solo cell completo, con le sue 8 spe e una ppe general purpose castrata (per volontà di progetto) avrebbe avuto non poche rogne, rispetto già al solo dual core intel. Tuttavia, molto probabilmente l'algoritmo implementato sarà già nativamente ottimizzato per l'elaborazione simd, e il dual core general purpose, che comunque viene sfruttato, benchè notevolmente sgravato del carico di lavoro, suppongo abbia il compito non secondario di occuparsi degli accessi in memoria e della preparazione dei dati da dare in pasto alle spe del coprocessore, che in tal modo se li ritrova "belli e pronti" da elaborare nel modo che gli riesce più congeniale.

[anti]

chiaro?

[filippo1974]

Chiarissimo, grazie :-)

Ciao
Filippo

[scoppy]

che bello, a qualcuno potrebbe venire in mente di emulare sulle 4 spu una AGEIA PhysX