Link alla notizia: http://www.hwupgrade.it/news/cpu/14532.html

Eseguendo 48 flussi video MPEG2 contemporanei, Toshiba ha mostrato la ptenza elaborativa della propria tecnologia Cell

Click sul link per visualizzare la notizia.

Questo processore mi fa paura! (nel senso buon del termine)
Mi piaceebbe molto un raffronto con i pentium e gli athlon.
Ma sapete se, teoricamente, può essere usato su pc normali?
Dallo screenshot, sopra che sia stato usato windows media player.

Potentissimo.....
Mi sa che AMD e Intel dovranno darsi da fare, nel caso Cell "sbarchi" nel mondo Desktop

questa è potenza
48 flusssi mpeg2 tv
allora per riprodurre un flusso mpeg2 in standard tv 704x576
serve almeno un pentium III 300 Mhz
300x48=14 Ghz
so che non sono comparabili ma fa effetto :)

questo cell sembra davvero interessante :)

Non sono pro amd o intel. Con il PC lavoro quindi ...
Ma se potessi mettere un Cell nel mio PC lo farei immediamente ... (e chissa' quanto potrebbe costare un processore Cell, una mobo adatta, memorie adatta , scheda video adatta (nvidia) etc etc ... )

beh sembra che usino media player per la riprosuzione 10 :confused: ma questi proci non hanno architettura ne x86 ne x86-64 :mbe: come è possibile che usino media player :what:

ad ogni modo sembra che questa architettura sia qualcosa di spettacolare :sbav: pensate a un pc con quel procio (8 core :D) ci sarebbe da divertirsi ;)

news old

È ovvio che il video è stato registrato sulla piattaforma di test.
Usano WMP solo come player per avere una maggior portabilità.

8 processori integrati e OS dedicato in specifico... non mi sembra che sia niente di sbalorditivo nelle prestazioni ottenute....

Apparte che ne usano 'solo' 7 :)
Ma sono più di 6 stream per processore, ma che volevi un Earth simulator tascabile ? :D

Vorrei solo puntualizzare una cosa... quelli non sono normali flussi mpeg2, ma flussi video HD 1080.... tanto per capirci un P4 2.5Ghz riesce a malapena a farne girare uno decentemente. Se provate a lanciarne due addio, il PC vi chiederà pietà.
Quindi il raffronto fatto da eta_beta non è esatto, diciamo che in quella configurazione e con quel tipo di applicativi multimediali, quel Cell rende circa come 48 P4 a 2.5Ghz.
Dire che è un mostro è poco... certo è che sulla PS3 non monteranno quello, ma una versione più castrata... comunque mostruosa.

come fanno ad usare wmp se

"Per la dimostrazione, Toshiba ha sviluppato un ambiente operativo specifico per poter sfruttare al meglio le potenzialità dell'architettura Cell."

l'interfaccia grafica è simile ma nn è lui!!

@coyote
"La dimostrazione è consistita nella riproduzione simultanea di 48 flussi video MPEG2 Standard TV. I flussi sono stati proiettati su un televisore HDTV a risoluzione di 1920x1080 pixel"

in italiano significa ke il monitor su cui sono stati proiettati ha la risoluzione 1920x1080...mentre i flussi video sono di tipo MPEG2 Standard TV cioè ris. 720x480

io ho letto che questo processore riesce a fare 250 Gflop/s... un P4 o Athlon, quanto fanno?

"La dimostrazione è consistita nella riproduzione simultanea di 48 flussi video MPEG2 Standard TV"
MPEG2 Standard TV
MPEG2 Standard TV
MPEG2 Standard TV
MPEG2 Standard TV
il proiettore e HDtv 1080i
dividendo lo schermo in 8 celle in orizzontale e 6 celle in verticale
in formato tv 720x480 si ottine 5760x2880
un a unita ridimensiona da
5760x2880 a 1920x1080
un singolo processore dei 6 svolge 8 flussivideo
quindi 2880x 960

@reptile9985
Lascia perdere quello che riporta HWUpgrade... la notizia ufficiale riporta che i flussi video erano in HD 1080, se proprio non ricordo male. Potrebbe però anche essere che ho preso una cantonata... converrebbe controllare.

Il processore per decodifica video che è dentro al mio cellulare è molto più potente di un pentium da 3GHz, peccato che il processore del cellulare sa solo fare decodifica mentre il pentium (o altro processore) sa fare di tutto + o - "bene".
Questo è un processore "multimediale" ad elevata specializzazione che va bene a fare poche cose tra l'altro con un s.o. scritto ad hoc, in un PC non lo metterei mai, al massimo dentro ad una console, un HTPC o un chiosco multimediale!

@Freeride
Guarda che quel procio non è studiato solo per la multimedialità, ma anche per ben altro... non per niente sarà il cuore della PS3 e la Sony ha annunciato l'utilizzo di tale processore per i suoi server. Altro che il chip del tuo telefonino. Il top di gamma dei Cell è stato valutato spingere fino a 1 TFlop/s (dato da prendere un po' con le molle, ma anche ridimensionandolo drasticamente fa paura).

Bella dimostrazione.
Ma parliamo pur sempre di 8 processori che lavorano assieme e quindi non griderei al miracolo. ;)

@Freeride
Guarda che quel procio non è studiato solo per la multimedialità, ma anche per ben altro... non per niente sarà il cuore della PS3 e la Sony ha annunciato l'utilizzo di tale processore per i suoi server. Altro che il chip del tuo telefonino. Il top di gamma dei Cell è stato valutato spingere fino a 1 TFlop/s (dato da prendere un po' con le molle, ma anche ridimensionandolo drasticamente fa paura).
Se è la stessa IBM che con la tecnologia Cell vuole far un processore staccato dalla classica filosofia "one size fits all" tipica dei processori da PC (vedi P4 o Athlon) e usarlo per applicazioni embedded (vedi console, htpc,...) fai un po' te.
Il chip da 2 euro del mio telefonino realizzato per fare una singolo compito ha più flops di un processore da 3Ghz general pourpose, anche se in questo caso sarebbe meglio parlare di mops.

Il procio è uno solo con 8 core... il modello di punta dovrebbe averne 16 di core. E un po' come i nuovi processori Intel e AMD con doppio core, che comunque restano sempre e solo un processore. La tecnologia applicata sul Cell però è profondamente diversa da quella di Intel e AMD.

@Freeride
OK, ma questo non significa che faccia girare solamente flussi audio-video come il chip del tuo telefonino. Se la Sony ha intenzione di usarli nei server vuol dire che il campo di utilizzo e di potenza è vastissimo.

"Degli 8 procesori SPE "

Altro errore di battitura ...
la fretta, brutta cosa.

Comunque impressionante

Bene, assodato che posso guardarmi in preview tutti quei canali contemporaneamente, poi cosa me ne faccio?
Ok potenza mostruosa ma per me pincopallino che nemmeno la guardo la tv, ci saranno altri applicativi dove dimostrare tutta questa fantascienza, o no?

Ma non potevano farmi il rendering in tempo reale di qualche film di animazione? Con tutta quell'immane potenza dovrebbero riuscirci senza troppe difficoltà...

Tornando seri, dubito fortemente che questo Cell sia la rivoluzione che tutti auspicano, a tutt'ora di concreto si è visto molto poco, giusto qualche dato campato in aria per mantenere alto l'hype... Nessuno gli vieta di poter essere una soluzione innovativa, anche se non è un progetto completamente nuovo...

@Freeride
OK, ma questo non significa che faccia girare solamente flussi audio-video come il chip del tuo telefonino. Se la Sony ha intenzione di usarli nei server vuol dire che il campo di utilizzo e di potenza è vastissimo.
Cell gestisce magnificamente tutti quei flussi di dati che sono facilmente "vettorizzabili", audio, video, grafica, trasformate veloci,...
Devono ancora spiegarmi bene come si risce a vettorizzare un database da far girare su un server!
Forse perchè la tecnologia cell e' alla fine un unico chip contente tante GPU gestite da una CPU con una ottima interfaccia di memoria ...ma allora il server lo tiene su solo la parte CPU, praticamente un powerpc ibm!

E' come fare calcoli via DirectX su di un GPU potente, sono n volte più veloci che farli sulla CPU di sistema peccato che non tutti i tipi di calcolo siano rappresentabili su di una GPU.

....televisore PRO beta... 1 secondo in formato HD= 100 megabite mininoi al secondo.... fate voi le conclusioni.....azzo che telefonini ci sono in giro!!!! .... in editing con un HD da 2 minuti un AMD FX 55 mi si è piantato sempre.... a rifate Voi le logiche conclusioni!!!!!!.

Ciao

Giuliano

SE come avevo letto un P4 2.4 Ghz riesce a farne uno.
48 flussi * 2.4Ghz= 115.2 Ghz/8 processori= 14,4Ghz :sbavvv:

Quoto chi dice che queto "procio" ha funzioni limitate,ma quelle poche funzioni che ha....... :eekk: :eekk:

Questo processore mi fa paura! (nel senso buon del termine)
Mi piaceebbe molto un raffronto con i pentium e gli athlon.
Ma sapete se, teoricamente, può essere usato su pc normali?

Sui PC no, ma sui Mac probabilmente sì :D

Il procio è uno solo con 8 core... il modello di punta dovrebbe averne 16 di core.

In realtà di core il prototipo attuale ne ha 9: 8 vettoriali (SPE) e uno PowerPC (PPE). Quest'ultimo è dual-thread, quindi il chip da un OS è visto essere composto da 10 processori.

SE come avevo letto un P4 2.4 Ghz riesce a farne uno.
48 flussi * 2.4Ghz= 115.2 Ghz/8 processori= 14,4Ghz :sbavvv:

Quoto chi dice che queto "procio" ha funzioni limitate,ma quelle poche funzioni che ha....... :eekk: :eekk:

Un Geforce 5700 in alcuni tipi di calcolo vettoriale è equivalente ad un P4 a 10 GHz.
Se riempi una "CPU" di piccole GPU e usi le GPU per fare i calcoli che dovrebbe fare la CPU... vai da Dio!

Il grosso problema è che non tutti i tipi di operazioni possono essere ricondotti a rappresentazioni vettoriali.

....televisore PRO beta... 1 secondo in formato HD= 100 megabite mininoi al secondo.... fate voi le conclusioni.....azzo che telefonini ci sono in giro!!!! .... in editing con un HD da 2 minuti un AMD FX 55 mi si è piantato sempre.... a rifate Voi le logiche conclusioni!!!!!!.

Con le dovute proporzioni. Un codifica mpeg che un processore generico da 3Ghz ti fa a fatica un processore da 100 MHz progettato solo per fare quello te la fa in tempo reale consumanto 1/100.

Qualcuno arriva e costruisce un processore 10 volte meglio di Intel o Amd?
Ho l'impressione che ci sia un pò di gente che crede in babbo natale.

Qualcuno arriva e costruisce un processore 10 volte meglio di Intel o Amd?
Ho l'impressione che ci sia un pò di gente che crede in babbo natale.

Beh stiamo parlando una joint venture di tre colossi come IBM-SONY-Toshiba che ha avuto uno sviluppo di 4-5 anni e un investimento di 2-3 miliardi di dollari, includendo la costruzione delle 3-4 nuove fabbriche costruite o radicalmente rinnovate solo per produrre il Cell.

Non è che un pischero si è alzato una mattina e si è messo a fare un nuovo chip per sport.

Questa è la più grande sfida al monopolio Wintel che ci sia mai stata, nel caso tu non lo abbia notato... IBM si è anche venduta la divisione PC, e non credo sia un caso.

Ottimo esempio di elaborazione parallela, dove posso trovare gli schemi di funzionamento di questo procvessore?

IBM è anche quella che ha creato i PowerPc, processori che dovevano fare il mazzo a Pentium e compagnia bella.....

Sony è il re del marketing, sa ingigantire i dati dei suoi prodotti come nessuno sa fare

Il processore per decodifica video che è dentro al mio cellulare è molto più potente di un pentium da 3GHz, peccato che il processore del cellulare sa solo fare decodifica mentre il pentium (o altro processore) sa fare di tutto + o - "bene".
Questo è un processore "multimediale" ad elevata specializzazione che va bene a fare poche cose tra l'altro con un s.o. scritto ad hoc, in un PC non lo metterei mai, al massimo dentro ad una console, un HTPC o un chiosco multimediale!
Questa bella e che cellulare hai?? magari un nokia 6630 :ahahah:
Diciamo anche che questi telefonini hanno schermi ridicoli!!!

Non mi sembra che con un architettura X86
con sette cpu riesci a gestire 48 flussi mpeg2
con una cpu X86 riesci a gestire al massimo due flussi video

si ma come diceva Freeride questi sono proci con compiti molto specifici, quello che va dentro ad un Desktop pc ha una filosofia e compiti completamente diversi .... la stessa GPU di una scheda video per certi versi è infinitamente + potente di una CPU....

per esempio quel coso finirà dentro alla PS3.... che se la dovrà vedere contro l Xbox 360, il quale suppongo se seguirà la filosofia del suo predecessore sarà un piccolo PC.... li vedremo che reale differenza ci sarà.....

è più pesante eseguire mpeg2 o divx? I filmati con estensione mpg sn mpge2?

Questa bella e che cellulare hai?? magari un nokia 6630 :ahahah:
Diciamo anche che questi telefonini hanno schermi ridicoli!!!
Perchè si ragione come se tutti i processori fossero uguali, abbituati ai classici processori simil-risc da PC.
Metti che il tuo Athlon da 3 Ghz ti fa 1 FFT in 64 clock, un processore da codifica ti fa 16 fft in un clock ...peccato che sa fare solo quello!

le nuove idee arricchiscono sempre il mercato...
oggi il cell con 8 processori vettoriali,
domani software vettorializzati ( c'e' un software che vettorizza i flussi audio e applica filtri in tempo reale tramite le schede video nvidia, e quelli non sono calcoli nativi vettorizzabili),
o CPU a.. "largo spettro": multicore con ogni core altamente ottimizzato per un particolare compito;
ne piu' ne meno che istruzioni particolari come mmx sse e 3dnow, le quali hanno transistor dedicati per svolgere specifiche istruzioni molto velocemente, con il vantaggio che un core logico puo' essere programmato...
forse un piccolo passo indietro al 386+coprocessore matematico..

Piccola precisazione: Cell non è un ASIC (application specific integrated circuit), ma un processore vettoriale. Ha un gran numero di unità FP a 32 che lo rendono adatto alle applicazioni multimediali, ma queste unità sono completamente programmabili, a differenza della maggior parte dei processori dei telefonini, ad esempio.

Non è adatto per gestire database (che richiedono molte operazioni su interi) ma in compenso funziona bene con elaborazione video, rendering, elaborazione del suono, della fisica, di alcune routine di IA, generazione procedurale, sintetizzazione audio etc.
In una presentazione di Cell erano elencate alcune di queste possibilità. L'intenzione di IBM-Sony-Toshiba non è assolutamente quella di introdurre un processore general purpose.

x Morkar: [FANTASCIENZA] secondo me nel mirino di IBM c'è piuttosto il mercato del supercomputing. Sostituendo i MAC 32 delle SPE Cell con MAC 64 hai un processore capace di almeno 250 Gflop teorici (LINPACK) e a 65 nm dovrebbe consumare sui 70 W. Mettine un migliaio insieme e ottieni una potenza teorica doppia rispetto a Blue Gene con consumi e spazio ridotti :D

All'inizio della settimana, in occasione dell'International Solid State Circuits Conference di San Francisco, Big Blue e soci hanno mostrato un prototipo di Cell con una dimensione record di 221 millimetri quadrati: quasi tre volte superiore a quella che oggi caratterizza un tipico processore per PC. C'è tuttavia da considerare che l'attuale prototipo è stato fabbricato con una tecnologia di processo a 90 nanometri, mentre i modelli che arriveranno sul mercato verso la fine dell'anno adotteranno circuiti da 65 nm: questo dovrebbe contribuire a ridurre sia il diametro del chip che i suoi costi di produzione. La "ciccia" del processore è del resto costituita da ben 234 milioni di transistor, quasi il doppio rispetto a quelli contenuti in un Pentium 4 di ultima generazione.

La prima versione di Cell comprende otto unità di calcolo floating point a 64 bit, chiamate Synergistic Processing Elements (SPE), affiancate da una CPU PowerPC capace di eseguire due thread simultaneamente. Ogni singolo SPE ha una dimensione di 2,5 x 5,8 mm, contiene 256 KB di memoria cache ed è in grado di eseguire due istruzioni per ciclo di clock. I core comunicano fra loro per mezzo di un bus FlexIO a 6,4 GHz e con la memoria attraverso un bus XDR (Extreme Data Rate) a 3,2 GHz: entrambi si basano su tecnologie di Rambus e sono gestiti da controller integrati nel chip. Grazie ad un accordo stipulato con Rambus nel 2003, le memorie XDR DRAM che equipaggeranno i dispositivi Cell-based verranno prodotte direttamente da Sony e Toshiba.

Cell dovrebbe consumare intorno ai 30 watt, all'incirca quanto il processore grafico Emotion Engine che equipaggia la PlayStation 2, e fornire una potenza di calcolo paragonabile a quella di un piccolo cluster di server. IBM afferma che il proprio superchip sarà, in molti casi, fino a 10 volte più veloce rispetto ad un tipico processore per PC, inoltre potrà svolgere buona parte dei calcoli oggi demandati alla scheda grafica.

Alcuni prototipi di Cell sono già stati provati alla frequenza di 4 GHz, più o meno lo stesso clock che dovrebbe contraddistinguere i primi modelli commerciali. Secondo indiscrezioni il processore alla base della PS3 funzionerà a 4,6 GHz.

La produzione in volumi dei processori Cell comincerà il prossimo autunno nella fabbrica di IBM sita a East Fishkill, nello stato di New York. La seguirà a ruota Sony con la propria fabbrica di Nagasaki, in Giappone.


IMHO ci dobbiamo aspettare molto da questo processore, non i miracoli ma grandi cose se sfruttato degnamente, si!

si ma come diceva Freeride questi sono proci con compiti molto specifici, quello che va dentro ad un Desktop pc ha una filosofia e compiti completamente diversi .... la stessa GPU di una scheda video per certi versi è infinitamente + potente di una CPU....

Ed anche di un Cell a parti transistor.

Beh stiamo parlando una joint venture di tre colossi come IBM-SONY-Toshiba che ha avuto uno sviluppo di 4-5 anni e un investimento di 2-3 miliardi di dollari, includendo la costruzione delle 3-4 nuove fabbriche costruite o radicalmente rinnovate solo per produrre il Cell.

Non è che un pischero si è alzato una mattina e si è messo a fare un nuovo chip per sport.

Questa è la più grande sfida al monopolio Wintel che ci sia mai stata, nel caso tu non lo abbia notato... IBM si è anche venduta la divisione PC, e non credo sia un caso.

si ma criceto... con 2 o 3 miliardi di dollari intel ci fa una fabbrica, partiamo dal presupposto che non è che amd e intel siano le ultime arrivate o che non facciano investimenti, anzi... basta vedere la guerra che si fanno e quando sono arrivati i dual core rispetto a quando dovevano arrivare secondo le roadmap di 2 anni fa...

il problema come correttamente sottolineato da diverse persone è che cell NON è un processore general purpose. facciamo un parallelo. i mac hanno dei processori che presi di per sè hanno un'efficienza ridotta rispetto agli x86 (non voglio scatenare un flame, ma se andate a verificare le conclusioni vengono da sè) TUTTAVIA grazie ad altivec riescono in alcuni e ben precisi ambiti ad essere comunque competitivi (vedi photoshop) e in altri addirittura molto più peformanti (ad esempio con BLAST). in pratica ad un processore general purpose non particolarmente performante viene accostata una unità vettoriale capace di macinare gflops su gflops: il risultato è una macchina in grado di fare molto bene pochissime cose, discretamente bene poche altre, e le altre diciamo che le fa e basta =)

ora, al di là di tutti i miti e i fantatismi che stanno dietro ai mac, basta andare a vedere sul sito di ibm dove presenta il JS20, un server basato su due processori ppc970 (il g5 per intenderci), è praticamente identico all'xserve di apple, e ibm stessa lo indica come soluzione adatta per il calcolo scientifico, dove in effetti ha prestazioni di tutto interesse (anche se poi non si può generalizzare perchè bisogna analizzare nel concreto che tipo di calcoli svolgi - se i supercomputer li fanno con xeon, opteron e processori particolari ci sarà un motivo - comunque non entriamo troppo nel dettaglio).

cell è l'esasperazione di questo concetto: in realtà il processore general purpose dentro cell c'è, solo che fa davvero schifo :D tuttavia, a fianco di questo ci sono unità "analoghe" ad altivec pompate all'ennesima potenza. con una cpu così di sicuro ci saranno delle applicazioni dove avrai una rivoluzione vera e propria, ma per la stragrande maggioranza dei casi (in particolar modo per l'ambiente desktop) una cpu in grado di fare "un po' tutto bene" come gli attuali x86 continuerà a rimanere la scelta migliore.

tra l'altro, se andate sul sito della spec (www.spec.org) e guardate i risultati del js20 vedrete nel dettaglio grosse differenze tra un test e l'altro, mentre gli x86 sono molto più "regolari", e questo anche se altivec ha un incidenza del tutto marginale (se non nulla): se avesse una forte incidenza il divario tra un test e l'altro sarebbe ancora più marcato. se volessimo fare un paragone automobilistico, si potrebbe dire che gli x86 hanno un'erogazione di coppia molto lineare =)

detto questo personalmente vedrei bene il cell non al posto degli x86 ma come coprocessore vettoriale per gli x86, magari su una schedina pci-x: tra l'altro forse non tutti sanno che già esistono schede con processori vettoriali in grado di far fare al proprio pc un balzo in avanti incredibile per quanto riguarda i GFLOPS... c'è ad es. un processore a 96 core che mi sembra vada a 250 mhz e consumi solo 5 watt in grado di fare 50 gflops: una scheda può montarne fino a due per un totale di ben 100 gflops. non solo: il costruttore prevede la possibilità di installarne fino a 5 dentro un pc, il che significa un totale di 500 gflops per pc! ovviamente queste schede adesso come adesso sono relegate ad ambiti molto specifici e pertanto quasi non si conoscono, tuttavia cell non è niente di innovativo o straordinario: la cosa innovativa è se questo diventa fruibile per le masse. secondo me è un passaggio che anche i pc prima o poi dovranno fare: imho infatti dopo il salto delle GPU il prossimo sarà quello delle VPU, che magari all'inizio saranno usate più che altro per i giochi (vedi Phsyx) ma poi pian piano anche per altri compiti (ad esempio proprio la codifica / decodifica di flussi video).

sinceramente non capisco perchè intel e amd, che fanno cpu molto corpose in termini di transistor, non prevedano l'equivalente di un altivec, che a quanto mi risulta "consuma" solo due o tre milioni di transistor. i vari set di istruzioni SIMD attualmente presenti sugli x86 infatti non sono paragonabili alle capacità di altivec: al posto che fare mmx, mmx2, 3dnow, sse 1 2 e 3, e così via, fatene uno fatto cattivo, no? =)

Mi interessa solo il fatto che non si tratti di architettura x86.
Ogni tanto, cambiare aria stimola la curiosità e la voglia di cimentarsi con cose nuove...

p.s. il Cell ce lo vedrei bene con un sistema operativo del tipo BeOS...

Potentissimo.....
Mi sa che AMD e Intel dovranno darsi da fare, nel caso Cell "sbarchi" nel mondo Desktop
Non è stato pensato e realizzato per un uso desktop, ma il massiccio calcolo parallelo / distribuito.

io ho letto che questo processore riesce a fare 250 Gflop/s... un P4 o Athlon, quanto fanno?
Sono 250GFlops a precisione singola teorici (o di picco).

Un P4 a 3,8Ghz ne fa 15,2, e un AthlonFX-55 (a 2,6Ghz) ne fa 10,5.

Ma sono dati da prendere con la pinza, appunto: con le applicazioni reali è difficile avvicinarsi a questi numeri.

Mi interessa solo il fatto che non si tratti di architettura x86.
Ogni tanto, cambiare aria stimola la curiosità e la voglia di cimentarsi con cose nuove...

p.s. il Cell ce lo vedrei bene con un sistema operativo del tipo BeOS...

Proprio qui volevo arrivare :)
Sto cell sulla carta sembra veramente un mostro, ma è pur vero che queste prestazioni le ottiene con software dedicato....
Tanto per riportare un banale esempio, nel mio vecchio athlon slot-A 700mhz con installato BeOS riuscivo a far girare fluidamente 7 divx contemporaneamente, senza contare che il vecchio e caro BeOS era ottimizzato per piattaforme multiprocessore...

Il procio è uno solo con 8 core... il modello di punta dovrebbe averne 16 di core.
Quest'informazione (assolutamente falsa) dove l'hai presa?
Se serve raddoppiare la potenza di calcolo, basta mettere due Cell assieme: è anche per questo che Cell è stato creato.
E un po' come i nuovi processori Intel e AMD con doppio core, che comunque restano sempre e solo un processore. La tecnologia applicata sul Cell però è profondamente diversa da quella di Intel e AMD.
Infatti i dual core di Intel e AMD non hanno niente a che vedere con Cell: il paragone non calza proprio...

Qualcuno arriva e costruisce un processore 10 volte meglio di Intel o Amd?
Ho l'impressione che ci sia un pò di gente che crede in babbo natale.
Appunto. Cell ha un target completamente diverso. Se vogliamo cercare, qualche soluzione simile (quanto a potenza di calcolo offerta e modalità d'impiego) esiste già: le attuali GPU.

Non mi sembra che con un architettura X86
con sette cpu riesci a gestire 48 flussi mpeg2
con una cpu X86 riesci a gestire al massimo due flussi video
I DVD (MPEG-2, quindi), li vedevo già fluidamente col mio vecchi K6-2 400Mhz...

secondo me nel mirino di IBM c'è piuttosto il mercato del supercomputing. Sostituendo i MAC 32 delle SPE Cell con MAC 64 hai un processore capace di almeno 250 Gflop teorici (LINPACK) e a 65 nm dovrebbe consumare sui 70 W. Mettine un migliaio insieme e ottieni una potenza teorica doppia rispetto a Blue Gene con consumi e spazio ridotti :D
Mica facile sostituire i MAC32 coi MAC64... ;)

IMHO ci dobbiamo aspettare molto da questo processore, non i miracoli ma grandi cose se sfruttato degnamente, si!
La domande sorge spontanea: in quali ambiti? ;)

secondo me è un passaggio che anche i pc prima o poi dovranno fare: imho infatti dopo il salto delle GPU il prossimo sarà quello delle VPU, che magari all'inizio saranno usate più che altro per i giochi (vedi Phsyx) ma poi pian piano anche per altri compiti (ad esempio proprio la codifica / decodifica di flussi video).
E' stato già fatto qualche anno addietro col P10, che ha coniato il termine VPU. ;)
Inoltre le attuali GPU che implementano gli shader 3.0 offrono parecchia "programmabilità", e sarà ancora meglio per il futuro.

Se, insomma, abbiamo bisogno di una grossa potenza di calcolo e il problema lo permette, non credo che ci siano particolari problemi nello scrivere uno shader da usare con le DirectX9 e con un'adeguata GPU. E non stiamo parlando di roba dell'altro mondo: son cose che fanno già da anni i programmatori di videogiochi... :p
sinceramente non capisco perchè intel e amd, che fanno cpu molto corpose in termini di transistor, non prevedano l'equivalente di un altivec, che a quanto mi risulta "consuma" solo due o tre milioni di transistor. i vari set di istruzioni SIMD attualmente presenti sugli x86 infatti non sono paragonabili alle capacità di altivec: al posto che fare mmx, mmx2, 3dnow, sse 1 2 e 3, e così via, fatene uno fatto cattivo, no? =)
Le SSE sono simili ad Altivec, e non mi sembra che richiedano una quantità di transistor superiore.

il problema come correttamente sottolineato da diverse persone è che cell NON è un processore general purpose. facciamo un parallelo. i mac hanno dei processori che presi di per sè hanno un'efficienza ridotta rispetto agli x86 (non voglio scatenare un flame, ma se andate a verificare le conclusioni vengono da sè) TUTTAVIA grazie ad altivec riescono in alcuni e ben precisi ambiti ad essere comunque competitivi (vedi photoshop) e in altri addirittura molto più peformanti (ad esempio con BLAST). in pratica ad un processore general purpose non particolarmente performante viene accostata una unità vettoriale capace di macinare gflops su gflops: il risultato è una macchina in grado di fare molto bene pochissime cose, discretamente bene poche altre, e le altre diciamo che le fa e basta =)

Secondo me è proprio il concetto di processore "general purpose" che viene rivoluzionato con Cell. La sua particolarare implementazione con molte unità vettoriali ne è la conseguenza.

Fino ad ora si era cercato di spremere la massima velocità dai processori nell'esecuzione di un singolo thread scalare. Questo è utile per una montagna di utilizzi, come far girare un word-processor, visualizzare una pagina web (in parte) o mandare un email. Ma non sono questi i compiti dove i processori moderni hanno dei colli di bottiglia. Le applicazioni dove la potenza non basta mai sono la grafica, il video, i calcoli scientifici, il 3D e in generale il processo di streams digitali.

In ambito casalingo ormai gli utilizzi che ci spingono ad acquistare un computer più veloce sono il poter giocare con gli MP3, ritoccare foto digitali, editare filmati, giocare con videogiochi 3D e simili e magari poter fare tutto questo insieme. In ambiente scientifico poter fare simulazioni sempre più complesse. Non sono certo i word processor o i programmi di email il problema.

Ed è per questi ambiti che Cell è progettato, ed eccelle.

La PPE (l'unità PowerPC del Cell) pur non essendo (forse) veloce nei compiti scalari come un Power5 o un Pentium di ultima generazione, è perfettamente adeguata per gli utilizzi non vettorializzabili che rimangono.

Il Cell è il processore "general purpose" dell'era digitale.

Ma se cell è composto da 8 processori di cui 1 powerpc non direi che sia utilizzabile solo in un fornetto per scaldare le vivande.
Chiaro che forse in un pc sarebbe non sfruttato a pieno
ma sicuramente sarebbe potente, il powerpc e un processore equivalente hai nostri X86 cioè generico !!

Secondo me è proprio il concetto di processore "general purpose" che viene rivoluzionato con Cell. La sua particolarare implementazione con molte unità vettoriali ne è la conseguenza.

Il Cell e' uno stream processor, non certo un processore general purpose.
Come general purpose avrebbe la stragrande maggioranza dei transistor inoperanti nella stragrande maggioranza dei casi, operando solo con il core PowerPC; un multi core general purpose con lo stesso numero di transistor lo surclasserebbe.


In ambito casalingo ormai gli utilizzi che ci spingono ad acquistare un computer più veloce sono il poter giocare con gli MP3, ritoccare foto digitali, editare filmati, giocare con videogiochi 3D e simili e magari poter fare tutto questo insieme. In ambiente scientifico poter fare simulazioni sempre più complesse. Non sono certo i word processor o i programmi di email il problema.

Ed è per questi ambiti che Cell è progettato, ed eccelle.

Ed e' proprio in questi ambiti che soluzioni alternative sarebbero decisamente piu' efficienti.
Per un videogioco, approcci multi core + GPU sono estremamente piu' efficienti del Cell, che non e' in grado di svolgere operazioni di rasterizzazione con l'efficienza di una GPU ad esempio. Per suonare un MP3 (non credo si abbia bisogno di suonarne un centinaio in contemporanea ;)) non c'e' bisogno di scomodare uno stream processor e i restanti transistor potrebbero essere usati per altri compiti.

In ambiente scientifico, al contrario, un processore come il Cell avrebbe ottimi usi soprattutto per problemi altamente paralleli.

In sintesi: il Cell presentato come processore general purpose fantascientifico in grado di fare tutto piu' veloce di tutto e' pura fantasia da marketing. E' uno strumento ottimo per determinati compiti, non adatto ad altri compiti e va usato per quello.

Ma se cell è composto da 8 processori di cui 1 powerpc non direi che sia utilizzabile solo in un fornetto per scaldare le vivande.
Chiaro che forse in un pc sarebbe non sfruttato a pieno
ma sicuramente sarebbe potente, il powerpc e un processore equivalente hai nostri X86 cioè generico !!
Non si sa ancora niente di preciso: mancano i dettagli sull'ISA. Si sa che è di derivazione PowerPC.

Si conosco, però, alcuni dettagli implementativi, e da ciò è facile dedurre che le sue prestazioni in ambito general purpose non possono assolutamente competere con le architetture PowerPC esistenti.

Il Cell e' uno stream processor, non certo un processore general purpose.
Come general purpose avrebbe la stragrande maggioranza dei transistor inoperanti nella stragrande maggioranza dei casi, operando solo con il core PowerPC; un multi core general purpose con lo stesso numero di transistor lo surclasserebbe.

In quale applicazione PRATICA un "multi core general purpose" lo surclasserebbe?

Per un videogioco, approcci multi core + GPU sono estremamente piu' efficienti del Cell, che non e' in grado di svolgere operazioni di rasterizzazione con l'efficienza di una GPU ad esempio.

Cell+GPU Nvidia è l'approccio scelto da Sony per la PS3 per avere le massime perfomance nei giochi, ma credo che disponendo di un processore Cell in un utilizzo casalingo NON specificatamente mirato ai giochi si potrebbe risparmiare un bel po' sulla scheda grafica pur avendo, anche nei giochi, delle prestazioni molto più che onorevoli...

Ma se cell è composto da 8 processori di cui 1 powerpc non direi che sia utilizzabile solo in un fornetto per scaldare le vivande.
Chiaro che forse in un pc sarebbe non sfruttato a pieno
ma sicuramente sarebbe potente, il powerpc e un processore equivalente hai nostri X86 cioè generico !!

Beh, è un processore DERIVATO dai power PC e quindi general-purpose, ma non è particolarmente potente, in quanto ha un core molto semplificato (es. è un core con esecuzione in-order). A 4 GHz probabilmente sarà meno performante dei suoi "fratelli" che viaggiano intorno ai 2 GHz. Non che alla fine nella maggior parte degli usi questo sia un grosso danno.

In quale applicazione PRATICA un "multi core general purpose" lo surclasserebbe?


Una qualunque applicazione multithreaded non vettoriale, una qualunque applicazione pesantemente IO bound (ovvero il 99% delle applicazioni che girano su un PC)..


Cell+GPU Nvidia è l'approccio scelto da Sony per la PS3 per avere le massime perfomance nei giochi, ma credo che disponendo di un processore Cell in un utilizzo casalingo con specificatamente mirato ai giochi si potrebbe risparmiare un bel po' sulla scheda grafica pur avendo, anche nei giochi, delle prestazioni molto più che onorevoli...

Credi male, perche' il problema qui e' che cosa poi fare con un determinato numero di transistor. Gli SPE non vengono mica gratis, costano transistor e se devo fare grafica 3d quei transistor sono spesi meglio in una GPU dedicata, che per questo compito e' anche piu' semplice da programmare.

In un utilizzo casalinga non mirato ai giochi si puo' risparmiare molto NON usando un Cell, ma un normale processore GP con una GPU dedicata. Usara un Cell in questa situazione e' come pensare di uccidere una mosca con un cannone, uno strumento che riesce nello scopo, ma e' un po' sovradimensionato.

Una qualunque applicazione multithreaded non vettoriale, una qualunque applicazione pesantemente IO bound (ovvero il 99% delle applicazioni che girano su un PC)..

A parte il fatto che come IO il Cell con i suoi bus e memorie Rambus è 5-10 volte meglio dei processori attuali, poi certo la velocità dell'HD ha la sua importanza...

Ma quale applicazione multithreaded non vettorializzabile è lenta sui PC moderni?
(e comunque la PPE del Cell è dual-threaded diversamente dagli attuali PowerPC 970x)

Credi male, perche' il problema qui e' che cosa poi fare con un determinato numero di transistor. Gli SPE non vengono mica gratis, costano transistor e se devo fare grafica 3d quei transistor sono spesi meglio in una GPU dedicata, che per questo compito e' anche piu' semplice da programmare.

Ma il Cell è "general purpose", appunto!! Non è fatto solo per i giochi!
E' un "general purpose" per gli stream digitali, il che include i giochi 3D, ma non è pensato per competere con un hardware dedicato specifico top di gamma!
Per quello Sony gli affianca una GPU nella PS3 (cosa che la PS2 non ha).

In un utilizzo casalinga non mirato ai giochi si puo' risparmiare molto NON usando un Cell, ma un normale processore GP con una GPU dedicata. Usara un Cell in questa situazione e' come pensare di uccidere una mosca con un cannone, uno strumento che riesce nello scopo, ma e' un po' sovradimensionato.

Ma la GPU sa fare solo i giochi, o poco più (vedi OS-X Tiger con il CoreVideo).
Il Cell è molto più general purpose!!!

A parte il fatto che come IO il Cell con i suoi bus e memorie Rambus è 5-10 volte meglio dei processori attuali, poi certo la velocità dell'HD ha la sua importanza...

Non ha la sua importanza, e' l'unica cosa che conta. Butta i transistor degli SPE in tanta cache, che sono usati molto meglio in software pesantemente IO bound.


Ma quale applicazione multithreaded non vettorializzabile è lenta sui PC moderni?
(e comunque la PPE del Cell è dual-threaded diversamente dagli attuali PowerPC 970x)

Compilazione. Quasi idealmente parallelizzabile, tipicamente non vettoriale, lo fai girare su un Cell? No, lo fai girare su un bel processore multicore che a parita' quando si tratta di compilare codice macinerebbe qualunque Cell a parita' di transistor.


Ma il Cell è "general purpose", appunto!! Non è fatto solo per i giochi!
E' un "general purpose" per gli stream digitali, il che include i giochi 3D, ma non è pensato per competere con un hardware dedicato specifico top di gamma!
Per quello Sony gli affianca una GPU nella PS3 (cosa che la PS2 non ha).

Il Cell non e' general purpose (e due), e' uno stream processor e fa benissimo lo stream processor, infatti Sony gli ha affiancato una GPU perche' Cell non puo' fare da CPU (alla faccia del general purpose).


Ma la GPU sa fare solo i giochi, o poco più (vedi OS-X Tiger con il CoreVideo).
Il Cell è molto più general purpose!!!

Ma questo lo dici tu, io con una GPU ci posso processare suoni, fare fisica, risolvere problemi finanziari (non ci pensavi vero?), pure compilare programmi C se vuoi, lo farei dannandomi l'anima, ad una velocita' infinitamente bassa, ma il modello di programmazione me lo permetterebbe.
E lo stesso vale per il Cell, il suo modello di programmazione permette di fare qualunque cosa una CPU normale puo' fare, ma alcune cose molto piu' velocemente, altre molto piu' lentamente e con difficolta' di programmazione.

Non capisci che il Cell non e' la panacea di tutti i mali, non e' la rivoluzione, e' uno strumento che fa benissimo il suo compito (quello dello stream processor) e male tutto il resto (a parita' di transistor). Sei vittima del marketing.

Non ha la sua importanza, e' l'unica cosa che conta. Butta i transistor degli SPE in tanta cache, che sono usati molto meglio in software pesantemente IO bound.

Oppure elimina la cache (che costa transistor, anche il 70-80% nei processori attuali) e fai la Ram e il bus 5-10 volte più veloce. Che è l'approccio di Cell.
Così ti rimangono molti più transistor per macinare numeri...

Compilazione. Quasi idealmente parallelizzabile, tipicamente non vettoriale, lo fai girare su un Cell? No, lo fai girare su un bel processore multicore che a parita' quando si tratta di compilare codice macinerebbe qualunque Cell a parita' di transistor.

Ma il Cell di core ne ha 9!! E programmare un compilatore in una SPE non è teoricamente differente che farlo nel core PowerPC!! Hanno un'altra ISA, sono vettoriali, ma nessuno impedisce di usare un dato alla volta ed utilizzarle come semplici core scalari general purpose!

Ma questo lo dici tu, io con una GPU ci posso processare suoni, fare fisica, risolvere problemi finanziari (non ci pensavi vero?), pure compilare programmi C se vuoi, lo farei dannandomi l'anima, ad una velocita' infinitamente bassa, ma il modello di programmazione me lo permetterebbe.

Vedi, alla fine sei arrivato alle mie stesse conclusioni: anche con un stream-processor, sia esso una GPU o una PPE del Cell, puoi svolgerci dei compiti "general-purpose" anche se con dei limiti.
E più un hardware è dedicato ad un preciso compito e con più difficoltà ne riesce a fare altri, come le GPU.

Le PPE sono un compromesso. Non saranno il top come GPU, non saranno il top come processori scalari, ma sono certamente il top per macinare numeri e grazie alla loro semplicità in un chip ce ne possono stare tante e quindi potrebbero adattarsi con successo anche in compiti per il quale non sono particolarmente ottimizzate, come la compilazione o i giochi 3D.

Come lo vedi un compilatore scritto per le PPE?
Sono più veloci 8 core PPE o 2 core di un Pentium 4?

Oppure elimina la cache (che costa transistor, anche il 70-80% nei processori attuali) e fai la Ram e il bus 5-10 volte più veloce. Che è l'approccio di Cell.
Così ti rimangono molti più transistor per macinare numeri...

Non ti serve macinare numeri, ti serve fare IO. Levi gli SPE e metti la cache. Esistono limiti tecnologici alla velocita' della RAM e quelli sono fissi, non puoi solo dire "ok, facciamo la RAM piu' veloce, in barba alle leggi della fisica".



Ma il Cell di core ne ha 9!! E programmare un compilatore in una SPE non è teoricamente differente che farlo nel core PowerPC!! Hanno un'altra ISA, sono vettoriali, ma nessuno impedisce di usare un dato alla volta ed utilizzarle come semplici core scalari general purpose!

Esatto, nessuno lo impedisce, come nessuno impedirebbe ad una GPU di fare lo stesso. Andrebbe solo lentissimo, molto piu' lento che usando quei transistor in una CPU multicore che svolge questo compito meglio. E' questo il nodo della questione: per ogni problema c'e' uno strumento che lo risolve meglio degl'altri e il Cell non e' lo strumento che risolve tutti i problemi al meglio. Ne risolve solo alcuni.



Vedi, alla fine sei arrivato alle mie stesse conclusioni: anche con un stream-processor, sia esso una GPU o una PPE del Cell, puoi svolgerci dei compiti "general-purpose" anche se con dei limiti.
E più un hardware è dedicato ad un preciso compito e con più difficoltà ne riesce a fare altri, come le GPU.

Guarda che dal punto di vista teorico, una macchina di Turing puo' risolvere qualunque problema computabile. Se vuoi affermare che il Cell e' in grado teoricamente di risolvere qualunque problema computabile, hai scoperto l'acqua calda, e' un'ovvieta'.
Ma tu non mi stai dicendo che e' in grado di risolvere teoricamente qualunque problema, mi stai dicendo che e' in grado di risolvere qualunque problema meglio di una CPU classica o di una GPU. E' falso.
E' in grado di risolvere solo una strettissima classe di problemi (quelli vettoriali altamente parallelizzabili) meglio di una CPU classica e questi problemi non sono i piu' comuni, quindi un Cell in un PC non sarebbe un'idea intelligente (cannone e mosca).


Le PPE sono un compromesso. Non saranno il top come GPU, non saranno il top come processori scalari, ma sono certamente il top per macinare numeri e grazie alla loro semplicità in un chip ce ne possono stare tante e quindi potrebbero adattarsi con successo anche in compiti per il quale non sono particolarmente ottimizzate, come la compilazione o i giochi 3D.

Ti stai confondendo fra PPE e SPE. Le SPE fanno solo il controllo, le PPE macinano i numeri.

E continua a sfuggirti il problema: esistono le leggi della fisica e anche Cell deve sottostare a quelle (a meno che non abbiano trovato un modo per violare le leggi della fisica).

Il ragionamento che devi fare non e' "butto tanti Cell e svolgo qualunque compito", ma:

- Devo risolvere un determinato compito (compilare un programma in C)
- Dato un processo di produzione ed un certo valore di dissipazione termica, posso usare un certo valore X di transistor per produrre il processore per svolgere il compito
- Come posso utilizzare meglio questo numero di transistor? Mettendo tanti Cell con tanti transistor usati per i calcoli vettoriali che non usero' nel mio compito oppure un processore multicore con esecuzione out of order?

Non viviamo nel mondo dei sogni dove puoi creare processori con millemilamiliardi di transistor, ma in un mondo molto reale dove valgono le leggi della fisica.


Come lo vedi un compilatore scritto per le PPE?
Sono più veloci 8 core PPE o 2 core di un Pentium 4?

Dipende da quello che devi fargli fare.

Se non credi a quello che ti dico io, leggi questo articolo sul Cell, e' fatto piuttosto bene, anche se particolarmente tecnico:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2379&p=8


If there’s a weak element of the Cell architecture it’s the PPE, but then again, Cell isn’t targeted at general purpose computing, despite what some may like to spin it as.

Non ti serve macinare numeri, ti serve fare IO. Levi gli SPE e metti la cache. Esistono limiti tecnologici alla velocita' della RAM e quelli sono fissi, non puoi solo dire "ok, facciamo la RAM piu' veloce, in barba alle leggi della fisica".

Senza superare limiti della fisica, Rambus a quanto pare è in grado di fare dei bus e delle memorie molto più veloci di quelle ora in commercio. E l'approccio di Cell è stato di spingere in questa strada, piuttosto che continuare ad ingrandire le cache (vedi l'ultimo Itanium da 1,7 miliardi di transistor, quasi tutti facenti parte dell'enorme cache).

Ma tu non mi stai dicendo che e' in grado di risolvere teoricamente qualunque problema, mi stai dicendo che e' in grado di risolvere qualunque problema meglio di una CPU classica o di una GPU. E' falso.


No, io sto dicendo che Cell è un compromesso, come sono un compromesso gli attuali processori "general-purpose" tipo i Pentium, ma un compromesso diverso. Mirato ad ottimizzare le prestazioni per gli utilizzi del 2000, non degli anni 70-80. Quindi per gli stream digitali, non le applicazioni di ufficio.

E' in grado di risolvere solo una strettissima classe di problemi (quelli vettoriali altamente parallelizzabili) meglio di una CPU classica e questi problemi non sono i piu' comuni, quindi un Cell in un PC non sarebbe un'idea intelligente (cannone e mosca).

Ma come tu mi insegni sono il 20% delle persone che hanno l'80% dei soldi, sono il 20% degli utenti internet che utilizzano l'80% della banda ...
E sono il 20% degli algoritmi che richiedono l'80% della potenza di un processore. Il Cell è ottimizzato per quel 20%, i processori attuali per il restante 80% di cui ce n'è scarso bisogno.

Ti stai confondendo fra PPE e SPE. Le PPE fanno solo il controllo, le SPE macinano i numeri.

Ma sono esse stesse dei processori suffientemente generici e indipendenti, anche se ottimizzati per il calcolo vettoriale. Così sembrerebbe almeno dalle info attualmente disponibili...

Il ragionamento che devi fare non e' "butto tanti Cell e svolgo qualunque compito", ma:

- Devo risolvere un determinato compito (compilare un programma in C)
- Dato un processo di produzione ed un certo valore di dissipazione termica, posso usare un certo valore X di transistor per produrre il processore per svolgere il compito
- Come posso utilizzare meglio questo numero di transistor? Mettendo tanti Cell con tanti transistor usati per i calcoli vettoriali che non usero' nel mio compito oppure un processore multicore con esecuzione out of order?


Infatti è stato proprio questo l'approccio dei progettisti del Cell che ha portato alla sua originale architettura.
C'è un interessante articolo di uno dei progettisti proprio qui:
http://www.hpcaconf.org/hpca11/papers/25_hofstee-cellprocessor_final.pdf

Senza superare limiti della fisica, Rambus a quanto pare è in grado di fare dei bus e delle memorie molto più veloci di quelle ora in commercio. E l'approccio di Cell è stato di spingere in questa strada, piuttosto che continuare ad ingrandire le cache (vedi l'ultimo Itanium da 1,7 miliardi di transistor, quasi tutti facenti parte dell'enorme cache).


E questo approccio va bene per determinati compiti, non per tutti i compiti.
Ad un compilatore serve tanta cache perche' accedera' molto spesso agli stessi dati, per fare encoding video servira' molta banda e la cache sara' ininfluente perche' deve processare uno stream di dati. Cell va bene per fare encoding video, non per compilare.


No, io sto dicendo che Cell è un compromesso, come sono un compromesso gli attuali processori "general-purpose" tipo i Pentium, ma un compromesso diverso. Mirato ad ottimizzare le prestazioni per gli utilizzi del 2000, non degli anni 70-80. Quindi per gli stream digitali, non le applicazioni di ufficio.

Marketing.
Mira ad ottimizzare le prestazioni come stream processor, non come CPU general purpose.



Ma sono esse stesse dei processori suffientemente generici e indipendenti, anche se ottimizzati per il calcolo vettoriale. Così sembrerebbe almeno dalle info attualmente disponibili...

E te lo ripeto per l'ennesima volta, se devo fare applicazioni general purpose (come il 90% di cio' che avviene in un PC), invece di usare il PPE e tenere fermo il resto del Cell, uso una CPU out of order multicore che con lo stesso numero di transistor mi esegue le operazioni general purpose di un PC molto piu' efficientemente. Non faro' encoding video di 48 canali contemporaneamente? Pazienza, ma tutto il resto andra' piu' veloce.



If there’s a weak element of the Cell architecture it’s the PPE, but then again, Cell isn’t targeted at general purpose computing, despite what some may like to spin it as.


Infatti è stato proprio questo l'approccio dei progettisti del Cell che ha portato alla sua originale architettura.
C'è un interessante articolo di uno dei progettisti proprio qui:
http://www.hpcaconf.org/hpca11/papers/25_hofstee-cellprocessor_final.pdf


Cell non e' una scelta intelligente per una CPU general purpose, e' un ottimo stream processor, che non metterai mai da solo in un PC.

Cell non e' una scelta intelligente per una CPU general purpose, e' un ottimo stream processor, che non metterai mai da solo in un PC.

Mah, secondo me le potenzialità ci sono. Certo è strano e all'inizio sarà difficile sfruttarlo al meglio. Comunque ormai la commercializzazione non è lontana, staremo a vedere...

Mah, secondo me le potenzialità ci sono. Certo è strano e all'inizio sarà difficile sfruttarlo al meglio. Comunque ormai la commercializzazione non è lontana, staremo a vedere...

Secondo me le potenzialita' non ci sono perche' Cell non e' stato progettato per quello.
Sarebbe come dire che un frigo ha le potenzialita' per cuocere delle ottime torte se sfruttato al meglio.
Ovviamente no, perche' un frigo e' progettato per raffreddare, non per riscaldare, certo gli puoi dare fuoco e sperare di cuocerci una torta, ma io userei un forno :)

Secondo me le potenzialita' non ci sono perche' Cell non e' stato progettato per quello.
Sarebbe come dire che un frigo ha le potenzialita' per cuocere delle ottime torte se sfruttato al meglio.
Ovviamente no, perche' un frigo e' progettato per raffreddare, non per riscaldare, certo gli puoi dare fuoco e sperare di cuocerci una torta, ma io userei un forno :)

Oh, ma ti dimentichi la "SPE" da 4.6 ghz dual-threaded!
Anche scordandoci degli altri 8 cores, io credo che sarebbe sempre meglio dei G4/G5 attualmente montati su tutti i Mac ad esclusione dei PowerMac!
Le PPE vedile come "bonus"... :)

Oh, ma ti dimentichi la "SPE" da 4.6 ghz dual-threaded!
Anche scordandoci degli altri 8 cores, io credo che sarebbe sempre meglio dei G4/G5 attualmente montati su tutti i Mac ad esclusione dei PowerMac!
Le PPE vedile come "bonus"... :)
Cdimauro ha già spiegato perchè non è così. Manca soprattutto la gestione di istruzioni Out of Order che in caso di codice sequenziale influenzano molto le prestazioni, soprattutto con codice compilato opportunamente.

Le SSE sono simili ad Altivec, e non mi sembra che richiedano una quantità di transistor superiore.

io sapevo che hanno numero di registri, capacità di calcolo e numero di operazioni inferiori ad altivec...


criceto: c'era un articolo interessante sul cell mi sembra su arstechnica o su anandtech dove descrivevano il powerpc che sta alla base del cell... scordati del tutto che veda anche solo con il binocolo un x86 moderno o un power5...

comunque imho dovresti ascoltare di più fek :D il cell NON è general purpose anche se può far girare applicazioni general purpose: il punto è che lo fa male. capisco che può essere interessante avere windows media player che ti consuma il 10% di cpu mentre riproduce un filmato in HD 1080i, ma se il costo è che ti ci mette 12 minuti a caricare l'os e 1 a caricare il lettore multimediale forse un pensierino a usare il cell come coprocessore piuttosto che come cpu principale ce lo farei =) dico per dire eh, però è per rendere l'idea.

stesso discorso per il concetto GPU / VPU: sono due cose diverse, il cell non è adatto a fare i calcoli che si smazza la GPU... certo, puoi fare tutto, puoi usare anche le directx in modalità software, questo non vuol dire che sia proficuo, anzi... la cosa per cui verrà sfruttato molto il cell almeno all'inizio è la gestione di una fisica molto più complessa di quella che vediamo attualmente nei giochi, e poi passando sui computer di sicuro lo vedremo per la gestione efficiente di stream e di calcoli scientifici. in ogni caso non andrà molto al di là di questi ambiti.

criceto: c'era un articolo interessante sul cell mi sembra su arstechnica o su anandtech dove descrivevano il powerpc che sta alla base del cell... scordati del tutto che veda anche solo con il binocolo un x86 moderno o un power5...

Beh i Power5 sono di un'altra lega (e costo), ma Microprocessor Report è di un altro avviso in un confronto con gli attuali "G5":

"The performance of only the 4GHz Power core without the
SPEs is harder to compare with the slower 2.5GHz G5 processor,
because of the Cell core’s simpler microarchitecture. The
higher clock speed of the Cell processor can still process many
math operations faster than the G5 can, so we would give the
performance edge to the Cell processor."

@ Fek

Dato che entra costantemente in discussione il Cell in ambito game vorrei sapere da te cosa ne pensi del rivale Microsoft, l'XBox2, che presenta 3 power pc in parallelo più una VPU ATI a unità unificate.

Come si pone rispetto al Cell + VPU nVidia ? Chi ha maggiori possibilità di stupire ?

grazie :)

Oh, ma ti dimentichi la "SPE" da 4.6 ghz dual-threaded!
Anche scordandoci degli altri 8 cores, io credo che sarebbe sempre meglio dei G4/G5 attualmente montati su tutti i Mac ad esclusione dei PowerMac!
Le PPE vedile come "bonus"... :)

Un bonus che costa transistor che possono essere usati meglio in applicazioni che non richiedono le PPE (il 90%).

@ Fek

Dato che entra costantemente in discussione il Cell in ambito game vorrei sapere da te cosa ne pensi del rivale Microsoft, l'XBox2, che presenta 3 power pc in parallelo più una VPU ATI a unità unificate.

Come si pone rispetto al Cell + VPU nVidia ? Chi ha maggiori possibilità di stupire ?

grazie :)

La verita'? Non e' ho la piu' pallida idea :D
A pelle sono piu' vicino alla soluzione dell'XBOX2, che mi sembra piu' flessibile e facile da programmare, ma la soluzione della PS3 dovrebbe essere in linea teorica piu' performante e complicata da programmare.
A questo stadio, senza aver mai scritto una riga di codice per nessuna delle due, non saprei davvero dire di piu'.

La verita'? Non e' ho la piu' pallida idea :D
A pelle sono piu' vicino alla soluzione dell'XBOX2, che mi sembra piu' flessibile e facile da programmare, ma la soluzione della PS3 dovrebbe essere in linea teorica piu' performante e complicata da programmare.
A questo stadio, senza aver mai scritto una riga di codice per nessuna delle due, non saprei davvero dire di piu'.


Grazie :)

Sbaglio se dico che la PS3 è più forte di Xenon nel lato CPU ma più deficitaria nel versante VPU ? Del resto si dice che la VPU nVidia sia una derivazione di base GF6800, quindi unità NON unificate, mentre Xenon potrebbe avere una gestione dei pixel/vertex molto più efficente.

:)

Grazie :)

Sbaglio se dico che la PS3 è più forte di Xenon nel lato CPU ma più deficitaria nel versante VPU ? Del resto si dice che la VPU nVidia sia una derivazione di base GF6800, quindi unità NON unificate, mentre Xenon potrebbe avere una gestione dei pixel/vertex molto più efficente.

:)

Ma potrebbe anche non averlo. Davvero, a questo stadio non sappiamo proprio nulla, anch'io non ho ancora visto i data sheet di nessuna delle due. Spero di mettere a breve le mani sui manuali dello Xenon.

Ma potrebbe anche non averlo. Davvero, a questo stadio non sappiamo proprio nulla, anch'io non ho ancora visto i data sheet di nessuna delle due. Spero di mettere a breve le mani sui manuali dello Xenon.

:p

muoio dalla voglia di sapere cosa c'è dentro a ste scatole malefiche :p ;)

Un bonus che costa transistor che possono essere usati meglio in applicazioni che non richiedono le PPE (il 90%).

Un bonus che ti permette di fare in real-time quel 10% di cose che inchiodano gli altri computer... :)

Un bonus che ti permette di fare in real-time quel 10% di cose che inchiodano gli altri computer... :)

Ma lo capisci che se a me interessa compilare un programma, non mi interessa che faccia l'encoding di 48 video in simultanea???
Ma lo cogli questo piccolissimo problema?
Voglio solo compilare, fosse per me puo' anche cacare fulmini e saette il Cell, ma se si inchioda a fare il 90% di quello che mi serve, se lo possono anche tenere.

E la compilazione e' solo un esempio, e vale anche per il restante 90% di cio' che di solito si fa con un PC.

@Fek
Per essere più precisi, visto che c'è anche gente, come me, che ne capisce poco di queste cose... Quali sono in soldoni le applicazioni comuni in ambito PC dove il Cell sarebbe deficitario e quali dove invece sarebbe una bomba. Mi piacerebbe avere una specie di lista tipo:
Word-processing: fa schifo
Compilazione: fa schifo
Streaming Video: è una bomba

Sai perchè te lo chiedo? Perchè non tutti gli utenti PC sono uguali, c'è chi predilige un applicativo ad un altro. Quindi magari per te il Cell è inutile, ma per uno che lavora in ambito grafico o audio-video potrebbe essere la famosa chimera.

Certo è che finalmente si stà facendo un po' di chiarezza su questa tecnologia, non avrei mai immaginato tante problematiche. Ma è naturale, penso, visto che miracoli non se ne possono fare ed è come una coperta troppo corta. Certo è che finalmente qualcuno (Sony, IBM & Co) ha avuto almeno il coraggio di intraprendere una nuova strada, chissà che non risulti, alla fine, essere quella vincente.

@Fek
Per essere più precisi, visto che c'è anche gente, come me, che ne capisce poco di queste cose... Quali sono in soldoni le applicazioni comuni in ambito PC dove il Cell sarebbe deficitario e quali dove invece sarebbe una bomba. Mi piacerebbe avere una specie di lista tipo:
Word-processing: fa schifo
Compilazione: fa schifo
Streaming Video: è una bomba


Hai gia' fatto tu l'elenco.
Posso aggiungere che in genere le applicazioni dove il Cell va molto bene sono quelle che richiedono molti calcoli relativamente semplici su un flusso di dati (il processing video e audio).

Va molto male in applicazioni che manipolano strutture dati complesse, come la compilazione, la gestione di database, fogli elettronici, l'IA dei giochi, la gestione delle scene 3d sempre nei giochi, anche se alcuni mettono queste applicazioni fra i punti di forza del Cell.

Scusa FeK, ma le scene 3d non sono vettorizzate? A quel punto dovrebbe andare benone, meglio di un processore tradizionale. Se invece intendi che a quel punto una GPU le gestisce meglio allora è un altro paio di maniche.

vi dico subito che:
-mi sono avvicinato seriamente all informatica da 2 mesi
-anche se ho un sony non sono stato influenzato dal marketing
-fino a quando non ho le prove non grido al miracolo, ma questo processore e il futuro della multimedialita, a molte condizioni pero, la piu importante credo che sia quella di avere affianco un proc con architettura x86 e una gpu.
lo li metterei su un socket della MB affianco al proc con delle loro ram.
CPU, GPU e CELL che lavorano insieme credo possano dare grandi risultati se ho capito bene.
(vorrei aprire una parentesi su una cosa che molti non hanno capito: si chiama "cell" perche proprio come una cellula lavora "in simbiosi con altre cellule" come gli xeon e gli opteron, ma questo ovviamente dipendera dal costo)

Scusa FeK, ma le scene 3d non sono vettorizzate? A quel punto dovrebbe andare benone, meglio di un processore tradizionale. Se invece intendi che a quel punto una GPU le gestisce meglio allora è un altro paio di maniche.

Questo e' un errore comune :)

Una scena 3d non e' altro che un database ed e' gestito con algoritmi in parte simili.
Ci sono gli oggetti, gli oggetti sono organizzati in famiglie, un oggetto e' composto di sotto oggetti ai quali sono associati materiali e poligoni.

Disegnare una scena significa eliminare gli oggetti non visibili in un qualche modo, metterli in ordine secondo un qualche criterio, applicare alcune trasformazioni e poi spedire i poligoni che fanno parte degli oggetti visibili al resto della pipeline che li trasformera' e dividera' in pixel (quest'ultima parte e' appannaggio della GPU o chi per lei).

Tutta la fase di ordinamento e controllo della visibilita' non e' altro che maneggiare una struttura dati piu' o meno complicata, da tenere tendenzialmente sempre in memoria cache per velocizzare gli accessi. E' molto simile come ho detto a gestire un database. Queste non sono operazioni che un processore come il Cell gradisce enormemente.

Grazie Fek, sei stato esaustivo e gentilissimo.

fek: hai lasciato fuori la fisica dei giochi, mentre un pc può gestire poche decine di oggetti un pc con vpu, una ps 3 con cell o una xbox 360 (che dovrebbe macinare gflops su gflops pure lei) dovrebbe gestirne migliaia

fek: hai lasciato fuori la fisica dei giochi, mentre un pc può gestire poche decine di oggetti un pc con vpu, una ps 3 con cell o una xbox 360 (che dovrebbe macinare gflops su gflops pure lei) dovrebbe gestirne migliaia

Hai ragione, una simulazione fisica e' spesso facilmente parallelizzabile, un calcolo relativamente semplice da svolgere su uno "stream di oggetti".

a tal proposito, sono molto curioso di vedere un gioco che sfrutta queste nuove tecnologie (siano esse cell, le unità vettoriali dell'xbox 360 o physx)... dev'essere un salto epocale

fek: hai lasciato fuori la fisica dei giochi, mentre un pc può gestire poche decine di oggetti un pc con vpu, una ps 3 con cell o una xbox 360 (che dovrebbe macinare gflops su gflops pure lei) dovrebbe gestirne migliaia

Sembra proprio che XBox 360 integra la PPU Ageia per la gestione della fisica, le CPU non devono fare manco questo :)

Oh, ma ti dimentichi la "SPE" da 4.6 ghz dual-threaded!
Le hai scambiate: questa è la PPE (che comunque dovrebbe essere a 4Ghz, anche se inizialmente si pensava potesse raggiungere i 4,6Ghz in produzione). ;)

Comunque è vero che può lavorare su due thread, ma è in grado di eseguire al più due istruzioni "in ordine". Paragonato a un G5 che riesce a estrarre e spedire in esecuzione fino a 5 istruzioni fuori ordine, la PPE è un cesso... :D
Anche scordandoci degli altri 8 cores, io credo che sarebbe sempre meglio dei G4/G5 attualmente montati su tutti i Mac ad esclusione dei PowerMac!
Vedi sopra: meglio un G4 a 1,5Ghz che una PPE a 4Ghz... ;)
Le PPE vedile come "bonus"... :)
Vedi sopra: sono le SPE. E sono queste ad essere rilevanti, certamente non il PPE. Tant'è che i 250GFlops sono calcolati contando la potenza di calcolo delle SPE: il PPE non l'hanno cacato neppure di striscio... :asd:

Altro che "bonus"! ;)

io sapevo che hanno numero di registri, capacità di calcolo e numero di operazioni inferiori ad altivec...
Il numero di registri nell'architettura x86 (a 32 bit) è di 8, mentre in quella x86-64 è di 16. Comunque buona parte dei problemi "parallelizzabili" non usa molti registri: considera che già un solo registro è in grado di contenere 4 dati in virgola mobile a 32 bit (e addirittura 16 interi a 8 bit, 8 interi a 16 bit, ecc.).

Le capacità di calcolo sono simili: SSE (ma anche le "vecchie" 3DNow! di AMD) e Altivec sono in grado di effettuare 4 operazioni sui 4 dati per ciclo di clock. Altivec è più efficiente perché permette di usare 4 registri per ogni operazione, di cui uno con una maschera da applicare. Comunque l'uso di queste caratteristiche dipende strettamente dall'algoritmo da implementare.

Il numero di operazioni, invece, è superiore nel caso delle SSE: ne conta più di 200, se non erro. Ma non è la quantità di operazioni a fare la differenza fra due implementazioni SIMD, quanto piuttosto cosa fanno, e da questo punto di vista fanno più o meno le stesse cose. In più le SSE hanno anche un set di istruzioni scalari, che permette di fare a meno di passare dall'uso delle SIMD a quello dell'FPU x87 quando i calcoli si devono effettuare su un solo dato alla volta; cosa inutile per i G4 e G5, in quanto già dotati di un'ottima FPU (comunque gl Athlon, e in particolare gli Athlon64, sono molto efficienti anche sul codice x87).

Beh i Power5 sono di un'altra lega (e costo), ma Microprocessor Report è di un altro avviso in un confronto con gli attuali "G5":

"The performance of only the 4GHz Power core without the SPEs is harder to compare with the slower 2.5GHz G5 processor, because of the Cell core’s simpler microarchitecture. The higher clock speed of the Cell processor can still process many math operations faster than the G5 can, so we would give the performance edge to the Cell processor."
Sì, può fare tante operazioni più velocemente... Ma QUANTE ne riesce a fare in un ciclo di clock? Poche, visto che ne può fare AL PIU' due IN ORDINE. E' questo che devi capire.

Sì, può fare tante operazioni più velocemente... Ma QUANTE ne riesce a fare in un ciclo di clock? Poche, visto che ne può fare AL PIU' due IN ORDINE. E' questo che devi capire.

2 operazioni per ciclo di clock non fanno schifo. Quante ne può fare teoricamente il G5, 3? E considera che possono essere due istruzioni di 2 thread differenti, cosa che il G5 non può fare, quindi sono più facilmente utilizzabili.

Inoltre il bus e la memoria del Cell è estremamente più veloce, così come pure la frequenza. Sono architetture molto differenti, è difficile dire sulla carta quale delle 2 è più veloce, ma una cosa è certa: non ci sarà un abisso prestazionale tra un G5 attuale e una PPE del Cell. Potrà essere un po' più veloce una o l'altra, a seconda dei casi e dei compilatori. Ma all'atto pratico saranno SIMILI. E quindi dire che il Cell è da escludere per un utilizzo general purpose perchè per il codice scalare fà schifo è sbagliato.

Inoltre i compiti della PPE saranno limitati rispetto ad un processore attuale, in quando per il lavoro pesante ci sono sempre altri gli altri 8 cores SPE.
Infine i Cell sono progettati per lavorare insieme ad altri Cell, quindi fare macchine con più di 1-2 processori dovrebbe essere molto più facile che con i processori attuali e quindi si possono adattare bene anche per compiti che possono essere divisi in molti thread ma non sono vettorializzabili come la compilazione, che diceva Fek, o i database relazionali.

2 operazioni per ciclo di clock non fanno schifo. Quante ne può fare teoricamente il G5, 3? E considera che possono essere due istruzioni di 2 thread differenti, cosa che il G5 non può fare, quindi sono più facilmente utilizzabili.

Il G5 ha un limite teorico di più di 3 ;) Comunque un'architettura OOO ha dei decisi vantaggi prestazionali.

Il G5 ha un limite teorico di più di 3 ;) Comunque un'architettura OOO ha dei decisi vantaggi prestazionali.

Non credo che possa comunque raccattare dalla memoria più di 2 istruzioni (128 bit) alla volta, quindi il limite teorico lascia il tempo che trova...
Inoltre considera che anche il famoso Itanium può essere considerato una architettura "in order"...

Ma all'atto pratico saranno SIMILI.

ma proprio no, l'unica cosa in comune che hanno è che sono due powerpc, per il resto sono completamente diversi. a partire dall'OOO.

ma proprio no, l'unica cosa in comune che hanno è che sono due powerpc, per il resto sono completamente diversi. a partire dall'OOO.

Non ho detto che sono simili i processori.
Ma che probabilmente saranno simili le prestazioni perchè entrambi hanno i loro pro e contro.

e come fai a dirlo? andando a logica (dato che conosciamo ben poche caratteristiche del cell per sbilanciarsi troppo) se realizzare un powerpc PIU' SEMPLICE di un g5 ti permette di ottenere le stesse prestazioni nelle applicazioni general purpose, c'è da chiedersi se non siano scemi alla ibm a fare la cosa più complessa :D

e come fai a dirlo? andando a logica (dato che conosciamo ben poche caratteristiche del cell per sbilanciarsi troppo) se realizzare un powerpc PIU' SEMPLICE di un g5 ti permette di ottenere le stesse prestazioni nelle applicazioni general purpose, c'è da chiedersi se non siano scemi alla ibm a fare la cosa più complessa :D

Perchè facedolo "più semplice" possono clockarlo a 4.6 Ghz invece dei 2.5Ghz a cui sono inchiodati ora con i PowerPC 970 (aka G5) realizzati con la stessa tecnologia (90nm). Inoltre semplificandolo hanno spazio per mettere altre unità nello stesso chip (9 nel Cell!) aumentando il parallelismo e quindi l'efficienza globale. Certo per alcuni algoritmi non parallelizzabili l'approccio dell'estrema ricerca del parallelismo per singolo thread (e quindi l'OOO) può risultare vincente. Ma non credo che i progettisti dell'IBM siano dei fessi avranno valutato i pro e i contro della cosa.

Per la cronaca ecco cosa pensa Ken Kuratagi, il capo della divisione entertaiment della Sony e ideatore del Cell, degli ingegneri IBM che hanno partecipato al progetto Cell "they orchestrated an all-star team for us. It was like lining up an Olympic athlete-class of engineers".
Tutta l'intervista può essere letta qui: http://techon.nikkeibp.co.jp/english/NEWS_EN/20050407/103542/

2 operazioni per ciclo di clock non fanno schifo. Quante ne può fare teoricamente il G5, 3?

Esattamente come il Pentium I :)

Perchè facedolo "più semplice" possono clockarlo a 4.6 Ghz invece dei 2.5Ghz a cui sono inchiodati ora con i PowerPC 970 (aka G5) realizzati con la stessa tecnologia (90nm).

I P4 3.6 ghz viaggiano all'interno a 7.2 ghz ed hanno un motore di esecuzione out of order. Non per altro in applicazioni general purpose surclasseranno il Cell.


Inoltre semplificandolo hanno spazio per mettere altre unità nello stesso chip (9 nel Cell!) aumentando il parallelismo e quindi l'efficienza globale.


Aumentano il parallelismo, ma non l'efficienza che dipende dall'applicazione.


Certo per alcuni algoritmi non parallelizzabili l'approccio dell'estrema ricerca del parallelismo per singolo thread (e quindi l'OOO) può risultare vincente. Ma non credo che i progettisti dell'IBM siano dei fessi avranno valutato i pro e i contro della cosa.


Non sono scemi, infatti hanno progettato un ottimo stream processor, non un processore general purpose.


Infine i Cell sono progettati per lavorare insieme ad altri Cell, quindi fare macchine con più di 1-2 processori dovrebbe essere molto più facile che con i processori attuali e quindi si possono adattare bene anche per compiti che possono essere divisi in molti thread ma non sono vettorializzabili come la compilazione, che diceva Fek, o i database relazionali.

Per l'ennesima volta, perche' ripetere le stesse cose dopo un po' diventa stancante, se per un determinato compito devo mettere 8 Cell assieme per eguagliare le prestazioni di un processore general purpose, lo capisci che tanto vale usare un processore general purpose? Che costa molto meno? Che fa meglio quel lavoro?
Lo capisci che Cell non e' un processore general purpose ma solo un ottimo stream processor che e' lentissimo a fare tutto il resto?

Esattamente come il Pentium I :)
I P4 3.6 ghz viaggiano all'interno a 7.2 ghz ed hanno un motore di esecuzione out of order. Non per altro in applicazioni general purpose surclasseranno il Cell.

I P4 però hanno ottenuto frequenze elevate aumentando a dismisura la lunghezza delle pipelines. Questo comporta un penalizzazione elevata in caso di svuotamento delle stesse e quindi giustifica lo sforzo profuso affinchè questo non avvenga (quindi OOO).

Per contro il Cell pare abbia pipelines più corte (anche se al momento questa informazione non è pubblica) e quindi le penalizzazioni in caso di svuotamento sarebbero più limitate e questo potrebbe giustificare in parte la rinuncia ad una implementazione OOO.

Insomma ognuno fa i suoi compromessi e le sue scelte per ottenere il massimo delle prestazioni, però per dire tout-court che il Cell è lento perché non è OOO, dimenticandosi tutto il resto, ce ne vuole.

Anche l'Alpha non era OOO e finchè lo hanno prodotto è sempre stato il processore più veloce. Anche Itanium non lo si può considerare OOO... Insomma ci possono essere approcci diversi allo stesso problema. Il Cell è sicuramente diverso da un P4 o anche da un PPC 970. Sarà più lento nel codice scalare? Io non credo, ma vedremo...

Ci rinuncio. Mi ha sfiancato.

Per contro il Cell pare abbia pipelines più corte (anche se al momento questa informazione non è pubblica) e quindi le penalizzazioni in caso di svuotamento sarebbero più limitate e questo potrebbe giustificare in parte la rinuncia ad una implementazione OOO.
E ha anche una unità di branch prediction abbastanza semplice. Questo è normale perchè la PPE è pensata per coordinare l'esecuzione delle SPE, e non per eseguire codice sequenziale. Non mi ricordo la quantità di cache della PPE, ma mi pare fosse minore rispetto agli x86, e questo è un altro fattore che penalizza l'esecuzione di codice sequenziale.
In più, come ha detto Fek, se devi eseguire codice sequenziale con Cell (usando solo la PPE) a questo punto conviene prendere un altro processore (che so, un G5), che è più piccolo, consuma meno e probabilmente è anche più veloce. Oppure riscrivere da zero il codice in modo da sfruttare al meglio le caratteristiche di Cell, ma capirai che questo può essere molto costoso.

Esiste un processore, mi pare della SPARC, chiamato Niagara. Più che processore è una architettura multicore, 4 o 8 o di più, non ricordo.

Ogni processore è semplificato al massimo. E' dualthread come i P4, ma non è OOO. Non effettua esecuzione speculativa, nè OOO: se un thread non può andare avanti, perchè aspetta un dato dalla memoria, si passa all'altro thread. Lì è detto che l'IPC medio dei P4 è circa una istruzione per ciclo. Per l'A64 è maggiore, ma il clock è inferiore. Con quell'approccio loro riescono ad avere un IPC di circa 0,8 per thread, ossia di poco inferiore al P4. Ma usano 2 thread e la frequelza mi pare che sia comparabile. Per loro stessa ammissione le prestazioni single thread sono inferiori ai processori moderni, ma, considerando anche che sono parecchi core, le prestazioni in multithreading sono molto alte. Poichè l'IPC medio del P4 è circa 1 e le frequenze sono comparabili, se il Cell ha un IPC comparabile, allora è buono. Mi pare di aver capito che esegue al massimo una istruzione per thread e per ciclo. Quindi sul monothread è inferiore al P4, perchè non ne può che eseguire al massimo 0,8, come il Niagara. Sul multithread potrebbe eguagliare il P4, ma anche lui ha l'Hyperthreading. Poichè un P4 se la gioca con un G5, possiamo dire che il Cell è inferiore al G5.

Punto.

Esiste un processore, mi pare della SPARC...

Beh 0,8 di IPC senza OOO vs 1,0 del P4 con OOO non mi sembra tutto questo abisso... anche considerando un valore un po' più basso di IPC per il Cell se tieni conto della notevole differenza di frequenza alla fine siamo lì come dicevo io...

state discutendo da 12 pagine senza avere dati certi su questo processore! Sn solo ipotesi le vostre! Nessuno può dire con certezza se sarà più o meno potente di un attuale pentium 4 o athlon64

2 operazioni per ciclo di clock non fanno schifo.
No, se è possibile eseguirle fuori ordine... ;)
Quante ne può fare teoricamente il G5, 3?
No, fino a 5 (CINQUE): strano che debba essere proprio io, utente PC, a dirti come funzionano i G5 dei tuoi cari Mac... :p
E considera che possono essere due istruzioni di 2 thread differenti,
Il PPE può eseguire due istruzioni per ciclo di clock. Punto. Poi non si sa ancora se sono due istruzioni di un solo thread, o una per ogni singolo thread: mancano informazioni in merito.
cosa che il G5 non può fare,
Per forza: non è SMT! Power5, invece, lo può fare benissimo... ;)
quindi sono più facilmente utilizzabili.
In che senso?
Inoltre il bus e la memoria del Cell è estremamente più veloce,
Sì, ma la latenza è anche superiore rispetto alle ram, quindi ogni thread aspetterà più tempo per portare a termine l'esecuzione del codice. E sai cosa succede a un processore che esegue le istruzioni solamente in ordine? Che il thread dovrà per forza FERMARSI ad aspettare il completamento dell'istruzione. Un processore con OOOE, invece, può eseguire le istruzioni seguenti, se non sono presenti dipendenze che lo forzino ad aspettare.
così come pure la frequenza.
Ovvio, ma non c'era qualcuno dalle tue parti che diceva che "la frequenza non è tutto"? ;)
Sono architetture molto differenti, è difficile dire sulla carta quale delle 2 è più veloce,
No, ma una buona stima la si può già fare A SECONDA DEL TIPO DI CODICE.
ma una cosa è certa: non ci sarà un abisso prestazionale tra un G5 attuale e una PPE del Cell.
Se è certa, ti prego di DIMOSTRARMELO: fammi vedere quanto veloce sarà la PPE a compilare un sorgente o a eseguire il MAME :D rispetto a un G5 attuale. Vogliamo scommettere una cena? Per me non c'è problema: sono una buona forchetta... :asd:
Potrà essere un po' più veloce una o l'altra, a seconda dei casi e dei compilatori.
Te l'abbiamo già detto: per il codice "generico" che è stato elencato, Cell non ha speranza di poter competere con un processore costruito appositamente per fare bene il suo lavoro. Viceversa, un processore general purpose non potrà comptere con Cell nell'eseguire codice di tipo stream.
Vuoi mettertelo in testa una volta per tutte?
Ma all'atto pratico saranno SIMILI.
Vedi sopra: DIMOSTRAMELO. Io non ho problemi a prenderti un qualunque pezzo di codice "classico" di un'applicazione e dimostrarti che un'architettura general purpose come un G4, G5, P4, Athlon, ecc. avrà sempre prestazioni migliori.
E quindi dire che il Cell è da escludere per un utilizzo general purpose perchè per il codice scalare fà schifo è sbagliato.
Non lo è affatto: è così. Prendine atto e metti una pietra sopra i tuoi sogni.
Inoltre i compiti della PPE saranno limitati rispetto ad un processore attuale, in quando per il lavoro pesante ci sono sempre altri gli altri 8 cores SPE.
Vedi? Ti sei risposto già da solo. :D Il PPE è l'equivalente di microcontroller dei sistemi embedded, ed è fatto per quello: COORDINARE il lavoro delle più potenti unità di esecuzione, adibite a compiti particolari.
Infine i Cell sono progettati per lavorare insieme ad altri Cell, quindi fare macchine con più di 1-2 processori dovrebbe essere molto più facile che con i processori attuali
E' chi lo nega questo? E' uno dei suoi punti di forza... ;)
e quindi si possono adattare bene anche per compiti che possono essere divisi in molti thread ma non sono vettorializzabili come la compilazione, che diceva Fek, o i database relazionali.
Già, ma ogni thread quanto ci metterebbe a portare a termine il lavoro? Meglio mettere assieme due processori general purpose per fare questo lavoro: lo faranno sicuramente meglio e più velocemente, no? E a un costo inferiore (non ha senso usare solamente il PPE di ogni Cell per questi compiti, "buttando a mare" le SPE ;)).

Non credo che possa comunque raccattare dalla memoria più di 2 istruzioni (128 bit) alla volta, quindi il limite teorico lascia il tempo che trova...
Il G5 legge una linea di cache L1 di 256 bit, che contiene 8 istruzioni PowerPC, da cui ne estrae (quindi fuori ordine) fino a 5 da eseguire.
Inoltre considera che anche il famoso Itanium può essere considerato una architettura "in order"...
Indubbiamente. Ma Itanium esegue fino a due bundle per ciclo di clock, ognuno contenente 3 istruzioni. Inoltre ha un sofisticato meccanismo basato su predittori ed esecuzione speculativa che gli permette di evitare il più possibile lo stallo della pipeline a causa di salti condizionati.

Mi sembra UN TANTINO DIVERSO dalle PPE di Cell, non credi? ;)

Perchè facedolo "più semplice" possono clockarlo a 4.6 Ghz invece dei 2.5Ghz a cui sono inchiodati ora con i PowerPC 970 (aka G5) realizzati con la stessa tecnologia (90nm).
"La frequenza non è tutto". Posso avere anche un processore che funziona a 10Ghz, ma se poi è in grado di fare soltanto semplici operazioni, non sarà un campione di prestazioni rispetto agli altri che lavorano a frequenze inferiori, ma che fanno molto più lavoro "utile" per ciclo di clock...

Questo, ripeto, dovresti saperlo, visto che è lo slogan di una certa casa produttrice di hardware... ;)
Inoltre semplificandolo hanno spazio per mettere altre unità nello stesso chip (9 nel Cell!) aumentando il parallelismo e quindi l'efficienza globale.
Infatti l'hanno per inserire le SPE, non altri PPE: chissà perché... ;)
Certo per alcuni algoritmi non parallelizzabili l'approccio dell'estrema ricerca del parallelismo per singolo thread (e quindi l'OOO) può risultare vincente.
Togli il "può". ;)
Ma non credo che i progettisti dell'IBM siano dei fessi avranno valutato i pro e i contro della cosa.
Esattamente. Ed è per questo che hanno progettato Cell: per essere un eccellente STREAM PROCESSOR. Ed è per questo che hanno progettato il Power5: per essere un eccellente GENERAL PURPOSE PROCESSOR.

Chiaro?
Per la cronaca ecco cosa pensa Ken Kuratagi, il capo della divisione entertaiment della Sony e ideatore del Cell, degli ingegneri IBM che hanno partecipato al progetto Cell "they orchestrated an all-star team for us. It was like lining up an Olympic athlete-class of engineers".
Tutta l'intervista può essere letta qui: http://techon.nikkeibp.co.jp/english/NEWS_EN/20050407/103542/
Letta. E allora?

I P4 però hanno ottenuto frequenze elevate aumentando a dismisura la lunghezza delle pipelines. Questo comporta un penalizzazione elevata in caso di svuotamento delle stesse e quindi giustifica lo sforzo profuso affinchè questo non avvenga (quindi OOO).
Embé? Nei calcoli "generl purpose" hanno comunque delle ottime prestazioni.

Comunque dimentichi anche gli Athlon, i Pentium-M, i G4, ecc. che hanno pipeline più corte, frequenze meno elevate, ma sono più efficienti.
Per contro il Cell pare abbia pipelines più corte (anche se al momento questa informazione non è pubblica)
Sì, sono più corte, ma si sa ancora di quanto.
e quindi le penalizzazioni in caso di svuotamento sarebbero più limitate e questo potrebbe giustificare in parte la rinuncia ad una implementazione OOO.
Sì, sono più limitate, ma AVVENGONO MOLTO PIU' FREQUENTEMENTE, visto che il PPE esegue codice solamente in ordine.
Insomma ognuno fa i suoi compromessi e le sue scelte per ottenere il massimo delle prestazioni,
Certamente, ma A SECONDA DEL CAMPO D'UTILIZZO.
però per dire tout-court che il Cell è lento perché non è OOO, dimenticandosi tutto il resto, ce ne vuole.
Infatti nessuno ha mai detto questo: il contesto era BEN CHIARO. Si parlava di esecuzione GENERAL PURPOSE.
Anche l'Alpha non era OOO
Lo era.
e finchè lo hanno prodotto è sempre stato il processore più veloce. Anche Itanium non lo si può considerare OOO...
No, ma Itanium funziona in modo completamente diverso: ha un altro approccio per risolvere gli stessi problemi (l'esecuzione di codice general purpose).
Insomma ci possono essere approcci diversi allo stesso problema.
Esatto. E Cell è un ottimo approccio per l'esecuzione di codice parallelizzabile e distribuibile...
Il Cell è sicuramente diverso da un P4 o anche da un PPC 970. Sarà più lento nel codice scalare? Io non credo, ma vedremo...
Io lo credo benissimo, invece, e non ho bisogno di aspettare per toccare con mano.

Ci rinuncio. Mi ha sfiancato.
Io no: voglio vedere dove arriva... :D

Tanto lo so che lo fa perché spera che il Cell possa essere usato nei futuri Mac, e quindi prendere a sberle i PC dal punto di vista prestazionale...

Quant' è bello sognare... :D :D :D

Beh 0,8 di IPC senza OOO vs 1,0 del P4 con OOO non mi sembra tutto questo abisso...
Per te no. Per le applicazioni reali, sì... ;)
anche considerando un valore un po' più basso di IPC per il Cell se tieni conto della notevole differenza di frequenza alla fine siamo lì come dicevo io...
Scommettiamo? Ho già l'acquolina in bocca... :sbav:

Io no: voglio vedere dove arriva... :D

Tanto lo so che lo fa perché spera che il Cell possa essere usato nei futuri Mac, e quindi prendere a sberle i PC dal punto di vista prestazionale...


A me è cdimauro che mi sfianca.
Abbandono anch'io :)
Comunque per il Cell sul MacMini entro Natale 2006 possiamo sempre scommettere...

A me è cdimauro che mi sfianca.
Abbandono anch'io :)
Comunque per il Cell sul MacMini entro Natale 2006 possiamo sempre scommettere...

Quanto vuoi. 1000 euro? 2000 euro? 3000 euro? Fai tu la cifra. (Soldi facili ragazzi :D)

Quanto vuoi. 1000 euro? 2000 euro? 3000 euro? Fai tu la cifra. (Soldi facili ragazzi :D)

'Na pizza? :D

Insomma entro 1 anno escono 2 consolle: una con 3 PowerPC da 3Ghz, e un'altra con un PowerPC da 256Gflops...

Come può la Apple continuare a vendere Mac con i G4?!?!?!
Qualcosa si deve inventare... E poi la PPE del Cell ha Altivec: è FATTA per Apple!

Inviato da: Criceto
Comunque per il Cell sul MacMini entro Natale 2006 possiamo sempre scommettere...

:doh: Ahi ahi... era meglio se non lo dicevi.

Se lo vede Cesare... :muro:

;)

Cmq...mi permetto di scommettere con Fek...scegliete voi la quota :D

'Na pizza? :D

Insomma entro 1 anno escono 2 consolle: una con 3 PowerPC da 3Ghz, e un'altra con un PowerPC da 256Gflops...

Come può la Apple continuare a vendere Mac con i G4?!?!?!
Qualcosa si deve inventare... E poi la PPE del Cell ha Altivec: è FATTA per Apple!


Non certo una pizza. E mi perdo questa possibilita' di spennare un pollo? (senza offesa, e' solo per scherzare) :D

Alza alza, ci scommettiamo un bell'i-book ultima generazione a fine 2006. Se vinci tu te ne compro due, se vinco io me ne compri uno solo.

Soldi facili ragazzi :D

Non certo una pizza. E mi perdo questa possibilita' di spennare un pollo? (senza offesa, e' solo per scherzare) :D

Alza alza, ci scommettiamo un bell'i-book ultima generazione a fine 2006. Se vinci tu te ne compro due, se vinco io me ne compri uno solo.

Soldi facili ragazzi :D

Comuqnue nel frattempo pare esserci una nuova versione di Cell con la PPE più grossa!!
https://www-03.ibm.com/chips/photolibrary/press/1001.jpg

Ecco il confronto con quello "vecchio"...
http://img207.echo.cx/my.php?image=ppecorecomparision6to.jpg

I transistor di conseguenza sono un po' aumentati:

Code Name = DD2
Size:235mm2
Tape Out: end of 2004
Transitor:250 million
New feature:CPU core can do 2 Order at the same time.

First gen Cell:
Code Name = DD1
Size:221mm2
Transistor:234 million

Non più molto!!

prototype:

1 VMX
1 FPU
1 INT ALU
2 instrtuctions/cycle
2 thread
32 Gflops at 4 Ghz

new modell:

1 full VMX
1 extra multiply-add VMX unit
1 FPU
2 INT ALU
4 instructions/cycle
2 thread
64 Gflops at 4 Ghz

Non certo una pizza. E mi perdo questa possibilita' di spennare un pollo? (senza offesa, e' solo per scherzare) :D

Alza alza, ci scommettiamo un bell'i-book ultima generazione a fine 2006. Se vinci tu te ne compro due, se vinco io me ne compri uno solo.


Sicuro di volerla ancora fare la scommessa?! ;)

xò adesso la scommessa la dovete fare :D

Un Ibook a che vince... il forum è testimone :ciapet:

Sicuro di volerla ancora fare la scommessa?! ;)


Ovvio. Ti regalo 2 i book ed una manciata di macmini a tua scelta se entro natale 2006 esce un mac mini che monta il Cell :D
Io mi accontento di un solo i book ultimo modello se non questo non succede.

C'e' tutto il forum testimone :)

Soldi facili ragazzi :D

.....se vi avanza un terzo già che ci siamo nn dico di no.... :) :D

BYEZZZZZZZZZZZZ

ho letto ora il thread.... e ancora mi sto chiedendo come abbia fatto a sfuggirmi l' appassionante diatriba fek - Criceto e alcune perle ivi contenute (stupendo e perfettamente calzante l' esempio del frigo e del forno... :D ) :confused:

In ambito casalingo ormai gli utilizzi che ci spingono ad acquistare un computer più veloce sono il poter giocare con gli MP3, ritoccare foto digitali, editare filmati, giocare con videogiochi 3D e simili e magari poter fare tutto questo insieme. In ambiente scientifico poter fare simulazioni sempre più complesse. Non sono certo i word processor o i programmi di email il problema. Ma come tu mi insegni sono il 20% delle persone che hanno l'80% dei soldi, sono il 20% degli utenti internet che utilizzano l'80% della banda ...
E sono il 20% degli algoritmi che richiedono l'80% della potenza di un processore. Il Cell è ottimizzato per quel 20%, i processori attuali per il restante 80% di cui ce n'è scarso bisogno.

certo, ma questo varrà per una certa parte dell' utenza, interessata a un sottoinsieme di tutti i problemi computabili ...
al che la domanda nasce spontanea: quel 20% di persone, che avendo accesso all' 80% delle risorse finaziarie totali, non trarrebbero maggior beneficio/"godimento" dal tagliare la testa al toro e acquistare (tanto se lo possono permettere, e chi non se lo può permettere, con buona probabilità appartiene alla categoria che ha ben altro per la testa che gli mp3 o il fotoritocco) due "scatole" separate, una contenente Cell, e una basata su una "normale" cpu dual core general purpose? :stordita:
se è pressochè evidente che le esigenze del pubblico benestante sono variegate e in evoluzione, in base a cosa deve esistere e in base a cosa si stabilisce l' ottimalità di apparecchio che sia perfetto per qualunque tipo di calcolo e ambito di utilizzo? :wtf:
Beh 0,8 di IPC senza OOO vs 1,0 del P4...
:mbe: avrei giurato che l' ipc , anche media, del pentium fosse maggiore...
a meno che non ci si riferisca a sw composti da istruzioni x86 complesse o floating point o SSE(2), nel qualcaso willamette e northwood non possono sfruttare le alu a doppia frequenza (usate per le istr. intere "semplici")ma la alu singola collegata alla rom del microcodice, oppure quella vettoriale.. (prescott invece modifica la pipeline e l' execution pool assegnando le operazioni che la alu speciale fa in più, a stadi posti prima dello scheduler, quindi rendendo tutte le u-ops in uscita dallo scheduler, eseguibili dalle alu normali )
o a meno che non ci si riferisca a quante istruzioni x86 possono entrare a ogni ciclo, nel decoder, che sì non è superscalare, ma (come noto) è fuori dal loop primario perchè posto a monte della cache ETC... cache ETC da cui escono 3 o 6 u-ops per volta, (3 se la cache line non è piena, ma con hyperthreading sono molto maggiori le probabilità di avere linee di cache completamente sfruttate)...
quindi, in base a cosa, si è preso IPC= 1 per il pentium 4? :wtf:

In base a questo articolo:

http://www.aceshardware.com/read.jsp?id=65000296

a pagina 5, verso la fine, uno Xeon ha un IPC medio di 0.5, su codice per server, dovuto ai cache miss!!! :eekk:

Consiglio, comunque, di leggere tutto l'articolo ed i suoi collegati...

Soprattutto perchè lo 0.7-0.8 IPC per core del Niagara è se si usa software che "riempie" tutti e 4 i thread per il singolo core...

Il numero di registri nell'architettura x86 (a 32 bit) è di 8, mentre in quella x86-64 è di 16. Comunque buona parte dei problemi "parallelizzabili" non usa molti registri: considera che già un solo registro è in grado di contenere 4 dati in virgola mobile a 32 bit (e addirittura 16 interi a 8 bit, 8 interi a 16 bit, ecc.).

Le capacità di calcolo sono simili: SSE (ma anche le "vecchie" 3DNow! di AMD) e Altivec sono in grado di effettuare 4 operazioni sui 4 dati per ciclo di clock. Altivec è più efficiente perché permette di usare 4 registri per ogni operazione, di cui uno con una maschera da applicare. Comunque l'uso di queste caratteristiche dipende strettamente dall'algoritmo da implementare.

Il numero di operazioni, invece, è superiore nel caso delle SSE: ne conta più di 200, se non erro. Ma non è la quantità di operazioni a fare la differenza fra due implementazioni SIMD, quanto piuttosto cosa fanno, e da questo punto di vista fanno più o meno le stesse cose. In più le SSE hanno anche un set di istruzioni scalari, che permette di fare a meno di passare dall'uso delle SIMD a quello dell'FPU x87 quando i calcoli si devono effettuare su un solo dato alla volta; cosa inutile per i G4 e G5, in quanto già dotati di un'ottima FPU (comunque gl Athlon, e in particolare gli Athlon64, sono molto efficienti anche sul codice x87).

Su http://it.wikipedia.org/wiki/AltiVec si dicono cose abbastanza diverse:
Quando è stato presentato AltiVec era il migliore sistema SIMD disponibile per per personal computer. Gli equivalenti prodotti della Intel non erano confrontabili. l'MMX non lavorava in virgola mobile ma trattava solamente numeri interi mentre l'SSE pur trattando i numeri in virgola mobile era molto più lento e limitato dell'AltiVec. Alla fine la quarta versione di sistema SIMD dell'Intel l'SSE2 risolse la maggior parte dei problemi e adottò molte delle soluzioni utilizzata dall'AltiVec.

AltiVec e SSE2 utilizzano dei registri a 128 bit. Questi registri sono in grado di rappresentare 16 dati a 8 bit con o senza segno, otto dati a 16 bit con o senza segno e quattro dati a 32 bit con o senza segno che possono essere anche in virgola mobile. Inoltre dispongono di un gestore della cache delle istruzioni che provvede a organizzare le istruzioni in modo da minimizzare i conflitti di accesso alla memoria.

A differenza di SSE2 AltiVec supporta direttamente la gestione dei pixel con la modalità RGB nativa che non si appoggia alla gestione a 64 bit del processore. Adeguandosi alla filosofia RISC del PowerPC le istruzioni AltiVec sono in grado di manipolare esclusivamente i dati immagazzinati nei registri ma a differenza del SSE2 non esistono registri speciali e tutte le operazioni possono utilizzare tutti i registri. L'unità di calcolo AltiVec è dotata di 32 registri a 128 bit a differenza dei 8 registri a 128 dell'unità SSE2 e quindi è in grado di trattare un maggior numero di informazioni prima di dover accedere alla memoria centrale. Inoltre molte operazioni AltiVec sono in grado di utilizzare tre registri contemporaneamente a differenza dell'SSE2 che può utilizzare al massimo due registri contemporaneamente.

Le ultime versioni del compilatore GNU e del compilatore dell'IBM il Visual Age sono in grado di compilare codice in grado di avvantaggiarsi delle istruzioni AltiVec. Il compilatore si preoccupa di fornire delle primitive ad alto livello al programmatore in modo che questo possa scrivere un programma in C che si avvantaggi dell'unità di calcolo. Il programmatore deve solo definire la tipologia di dato da trattare e le operazioni da eseguire e poi il compilatore provvede a realizzare il codice più appropriato, utilizzando le istruzioni corrette e provvedendo a immagazzinare i dati nella modalità migliore per il processore.

Per quanto riguarda The Cell mi pare un buon sistema integrato CPU+GPU per una console di videogiochi. Nel mondo dei pc si è visto che il sistema SLI delle schede video consente incrementi prestazionali elevatissimi e che l'introduzione (nel 2001) delle GPU programmabili è stata una scelta azzeccata. Le 8 SPE (con 4 FPU, 128 registri SIMD a 128bit, ...) si dovrebbero comportare in modo analogo a 8 GPU programmabili messe in SLI.
L'assenza di informazioni dettagliate sull'ISA delle SPE, secondo me, non dovrebbe preoccupare più di tanto visto che saranno supportate dalle OpenGL ES. L'ISA delle SPE sarà preoccupazione di chi scrive i driver, non di chi programma i giochi o le applicazioni. Anche nel mondo dei pc avviene una cosa analoga: non è mica necessario conoscere l'ISA delle varie GPU per programmare un'applicazione grafica, ci sono delle librerie che se ne preoccupano!

Su http://it.wikipedia.org/wiki/AltiVec
Per quanto riguarda The Cell mi pare un buon sistema integrato CPU+GPU per una console di videogiochi.


Cell non fara le veci della GPU nella PS3. Ci sara' anche una GPU.


Nel mondo dei pc si è visto che il sistema SLI delle schede video consente incrementi prestazionali elevatissimi e che l'introduzione (nel 2001) delle GPU programmabili è stata una scelta azzeccata. Le 8 SPE (con 4 FPU, 128 registri SIMD a 128bit, ...) si dovrebbero comportare in modo analogo a 8 GPU programmabili messe in SLI.

No, 8 GPU a 12 pipeline l'una (ogni pipeline e' grossomodo l'equivalente di un SPE ma specializzato e quindi molto piu' performante nelle operazioni di rasterizzazione) surclasserebbero di piu' di un ordine di grandezza un solo Cell. Una sola GPU con il succitato numero di pipeline sarebbe gia' molto piu' performante di un singolo Cell con 8 SPE.
Parlo a spanne, perche' ovviamente bisognerebbe considerare le frequenze alle quali girano.

Cell non fara le veci della GPU nella PS3. Ci sara' anche una GPU.

Lo so. Una GPU della Nvidia per la precisione. D'altra parte le 8 SPE funzioneranno come delle GPU interne al processore sgravando GPU esterna di gran parte del lavoro.
E' anche riportato nella Wikipedia:
http://it.wikipedia.org/wiki/Cell
L'architettura di Cell prevede l'incorporazione di più elementi base (1 PE più 8 GPU) in un solo chip. IBM ha presentato il brevetto di un'unità formata da quattro unità base in grado di sviluppare in teoria 1 Teraflop. Non è chiaro quante unità base verranno incluse nella PlayStation 3 o nei chip per computer.

No, 8 GPU a 12 pipeline l'una (ogni pipeline e' grossomodo l'equivalente di un SPE ma specializzato e quindi molto piu' performante nelle operazioni di rasterizzazione) surclasserebbero di piu' di un ordine di grandezza un solo Cell.

Certo, ma costerebbero molto si più!

Una sola GPU con il succitato numero di pipeline sarebbe gia' molto piu' performante di un singolo Cell con 8 SPE.

Perchè? 8 SPE clockate a 4Ghz e passa con 4 FPU, 2 istruzioni/clock e 128 registri SIMD dovrebbero riuscire a fare il loro sporco lavoro...
Solo pensando al fatto che 8 SPE con 2 istruzioni/clock ognuna porta già a 16 pipelines di esecuzione. Pensando poi che le attuali GPU arrivano a circa 0.5 GHz contro gli oltre 4 Ghz delle SPE, penso che il confronto sarebbe impari...

che confusione ragazzi :D

la GPU fa UNA cosa, fare paragoni tra i 4 ghz del cell (tra l'altro, li voglio vedere prima) e i 500 mhz di una GPU è un po' come paragonare i 30 mila giri che fa il motorino di un aereo radiocomandato e i 5000 giri di una ford mustang da 6000 di cilindrata...

GPU - VPU - CPU: ognuno di questi fa cose DIVERSE e nel suo campo - indipendentemente dagli hz - è il più bravo :D usare cell per elaborare grafica o per applicazioni general purpose non è una grande trovata, mentre per gestire che so la fisica di un gioco è eccezionale; usare una scheda video per far girare applicazioni general purpose o per gestire la fisica di un gioco non è una grande trovata, ma a manipolare scene 3d è eccezionale; usare una CPU per il 3d o per la fisica non è il max, mentre per le applicazioni general purpose spacca.

è tanto difficile? ognuno ha un suo segmento e che il cell è mooolto interessante NEL SUO e non in quello altrui: semplice no? :D

scusa, tanto per dire... ma a chi è mai venuto in mente di usare altivec al posto della scheda video?

Lo so. Una GPU della Nvidia per la precisione. D'altra parte le 8 SPE funzioneranno come delle GPU interne al processore sgravando GPU esterna di gran parte del lavoro.
E' anche riportato nella Wikipedia:
http://it.wikipedia.org/wiki/Cell
L'architettura di Cell prevede l'incorporazione di più elementi base (1 PE più 8 GPU) in un solo chip. IBM ha presentato il brevetto di un'unità formata da quattro unità base in grado di sviluppare in teoria 1 Teraflop. Non è chiaro quante unità base verranno incluse nella PlayStation 3 o nei chip per computer.

Quello che e' scritto su wikipedia non e' il Vangelo, spesso ci sono scritte molte fesserie e questo e' uno di quei casi. Chi ha scritto questo passaggio ha le idee molto confuse, perche' un SPE non equivale ad una GPU, ma grosso modo ad una piccola parte castrata di una delle pipeline di una GPU. Ne parlo dopo.


Certo, ma costerebbero molto si più!

Un Cell costerebbe piu' di una GPU e sarebbe molto meno performante a fare il lavoro della GPU. Tanto e' vero che sulla PS3 ci sara' anche una GPU.


Perchè? 8 SPE clockate a 4Ghz e passa con 4 FPU, 2 istruzioni/clock e 128 registri SIMD dovrebbero riuscire a fare il loro sporco lavoro...
Solo pensando al fatto che 8 SPE con 2 istruzioni/clock ognuna porta già a 16 pipelines di esecuzione. Pensando poi che le attuali GPU arrivano a circa 0.5 GHz contro gli oltre 4 Ghz delle SPE, penso che il confronto sarebbe impari...

Il confronto e' impari a favore di una GPU dedicata:

In particolare questo passagio:
Solo pensando al fatto che 8 SPE con 2 istruzioni/clock ognuna porta già a 16 pipelines di esecuzione.

E' un errore madornale perche' suppone che una pipeline di una GPU sia in grado di svolgere solo un'operazione per colpo di clock. Non e' proprio cosi'.
Ad esempio una pipeline di un NV40 e' in grado di svolgere in un solo colpo di clock (cito a memoria, se qualcuno vuole controllare magari sbaglio qualcosa qui):

- 2 operazioni ALU su dati vettoriali a 16 o 32 bit per componente
- una normalizzazione vettoriale (sono 4 moltiplicazioni e 3 addizioni)
- un texture fetch (accesso a memoria) con filtraggio bilineare, ovvero altre 4 addizioni ed una moltiplicazione vettoriale
- un'operazione di blend, ovvero due moltiplicazioni ed un'addizioni piu' due accessi a memoria

Ed e' in grado di svolgere tutto cio' strettamente OutOfOrder, nascondendo le latenze degli accessi a memoria parcheggiando decine di "thread di esecuzione" in maniera trasparente.

Inoltre c'e' hardware dedicato per le conversioni di dati da fixed a floating point e viceversa che sono gratuite. Piu' istruzioni di branching dynamico.

Sommando il tutto si tratta di un numero di operazioni da 10 a 20 volte superiore a quelle di un SPE del Cell e parlo di una pipeline sola di una GPU in commercio da piu' di un anno ormai. Per quando uscira' il Cell in commercio si parla di GPU clockate a 1ghz con pipeline riconfigurabili e clockate al doppio, 2 ghz, in grado di effettuare tutte le operazioni che ho elencato e anche qualcosa di piu' immagino.

Se capisci il ragionamento, gia' un NV40 nel fare la GPU e non in generale surclassa un Cell oggi, fra un anno le GPU future si metteranno i Cell nel taschino e li suoneranno come delle zampogne.

Ancora convinto che il Cell possa fare da GPU con le sue due istruzioncine in order per colpo di clock per SPE? :)

Per altro considera che ho descritto solo una parte piccola della pipeline grafica, ignorando tutta una serie di operazioni (zbuffering gerarchico, alpha testing, stencil) che in una GPU sono svolte da unita' specializzate ed ottimizzate che lavorano in parallelo al resto mentre su un Cell dovrebbero essere programmate a mano. E smazzarsi uno zbuffer gerarchico non e' un'operazioncina.

la GPU fa UNA cosa, fare paragoni tra i 4 ghz del cell (tra l'altro, li voglio vedere prima) e i 500 mhz di una GPU è un po' come paragonare i 30 mila giri che fa il motorino di un aereo radiocomandato e i 5000 giri di una ford mustang da 6000 di cilindrata...

Non è proprio così. Sempre basandomi su wikipedia che è una fonte imparziale ed affidabile:
http://it.wikipedia.org/wiki/Cell
Le moderne schede grafiche sono dotate di un unità di elaborazione e di molte unità dedicate alle gestione della grafica poligonale. Queste unità dispongono di un accesso alla memoria molto rapido e spesso sono in grado di condividere delle zone di memoria. Cell estende questa architettura, le unità SPU sono molto più flessibili e potenti delle unità dedicate all'elaborazione dei poligoni e la loro possibilità di comunicazione e sincronizzazione è notevolmente superiore a quella di qualsiasi scheda grafica. Non stupisce quindi che Cell venga utilizzata nella PlayStation 3 per realizzare la più potente accoppiata CPU scheda grafica che una console abbia mai visto.

GPU - VPU - CPU: ognuno di questi fa cose DIVERSE e nel suo campo

Questo è ovvio ma tieni conto che, dal punto di vista dell'architettura, le SPE (o SPU che dir si voglia) assomigliano più ad una GPU che ad una CPU...

usare cell per elaborare grafica o per applicazioni general purpose non è una grande trovata

Su questo molti dissentono tanto che c'è chi pensa che Cell potrebbe riuscire addirittura a fare il ray tracing di una scena in tempo reale!

[completerò la risposta dopo, ora devo andare ad allenamento di judo]

Non è proprio così. Sempre basandomi su wikipedia che è una fonte imparziale ed affidabile:
http://it.wikipedia.org/wiki/Cell
Le moderne schede grafiche sono dotate di un unità di elaborazione e di molte unità dedicate alle gestione della grafica poligonale. Queste unità dispongono di un accesso alla memoria molto rapido e spesso sono in grado di condividere delle zone di memoria. Cell estende questa architettura, le unità SPU sono molto più flessibili e potenti delle unità dedicate all'elaborazione dei poligoni e la loro possibilità di comunicazione e sincronizzazione è notevolmente superiore a quella di qualsiasi scheda grafica. Non stupisce quindi che Cell venga utilizzata nella PlayStation 3 per realizzare la più potente accoppiata CPU scheda grafica che una console abbia mai visto.

Come ti ho detto prima, quello che ha scritto questo pezzo non ha la piu' pallida idea di quello che sta scrivendo.

Questo è ovvio ma tieni conto che, dal punto di vista dell'architettura, le SPE (o SPU che dir si voglia) assomigliano più ad una GPU che ad una CPU...


No.


Su questo molti dissentono tanto che c'è chi pensa che Cell potrebbe riuscire addirittura a fare il ray tracing di una scena in tempo reale!

Di una scena di 10 poligoni. Ce la fa anche un Pentium III.

Non è proprio così. Sempre basandomi su wikipedia che è una fonte imparziale ed affidabile:
Gli articoli su Cell, in italiano e in inglese, sono abbastanza vaghi e imprecisi. E' comprensibile, dal momento che su Cell non si sa ancora molto, ma è un motivo in più per prendere con cautela quello che c'è scritto.

Questo è ovvio ma tieni conto che, dal punto di vista dell'architettura, le SPE (o SPU che dir si voglia) assomigliano più ad una GPU che ad una CPU...
Più che altro a un'unità vettoriale. Come ha detto Fek, le GPU hanno moltissime unità dedicate a compiti molto specifici, come conversione dei dati, texture blending, alpha blending, zeta-test... che con Cell invece dovrebbero essere emulate (con spreco di cicli di clock). Inoltre anche le unità shader hanno istruzioni specifiche (esempio, normalizzazione di un vettore) che possono essere eseguite in 1-2 cicli di clock.
Infatti le GPU sono ASIC, e quindi ottimizzate per il loro compito. Se devo fare Global Illumination, Cell ovviamente mi straccia tutte le GPU esistenti, perchè è più flessibile.

Su questo molti dissentono tanto che c'è chi pensa che Cell potrebbe riuscire addirittura a fare il ray tracing di una scena in tempo reale!
Ho trovato dei paper su tecniche di raytracing realtime, con alcuni trucchi (image warping + calcolo pixel mancanti) si riesce a raggiungere prestazioni quasi realtime con cluster di Opteron su immagini complesse (esempio, albero con un miliardo di poligoni). Tuttavia rimane sempre il problema di gestire la struttura dati, che se da un lato permette al raytracing di scalare meglio con scene complesse (log n invece che n nel numero di poligoni) dall'altro in realtime richiede il continuo aggiornamento della struttura della scena in base al punto di osservazione, che alla fine domina il tempo di rendering.

EDIT: visto che è sempre bene includere le fonti ecco il sito:
http://www.openrt.de/Resources/index.html

allora

premesso che se ricordo bene c'era una demo fatta in assembler puro che in 64 KB di .exe faceva il ray tracing in tempo reale su pc di qualche generazione fa (mi sembra di averla vista su un 386 a 40 mhz) e quindi dire "ray tracing in tempo reale" è un po' vago

premesso questo, se secondo te il ray tracing è general purpose OPPURE è una cosa che normalmente ti fa una scheda video siamo a posto. ripeto, prova a seguire la distinzione CPU - VPU - GPU che forse le cose ti si chiariranno meglio :D

detto ciò, come ha consigliato fek faresti bene a cercare altri "fonti del sapere" perchè la parte che hai quotato tu tratta dalla wikipedia è una castroneria bella e buona.

premesso che se ricordo bene c'era una demo fatta in assembler puro che in 64 KB di .exe faceva il ray tracing in tempo reale su pc di qualche generazione fa (mi sembra di averla vista su un 386 a 40 mhz) e quindi dire "ray tracing in tempo reale" è un po' vago

Ovviamente stiamo parlando del core di una console di videogiochi quindi il concetto non è per niente vago. Si parla del ray tracing in tempo reale di ogni singolo fotogramma di un videogioco alla risoluzione massima prevista per la console che penso sia quello della HDTV a 1080 linee.

detto ciò, come ha consigliato fek faresti bene a cercare altri "fonti del sapere" perchè la parte che hai quotato tu tratta dalla wikipedia è una castroneria bella e buona.

Andate a correggerla, allora. Wikipedia è un'enciclopedia libera accessibile a tutti. Comunque molti concordano con la descrizione della wikipedia.
http://www.blachford.info/computer/Cells/Cell4.html
The PC does have a weapon with which to respond, the GPU (Graphics Processor Unit). On computational power GPUs will be the only real competitors to the Cell.

GPUs have always been massively more powerful than general purpose processors [PC + GPU][GPU] but since programmable shaders were introduced this power has become available to developers and although designed specifically for graphics some have been using it for other purposes. Future generations of shaders promise even more general purpose capabilities[DirectX Next].

GPUs operate in a similar manner to the Cell in that they contain a number of parallel vector processors called vertex or pixel shaders, these are designed to process a stream of vertices of 3D objects or pixels but many other compute heavy applications can be modified to run instead [EE-GPU].

With aggressive competition between ATI and Nvidia the GPUs are only going to get faster and now "SLI" technology is being used again to pair GPUs together to produce even more computational power.

GPUs will provide the only viable competition to the Cell but even then for a number of reasons I don't think they will be able to catch the Cell.

Cell is designed from the ground up to be more general purpose than GPUs, the APUs are not graphics specific so adapting non 3D algorithms will likely mean less work for developers.

Cell has the main general purpose PU sharing the same fast memory as the APUs. This is distinct from PCs where GPUs have their own high speed memory and can only access main system memory via the AGP bus. PCI Express should speed this up but even this will be limited due to the bus being shared with the CPU. Additionally vendors may not fully support the PCI Express specification, existing GPUs are very slow at moving data from GPU to main memory.

Ovviamente stiamo parlando del core di una console di videogiochi quindi il concetto non è per niente vago. Si parla del ray tracing in tempo reale di ogni singolo fotogramma di un videogioco alla risoluzione massima prevista per la console che penso sia quello della HDTV a 1080 linee.

Fantascienza.


Andate a correggerla, allora. Wikipedia è un'enciclopedia libera accessibile a tutti. Comunque molti concordano con la descrizione della wikipedia.

Hai letto quello che ho scritto sulle GPU moderne?

E' inutile che posti link se non riesci a capire quando dicono fesserie. Una cosa non diventa automaticamente vera "solo perche' e' scritta su internet".

Affermare che il Cell puo' svolgere i compiti di una GPU dello stesso periodo piu' velocemente vuol dire non sapere di che cosa si stia parlando, per i motivi che ho elencato in un post precedente. Ed anche chi ha scritto questo testo che hai postato non sa di che cosa sta parlando, perche' non sa come funziona internamente una GPU, altrimenti non scriverebbe cio' che ha scritto. In particolare quando parla di bus AGP e PCI-E dimostra di non aver mai scritto due righe di codice 3d in vita sua.

allora

premesso che se ricordo bene c'era una demo fatta in assembler puro che in 64 KB di .exe faceva il ray tracing in tempo reale su pc di qualche generazione fa (mi sembra di averla vista su un 386 a 40 mhz) e quindi dire "ray tracing in tempo reale" è un po' vago

premesso questo, se secondo te il ray tracing è general purpose OPPURE è una cosa che normalmente ti fa una scheda video siamo a posto. ripeto, prova a seguire la distinzione CPU - VPU - GPU che forse le cose ti si chiariranno meglio :D


tieni conto che già dire "raytracing" in realtà è vago, in quanto l' algoritmo basilare che emette un raggio dall' osservatore verso gli oggetti 3d presenti nella scena è semplice e codificabile in un listato piuttosto breve...
il RT ha lo svantaggio di essere ricorsivo (quando un raggio primario colpisce un oggetto, dal punto di intersezione si dipartiranno vari altri raggi, alcuni diretti verso le sorgenti di luce presenti per determinarne l' influenza o meno), e quindi, scarsamente deterministico (non so a priori quanto tempo richiederà il rendering di un frame di un' animazione, a meno di non fissare dei limiti al numero di iterazioni e raggi secondari), ma il vantaggio di inglobare le funzioni di "ordinamento" della geometria (i raggi primari intersecheranno gli oggetti più vicini all' osservatore, che saranno quindi quelli di cui verrà calcolato il colore per il pixel corrente... a meno di trasparenze, nel qual caso genererò dei raggi secondari per il calcolo dell' effetto rifrattivo, ecc ecc)

questo per dire che, per pochi raggi (a che risoluzione andava la demo all' epoca, 320x200? quanti oggetti e fonti di luce c' erano ? io ricordo solo un toroide e uno spot..), nessuna iterazione secondaria, un po' di assembly 386 ben fatto, non trovo così eclatante che quella demo funzionasse su 386 o 486...

invece, se un algoritmo RT, "esteso" ai canoni odierni ( dotato magari di caratteristiche come la global illumination, oltre alle ormai "banali" ombre portate, riflessioni e trasparenze) riuscisse a girare in tempo reale per una scena tridimensionale generica (invece di una situazione perettamente nota a priori) , lo troverei assai eclatante

a) si parla di 1080i per il cell quando non si ha la più pallida idea di quale sarà la risoluzione "standard" della ps3, mentre si sa già che l'xbox 360 avrà come standard il 720i - che voglio dire, è già un'esagerazione per il mercato a cui si rivolge
b) le cazzate che si sono sparate e si sparano attorno al cell sono incredibili e hanno come unica spiegazione che dietro ci sono IBM e Sony, due colossi indiscussi del vaporware :D dapprima si diceva che avrebbero soppiantato gli x86, ora sento che invece soppianteranno le schede video... fatemi indovinare, ora ci diranno che soppianteranno gli hard disk e i monitor, e poi... TOMBOLAAAA :D
c) fantoibed, come giustamente dice fek, non è che se trovi scritta una cosa in giro per internet allora questa è vera, anzi, bisogna stare particolarmente attenti: perchè al posto di cercare in giro (facci caso, troverai scritto DI TUTTO e IL CONTRARIO DI TUTTO) non provi a pensare che magari anche quello che scrive fek (io mi tiro fuori) può essere autorevole (e forse di più di quello che trovi scritto in giro) e che quindi vale la pena di essere ascoltato? hai pure l'occasione di CHIEDERE se qualcosa non ti è chiaro, se ciò che fek dice non si regge in piedi lo scopri subito, se invece ne sa per davvero il suo discorso non farà una grinza, come mi pare sia

tieni conto che già dire "raytracing" in realtà è vago, in quanto l' algoritmo basilare che emette un raggio dall' osservatore verso gli oggetti 3d presenti nella scena è semplice e codificabile in un listato piuttosto breve...

sono assolutamente d'accordo, infatti quando dicevo:

quindi dire "ray tracing in tempo reale" è un po' vago

intendevo esattamente questo

il RT ha lo svantaggio di essere ricorsivo (quando un raggio primario colpisce un oggetto, dal punto di intersezione si dipartiranno vari altri raggi, alcuni diretti verso le sorgenti di luce presenti per determinarne l' influenza o meno), e quindi, scarsamente deterministico (non so a priori quanto tempo richiederà il rendering di un frame di un' animazione, a meno di non fissare dei limiti al numero di iterazioni e raggi secondari), ma il vantaggio di inglobare le funzioni di "ordinamento" della geometria (i raggi primari intersecheranno gli oggetti più vicini all' osservatore, che saranno quindi quelli di cui verrà calcolato il colore per il pixel corrente... a meno di trasparenze, nel qual caso genererò dei raggi secondari per il calcolo dell' effetto rifrattivo, ecc ecc)

questo per dire che, per pochi raggi (a che risoluzione andava la demo all' epoca, 320x200? quanti oggetti e fonti di luce c' erano ? io ricordo solo un toroide e uno spot..), nessuna iterazione secondaria, un po' di assembly 386 ben fatto, non trovo così eclatante che quella demo funzionasse su 386 o 486...

no, non era solo un toroide e uno spot, c'erano anche altri oggetti, mi sembra delle sfere... ovvio: era molto semplice, però ti garantisco che per i tempi eclatante lo era comunque... non avevi VPU eh :D

invece, se un algoritmo RT, "esteso" ai canoni odierni ( dotato magari di caratteristiche come la global illumination, oltre alle ormai "banali" ombre portate, riflessioni e trasparenze) riuscisse a girare in tempo reale per una scena tridimensionale generica (invece di una situazione perettamente nota a priori) , lo troverei assai eclatante

certamente, anche se comunque avendo a disposizione gflop nell'ordine delle centinaia se non addirittura del migliaio non me la sentirei comunque di definire la cosa "eclatante"... se vai a vedere il link che ha postato Banus (http://openrt.de/) troverai che con cluster di una decina di athlon 1800+ (mi sembra la versione di q3 in openrt) lo fanno già... e vedendo il tipo di progetto, non penso sia estremamente ottimizzato - senza nulla togliere eh =)

è ovvio che se l'algoritmo RT ha la complessità di quello di un motore di rendering 3d di - che so - un 3d studio max il discorso cambia. però personalmente ho dubbi, anche perchè non ha nessuna utilità: dato che per tutta una serie di effetti puoi usare dei "trucchetti" (guarda ad es. la demo sul sito della ATI delle sfere che riflettono / distorcono) che ottengono effetti analoghi ad un costo computazionale estremamente ridotto, è meglio abbondare con questi e ridurre algoritmi particolarmente onerosi (anche perchè come giustamente sottolineavi sono del peggior tipo: non hanno un tempo di esecuzione determinato a priori) come questi solo laddove dove veramente non se ne può fare a meno...

Sono sicuro che fek sa tutto di Cell, ma se in moltissimi siti si paragona il Cell ad una GPU (come anche qui:http://www.igeek.com/CellProcessor.pdf), uno è portato a crederci. E' ovvio che le attuali GPU possono effettuare operazioni dedicate più complesse, ma è anche vero che sono stati introdotti shader programmabili e che quindi esiste uno sforzo per renderle più versatili e pensavo a Cell come ad una sorta di "estremizzazione" di questo concetto.
Comunque prendo atto che ho preso una cantonata.

no, non è che hai preso una cantonata, è solo che c'è molta confusione in merito al cell... le GPU come giustamente dici si sono spostate un po', con gli shader programmabili, verso il general purpose (da prendersi con le pinze eh :D non è che adesso SONO general purpose, sono solo più flessibili rispetto a un tempo)... tuttavia non solo questo sono, e per il resto sono altamente ottimizzate per il loro campo. il cell invece è più flessibile, e farà bene più cose, anche se non sarà così bravo come le gpu a fare ciò per cui esse sono progettate, il che tuttavia non esclude che in alcuni aspetti specifici le possa battere.

comunque il concetto è chiaro: da una parte hai la flessibilità e dall'altra parte hai le performance assolute, più hai un hardware specifico più sarà bravo a fare quello per cui è progettato (e più sarà un disastro a fare il resto :D ) - ad esempio una GPU - più invece hai un hardware flessibile più questo offrirà performance ridotte (rispetto a un hardware specifico, non in assoluto) ma a 360° - le CPU. il cell si colloca nel mezzo, da come lo vedo io anzi più tendente ad un hardware specifico e più precisamente nella categoria VPU / stream processor / DSP... come ho già detto il cell io lo vederei particolarmente bene dentro a un pc, ma non in sostituzione della cpu o della gpu, bensì in COMPLETAMENTO alle due... anche se sono dell'opinione che difficilmente lo vedremo mai nei pc, più facilmente vedremo processori con caratteristiche analoghe: il prossimo passo, imho, è quello

se vai a vedere il link che ha postato Banus (http://openrt.de/) troverai che con cluster di una decina di athlon 1800+ (mi sembra la versione di q3 in openrt) lo fanno già... e vedendo il tipo di progetto, non penso sia estremamente ottimizzato - senza nulla togliere eh =)
E già in quel caso sono usate ottimizzazioni abbastanza sofisticate, che sfruttano ad esempio la coerenza tra frames ;)
Se si dovesse disegnare una scena usando uno degli ultimi renderizzatori (esempio, Mental Ray o Messiah), considerando che su un PC normale impiegano 20 minuti per oggetti semplici, servirebbero circa 30 Tflops per un'animazione realtime :eek:
Può darsi che nelle nuove console, grazie al quantitativo generoso di Gflops, qualche parte della scena sia disegnata con raytracing o raycasting (esempio, superficie dell'acqua), ma difficilmente tutta la scena sarà in raytracing, anche perchè costringerebbe a ripensare completamente la pipeline di rendering.

E' un po' OOT (out of thread), ma siccome se ne parlava, vi segnalo questo link:
http://www.gpgpu.org/
dedicato all'utilizzo General Purpose delle GPU. :)

non mi sembra sia ot, ti segnalo anche questo (mi sembra sia già stato postato in questo topic):

http://graphics.stanford.edu/projects/brookgpu/index.html

il problema è che ovviamente se le usi davvero per impieghi general purpose (che so, office) fanno schifo: la cosa diventa interessante invece se le sfrutti per fare operazioni in cui sono brave, quindi ad esempio alcuni casi di calcolo vettoriale... la chiave è sfruttare sempre l'hardware specifico a fare ciò che è bravo a fare =)

Banus: si, ma mental ray o messiah danno anche una qualità diversa dell'immagine =) ripeto, con tutto rispetto per il progetto eh, ma l'idea che mi sono fatto è che più che avere ottimizzazioni spinte abbiano ridotto una serie di parametri e una serie di feature rispetto a un motore di rendering di ultima generazione... imho se ci si mettono le software house grosse, soprattutto se si parla di console, si vedrà spremere per benino l'hardware

ps: per curiosità, hai visto le demo della ATI?

Sono sicuro che fek sa tutto di Cell, ma se in moltissimi siti si paragona il Cell ad una GPU (come anche qui:http://www.igeek.com/CellProcessor.pdf), uno è portato a crederci.

In realta' so' davvero poco sul Cell, sono decisamente piu' ferrato sulle GPU. E capisco che sia facile confondere il Cell con una GPU, soprattutto per le innumerevoli errate informazioni che si trovano in giro per la rete.

E' molto bello invece che si sia potuto sviscerare l'argomento qui con molta calma, nonostante la mia indefessa vis polemica che un bel giorno imparero' a tener fuori dalle discussioni :p, ed e' molto bello che tu ti possa essere chiarito le idee proprio per mezzo di questa discussione.

E' anche molto bello che nessuno si sia accorto di un paio di idiozie che ho scritto :p


il problema è che ovviamente se le usi davvero per impieghi general purpose (che so, office) fanno schifo: la cosa diventa interessante invece se le sfrutti per fare operazioni in cui sono brave, quindi ad esempio alcuni casi di calcolo vettoriale... la chiave è sfruttare sempre l'hardware specifico a fare ciò che è bravo a fare =)

Sull'ultimo GPU Gems di NVIDIA (http://developer.nvidia.com/object/gpu_gems_2_home.html) c'e' un intero capitolo dedicato all'uso della GPU per calcoli general puropose.

Questi sono alcuni esempi, che spaziano dalla fisica al campo finanziario:

Options Pricing on the GPU
Craig Kolb and Matt Pharr (NVIDIA Corporation)

Improved GPU Sorting
Peter Kipfer and Rüdiger Westermann (Technische Universität München)

Flow Simulation with Complex Boundaries
Wei Li (Siemens Corporate Research), Zhe Fan, Xiaoming Wei, and Arie Kaufman (Stony Brook University)

Medical Image Reconstruction with the FFT
Thilaka Sumanaweera and Donald Liu (Siemens Medical Solutions USA, Inc.)

Sarebbe bello però sviscerare un po' anche la tecnologia Altivec (ed il SIMD in genere).
Qui ho trovato l' AltiVec Technology Programming Interface Manual :
http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf.

Prendiamo ad esempio un'istruzione come vec_msum:
- For Multiply Sum of Sixteen 8-bit elements
do i=0 to 3
di <- (a4i * b4i) + (a4i+1 * b4i+1) + (a4i+2 * b4i+2) + (a4i+3 * b4i+3) +ci
end
- For Multiply Sum of Eight 16-bit elements
do i=0 to 3
di <- (a2i * b2i) + (a2i+1 * b2i+1) +ci
end

In pratica viene effettuata con un'unica istruzione Altivec una lunghissima serie di moltiplicazioni e somme che in un'unità SISD impiegherebbe decine e decine di cicli di clock!
Le GPU saranno in grado di eseguire molti più calcoli in un colpo di clock, ma rispetto ad un core x86 liscio (trascurando MMX,SSE,3DNow, ecc..) la differenza è sostanziale. Non dico che sia meglio o peggio, ma semplicemente diverso come concezione. Se non è simile alle GPU (per concezione, non per prestazioni), si potrà dire che è simile ad un DSP almeno, o no?
Almeno da quanto si legge (e fin qui pare che tutti i siti siano concordi) le unità SPE dovrebbero eseguire esclusivamente operazioni vettoriali e quindi non sono paragonabili certo ad una CPU tradizionale. Il paragone con i DSP, almeno, è calzante oppure no?
Le SPE, poi, non si sa nemmeno esattamente se utilizzeranno un'evoluzione delle Altivec o un'ISA ancora diversa (e più complessa)...

Le GPU saranno in grado di eseguire molti più calcoli in un colpo di clock, ma rispetto ad un core x86 liscio (trascurando MMX,SSE,3DNow, ecc..) la differenza è sostanziale. Non dico che sia meglio o peggio, ma semplicemente diverso come concezione. Se non è simile alle GPU (per concezione, non per prestazioni), si potrà dire che è simile ad un DSP almeno, o no?

Beh, l'Altivec e' l'equivalente delle istruzioni SSE.


Almeno da quanto si legge (e fin qui pare che tutti i siti siano concordi) le unità SPE dovrebbero eseguire esclusivamente operazioni vettoriali e quindi non sono paragonabili certo ad una CPU tradizionale. Il paragone con i DSP, almeno, è calzante oppure no?

E' molto calzante. L'SPE e' di fatto uno DSP.

non mi sembra sia ot, ti segnalo anche questo (mi sembra sia già stato postato in questo topic):

http://graphics.stanford.edu/projects/brookgpu/index.html

il problema è che ovviamente se le usi davvero per impieghi general purpose (che so, office) fanno schifo: la cosa diventa interessante invece se le sfrutti per fare operazioni in cui sono brave, quindi ad esempio alcuni casi di calcolo vettoriale... la chiave è sfruttare sempre l'hardware specifico a fare ciò che è bravo a fare =)


Beh il nuovo Tiger di Apple usa la GPU per il nuovo core-graphics e core-video. Non ho capito bene se la usa anche per il decoding dell'H264 in Quicktime e in core-audio, ma insomma le potenzialità sono impressionanti.

E' però interessante il fatto che quei frameworks non sono mappati ad una singola GPU o addirittura tecnologia: se non non si dispone di GPU programmabile quegli algoritmi vengono svolti da Altivec, certo con una velocità molto inferiore... ma insomma: l'effetto "goccia nello stagno" che era un classico dei demo del core-graphics, riesce a farlo anche il mio iBook G4 che non dispone di una GPU programmabile...

Portare queste tecnologie anche su Cell non sembrerebbe quindi difficile per Apple, anzi sembrano già predisposte...

Le SPE, poi, non si sa nemmeno esattamente se utilizzeranno un'evoluzione delle Altivec o un'ISA ancora diversa (e più complessa)...

A quanto pare un superset di Altivec. Ma attenzione, le SPE sono veri e propri processori indipendenti, completi anche di memoria locale, non sono solo unità vettoriali come Altivec o le MMX.

A quanto pare un superset di Altivec. Ma attenzione, le SPE sono veri e propri processori indipendenti, completi anche di memoria locale, non sono solo unità vettoriali come Altivec o le MMX.

No, le SPE non sono processori indipendenti, non hanno alcuna interfaccia verso l'esterno (e' una scelta), la memoria locale dev'essere riempita in DMA dal coordinatore. L'SPE non e' in grado di interfacciarsi al mondo esterno e prelevare istruzioni e dati, senza un coordinatore siederebbe all'infinito senza fare nulla, infatti non e' indipendente, per scelta e' una semplice unita' vettoriale in grado di processare molto velocemente stream di dati.

No, le SPE non sono processori indipendenti, non hanno alcuna interfaccia verso l'esterno (e' una scelta), la memoria locale dev'essere riempita in DMA dal coordinatore.
L'SPE non e' in grado di interfacciarsi al mondo esterno e prelevare istruzioni e dati, senza un coordinatore siederebbe all'infinito senza fare nulla, infatti non e' indipendente, per scelta e' una semplice unita' vettoriale in grado di processare molto velocemente stream di dati.

Sicuro che non hanno un'interfaccia verso l'esterno?
Io ho letto che ogni SPE può accedere all'EIB (Element Interconnect Bus) e scambiare dati con le unità SPE adiacenti (per accedere a quelle non adiacenti bisogna impostare le SPE intermedie in modalità "ripetitore"). Uno dei vantaggi accreditati alle SPE è quello di poter essere utilizzate in parallelo o in serie.

Sicuro che non hanno un'interfaccia verso l'esterno?

Se non ho detto una scemenza, si', non hanno interfaccia verso la memoria centrale per prelevare dati e istruzioni, e questo fa parte del design, di modo da avere un modello di latenze costante per semplificare il progetto.

In pratica non posso teoricamente prendere un SPE, attaccarlo ad un bus e fargli fare il fetch di dati e istruzioni dalla memoria centrale, perche' non ha alcuna logica per questo compito, puo' solo prelevare dalla sua memoria privata che viene riempita dal controllore via DMA.

Beh il nuovo Tiger di Apple usa la GPU per il nuovo core-graphics e core-video. Non ho capito bene se la usa anche per il decoding dell'H264 in Quicktime e in core-audio, ma insomma le potenzialità sono impressionanti.

E' però interessante il fatto che quei frameworks non sono mappati ad una singola GPU o addirittura tecnologia: se non non si dispone di GPU programmabile quegli algoritmi vengono svolti da Altivec, certo con una velocità molto inferiore... ma insomma: l'effetto "goccia nello stagno" che era un classico dei demo del core-graphics, riesce a farlo anche il mio iBook G4 che non dispone di una GPU programmabile...

Portare queste tecnologie anche su Cell non sembrerebbe quindi difficile per Apple, anzi sembrano già predisposte...

criceto, sei un confusionario esagerato :D

core video e core image sono un framework che sfrutta la scheda video a far cosa? indovina un po'? a elaborare immagini. gli "effetti" che vengono applicati sono la stessa cosa di ciò che si vedeva da tempo in una serie di giochi, di bench, di demo ma portato su un uso completamente diverso.

di fatto core video e image usano la GPU a far quello in cui è brava, per questo il risultato è proficuo: lo stesso effetto elaborato dalla CPU (tra l'altro: si parla di cpu che hanno altivec) impiega più tempo.

premesso questo non capisco:
a) perchè sono "predisposte" per il porting su cell? sono più "predisposte" per un porting su x86, se per quello, le gpu sono le stesse =)
b) perchè mai dovrebbero usare il cell e non la gpu a fianco al cell? :D

Se non ho detto una scemenza, si', non hanno interfaccia verso la memoria centrale per prelevare dati e istruzioni, e questo fa parte del design, di modo da avere un modello di latenze costante per semplificare il progetto.
In bsa all'articolo di arstechnica (http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2) le SPE hanno la possibilità di caricare dati direttamente dalla memoria centrale nella loro memoria locale. Il caricamento è esplicito (gestito a livello di codice).

Ora devo andare via e quindi purtroppo non leggerò la risposta prima di venerdì prossimo, comunque ho trovato un documento che sembra interessante sul sito della IBM. MPR-Cell-details-article-021405.pdf (http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf).

Purtroppo non ho avuto il tempo di leggerlo tutto, ma da un'occhiata veloce parrebbe che nè le SPU nè la PPU abbiano accesso diretto alla memoria, ma che tutto sia demandato all'EIB che a sua volta è collegato al MIC (che dovrebbe essere una specie di northbrige da quel che ho capito) che a sua volta accede alle XDR (...che al mercato mia madre comprò! ;) )

Altro documento che sembrerebbe interessante è, secondo me, questo:
http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318

Saluti e alla prox settimana!

In bsa all'articolo di arstechnica (http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2) le SPE hanno la possibilità di caricare dati direttamente dalla memoria centrale nella loro memoria locale. Il caricamento è esplicito (gestito a livello di codice).

Ok, allora ho detto una scemenza :)
Quindi e' possibile programmare il DMA direttamente dall'SPE in maniera esplicita senza passare dal controllore?
Vorrebbe dire che teoricamente e' possibile simulare qualcosa di simile ad un "texture fetch" direttamente dall'SPE.

Ecco il passo:
The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage.

Grazie Banus.

Quindi e' possibile programmare il DMA direttamente dall'SPE in maniera esplicita senza passare dal controllore?
So che la IBM ha depositato un po' di brevetti relativi a metodi di accesso alla memoria, però non li ho letti per conservare la mia sanità mentale :p

Se non ricordo male l'idea è permettere di caricare blocchi di dati nella memoria locale delle SPE, in maniera simile a una cache, ma con istruzioni esplicite. In questo modo ad esempio per applicare una convoluzione ad un'immagine si carica la kernel con un'istruzione, poi con altre istruzioni si caricano i blocchi di pixel su cui il filtro sarà applicato. In questo modo il flusso di dati non deve passare per la PPE. Un'altra possibilità dovrebbe essere quella di copiare i dati nella memoria locale di un'altra SPE per eseguire istruizioni a catena (esempio, convoluzione + sogliatura).
D'altra parte la possibilità di "saltare" la PPE è uno dei motivi che dovrebbero rendere il Cell molto efficiente nei compiti facilmente vettorializzabili.

Purtroppo non ho avuto il tempo di leggerlo tutto, ma da un'occhiata veloce parrebbe che nè le SPU nè la PPU abbiano accesso diretto alla memoria, ma che tutto sia demandato all'EIB che a sua volta è collegato al MIC
Il nostro era un discorso a livello logico ;)
EIB dovrebbe fare le veci del bus interno del processore, permettendo il transito dei dati dal controller di memoria alle varie unità. Infatti, se vedi il layout del processore, EIB è in contatto fisico con le 8 SPE e con la PPE.

Vorrebbe dire che teoricamente e' possibile simulare qualcosa di simile ad un "texture fetch" direttamente dall'SPE.
Anche io avevo notato la somiglianza :p

criceto, sei un confusionario esagerato :D

core video e core image sono un framework che sfrutta la scheda video a far cosa? indovina un po'? a elaborare immagini. gli "effetti" che vengono applicati sono la stessa cosa di ciò che si vedeva da tempo in una serie di giochi, di bench, di demo ma portato su un uso completamente diverso.


Sorry, ma io non li avevo mai visti fare prima da qualsiasi altro software... (sarà che non gioco? E non ho una gpu programmabile? :) )

premesso questo non capisco:
a) perchè sono "predisposte" per il porting su cell? sono più "predisposte" per un porting su x86, se per quello, le gpu sono le stesse =)


Hanno realizzato un framework abbastanza generico da poterlo mappare su archietture diverse, come le GPU e le unità vettoriali. A questo punto nessuno vieta il loro adattamento al Cell. All'inizio sembrava una cosa per le sole GPU...

b) perchè mai dovrebbero usare il cell e non la gpu a fianco al cell? :D
Perchè in un computer di fascia bassa, come il MacMini, è più economico da tutti i punti di vista (costi, consumo, spazio) avere un solo processore complesso invece di 2.

So che la IBM ha depositato un po' di brevetti relativi a metodi di accesso alla memoria, però non li ho letti per conservare la mia sanità mentale :p

Se non ricordo male l'idea è permettere di caricare blocchi di dati nella memoria locale delle SPE, in maniera simile a una cache, ma con istruzioni esplicite. In questo modo ad esempio per applicare una convoluzione ad un'immagine si carica la kernel con un'istruzione, poi con altre istruzioni si caricano i blocchi di pixel su cui il filtro sarà applicato. In questo modo il flusso di dati non deve passare per la PPE. Un'altra possibilità dovrebbe essere quella di copiare i dati nella memoria locale di un'altra SPE per eseguire istruizioni a catena (esempio, convoluzione + sogliatura).
D'altra parte la possibilità di "saltare" la PPE è uno dei motivi che dovrebbero rendere il Cell molto efficiente nei compiti facilmente vettorializzabili.

Nella mia ignoranza sul Cell pensavo che il PPE caricasse i dati necessari nella memoria privata e poi "lanciasse" il programma.
In effetti cosi' e' decisamente piu' flessibile.

Il dubbio e': le istruzioni di caricamento sono bloccanti o no? Immagina un codice del tipo:

1) load kernel
2) load block_of_pixels
3) execute_kernel

Se le due load sono bloccanti, mi inchioda l'intero SPE fino a che il trasferimento dei due blocchi di memoria, le istruzioni 1 e 2, non sono completati?

Lo stesso "programma" su una GPU sarebbe eseguito su un certo numero di pipeline in contemporanea. quando la prima pipeline, ad esempio, manda il comando do fetch dalla memoria, invece di bloccarsi, ha della logica che parcheggia quel gruppo di pixel, e passa ad elaborare un altro gruppo di pixel. Quando il fetch e' completato, riesuma il primo blocco di pixel e lo elabora.

Va detto che nelle GPU odierne tutte le pipeline eseguono lo stesso programma (shader), mentre su un Cell ogni SPE puo' eseguire programmi diversi. E' un'interessante differenza che forse spiega bene quanto una GPU abbia difficiolta' ad eseguire i compiti di un Cell e viceversa.

Anche io avevo notato la somiglianza :p

Si', ma se i fetch dell'SPE sono bloccanti quanto andrebbe lento?
A meno che non ci si programmi esplicitamente il PPE per compiere il lavoro di threading per nascondere le latenze degli accessi alla memoria, tutto il lavoro che in una GPU e' hardwired.
Mi diventa sempre piu' chiaro il perche' abbiano affiancato una GPU al Cell nella PS3, un Cell si inchioderebbe al solo pensiero di dover processare pixel.

Questa considerazione vale nell'ipotesi che i fetch siano bloccanti.

Perchè in un computer di fascia bassa, come il MacMini, è più economico da tutti i punti di vista (costi, consumo, spazio) avere un solo processore complesso invece di 2.

Dato un certo livello di prestazioni, e' molto piu' economico usare CPU e GPU, che usare il Cell che non e' in grado di fare nessuno dei due lavori allo stesso livello (general purpose e processare grafica) e dovrebbe essere sovradimensionato.

Nella mia ignoranza sul Cell pensavo che il PPE caricasse i dati necessari nella memoria privata e poi "lanciasse" il programma.
In effetti cosi' e' decisamente piu' flessibile.

Il dubbio e': le istruzioni di caricamento sono bloccanti o no? Immagina un codice del tipo:

1) load kernel
2) load block_of_pixels
3) execute_kernel

Se le due load sono bloccanti, mi inchioda l'intero SPE fino a che il trasferimento dei due blocchi di memoria, le istruzioni 1 e 2, non sono completati?

Se ho capito la domanda, la risposta dovrebbe essere no.

Cioè la SPE esegue il suo bel codice nella memoria LOCALE (non può lavorare direttamente con la memoria centrale) e contemporanamente carica/scarica i dati elaborati con la memoria o le altre SPE.

Ricorda che il Cell ha una banda spaventosa, sia con la memoria che con le altre SPE per mezzo un un bus ad anello. Non ricordo però se la banda sia sufficiente in caso di contemporaneo accesso al bus da parte di tutte e 8 le SPE (non mi sembra, era qualcosa tipo la metà).

Dato un certo livello di prestazioni, e' molto piu' economico usare CPU e GPU, che usare il Cell che non e' in grado di fare nessuno dei due lavori allo stesso livello (general purpose e processare grafica) e dovrebbe essere sovradimensionato.

Non sempre l'obbiettivo primario è avere il massimo delle prestazioni.
Il Cell è pensato come processore digitale multi-purpose ECONOMICO. Non va in competizioni con GPU da 500 Eur o processori da 1000 Eur.
Quindi un suo utilizzo "solitario" è auspicabile per il suo target, e quasi certo su macchine di fascia bassa.
Le GPU di cui parli sono processori estremamente complessi, spesso come e più del Cell in termini di transistor, quindi intrinsecamente costosi. Stai sicuro che se li possono eliminare pur mantenendo delle prestazioni "adeguate" lo faranno di certo. E il Cell dovrebbe garantire prestazioni onorevoli anche in ambiti ora di esclusiva pertinenza delle GPU.

Se ho capito la domanda, la risposta dovrebbe essere no.


Non hai capito la domanda :)

Per quanto ampia si la banda passante, non accadra' mai che fatta la richiesta al DMA per trasferire da memoria centrare un dato, questo dato sia immediatamente disponibile all'istruzione dopo. Ci sara' sempre e comunque una certa latenza, perche' se questa latenza non esistesse non avrebbe senso avere la memoria locale.

Esempio:

fetch [addr0], mem1 # memoria centrale, NON locale
load r0, [addr0]
add r0, r0, 10

La prima istruzione richiede un dato da memoria centrale a memoria locale, la seconda istruzione lo carica in un registro da memoria locale. E' matematicamente impossibile che al momento della seconda istruzione il dato sia gia' presente in memoria locale per via delle latenze.

E' piu' probabile che accada una cosa del tipo:

fetch [addr0], mem1
# esegui qualcosa qui mentre attendi il fetch
wait [addr0]
load r0, [addr0]
add r0, r0, 10

Che esista una qualche istruzione di sincronizzazione che attende la fine del trasferimento e inchioda l'SPE. Il programmatore avrebbe sempre la possibilita' di eseguire un qualche lavoro utile fra il fetch e il wait. Se consideri che le GPU sono progettatr per nascondere automaticamente queste latenze quando processano i pixel (che accedono sempre alla memoria centrale per i fetch delle texture), hai un'ulteriore motivo per cui il Cell non potra' mai fare da GPU con prestazioni accettabile. Non e' costruito per questo lavoro.

Non sempre l'obbiettivo primario è avere il massimo delle prestazioni.
Il Cell è pensato come processore digitale multi-purpose ECONOMICO. Non va in competizioni con GPU da 500 Eur o processori da 1000 Eur.
Quindi un suo utilizzo "solitario" è auspicabile per il suo target, e quasi certo su macchine di fascia bassa.
Le GPU di cui parli sono processori estremamente complessi, spesso come e più del Cell in termini di transistor, quindi intrinsecamente costosi. Stai sicuro che se li possono eliminare pur mantenendo delle prestazioni "adeguate" lo faranno di certo. E il Cell dovrebbe garantire prestazioni onorevoli anche in ambiti ora di esclusiva pertinenza delle GPU.

E' anche in grado di creare un milione di posti lavoro?

(Non hai letto nulla di quello che abbiamo scritto fin'ora, sembri un predicatore con la bibbia in mano che ripete la stessa filastrocca senza capire che vuol dire).

L'NV40 piu' economico viene venduto a meno di 50 dollari e sono stati ingegnerizzati sample con costi di produzione inferiori ai 10 dollari. Ci rinuncio, tu non sai di che stai parlando.

Non hai capito la domanda :)

....

Esempio:

fetch [addr0], mem1 # memoria centrale, NON locale
load r0, [addr0]
add r0, r0, 10


Credo di averla capita. Ma come detto le SPE possono elaborare dati presenti solo nella memoria LOCALE, non in quella centrale.

Insomma si spezzettano i dati in blocchi da 256KB, si danno in pasto alla SPE che li elabora, e si copiano i risultati nella memoria centrale.
Credo sia questa la filosofia di funzionamento delle SPE del Cell...

Che esista una qualche istruzione di sincronizzazione che attende la fine del trasferimento e inchioda l'SPE. Il programmatore avrebbe sempre la possibilita' di eseguire un qualche lavoro utile fra il fetch e il wait.
Sto cercando info. Se funziona circa come Imagine, il Cell dovrebbe fare qualcosa del genere:

fetch [block 1] (startup)
fetch [block 2]
kernel [block 1]
fetch [block 3]
kernel [block 2]
...

e a regime quindi le SPE possono essere idealmente utilizzate al 100%.
Ovviamente non sempre sarà così, ad esempio quanto il rapporto operazioni/dati è molto piccolo ci saranno comunque latenze, oppure quando il flusso di dati non è coerente.

Vedo se riesco a trovare qualcosa di più preciso.

E' anche in grado di creare un milione di posti lavoro?

Questa te la potevi risparmiare...

L'NV40 piu' economico viene venduto a meno di 50 dollari e sono stati ingegnerizzati sample con costi di produzione inferiori ai 10 dollari. Ci rinuncio, tu non sai di che stai parlando.

Cioè fammi capire: l'NV40 ha 220 milioni di transistor, più meno come il Cell. Quindi il costo industriali è paragobile. E viene prodotto con 10$?!
Ora ho capito perchè vogliono mettere i Cell anche nei televisori...
Comunque fidati, se mai la Apple farà un MacMini con il Cell NON avrà una GPU. Pur di risparmiare 10$ toglierebbero anche il mouse (ops, l'hanno già fatto!).

Credo di averla capita. Ma come detto le SPE possono elaborare dati presenti solo nella memoria LOCALE, non in quella centrale.

Insomma si spezzettano i dati in blocchi da 256KB, si danno in pasto alla SPE che li elabora, e si copiano i risultati nella memoria centrale.
Credo sia questa la filosofia di funzionamento delle SPE del Cell...

Finalmente! Forse arriviamo a qualcosa.
Questa filosofia di funzionamento va benissimo per uno stream processor, ma e' l'esatto contrario di cio' che serve per una GPU.

I pixel possono accedere in maniera random e incoerente virtualmente qualunque locazione in memoria centrale all'interno di una o piu' texture che possono essere grandi fino a 16/32 mb. Non sarebbe possibile copiare tutte le texture in memoria locale di un SPE per poi accedere da li'.

Un pixel shader tipico e' una cosa di questo tipo:

tex2d r0, s0, t0 # equivalente di un fetch a memoria
tex2d r1, s1, t1
...
add r0, r0, r1
mov C0, r0

t0 e t1 sono gli indirizzi in memoria centrale (piu' o meno) e sono virtualmente ovunque.
Un Cell con quel modello computazionale non sarebbe in grado di eseguire uno shader di questo tipo con prestazioni accettabili, perche' si ritroverebbe continuamente a trasferire blocchi da memoria centrale a locale e ad attendere le latenze, oppure la PPU dovrebbe essere programmata esplicitamente per nascondere in qualche modo queste latenze, e non e' un compito banale per una CPU gia' per se' piuttosto lenta.

Cioè fammi capire: l'NV40 ha 220 milioni di transistor, più meno come il Cell. Quindi il costo industriali è paragobile. E viene prodotto con 10$?!

Si', le versioni con meno pipeline sono prodotte a 10$ e sono enormemente piu' performanti di un Cell da 220 milioni di transistor (che non costa 10$ ma molto di piu') nel fare grafica 3d :)


Comunque fidati, se mai la Apple farà un MacMini con il Cell NON avrà una GPU. Pur di risparmiare 10$ toglierebbero anche il mouse (ops, l'hanno già fatto!).

Se il MacMini avesse solo un Cell a 10$ non sarebbe in grado di produrre grafica 3d in tempo reale per tutti i discorsi fatti fino ad ora. Infatti non lo avra'.

Se il MacMini avesse solo un Cell a 10$ non sarebbe in grado di produrre grafica 3d in tempo reale per tutti i discorsi fatti fino ad ora. Infatti non lo avra'.

Bene, quindi secondo te il modello di programmazione del Cell non è adatto alla grafica 3D (o almeno ad alcuni suoi algoritmi, perchè penso che per altri, vada bene). Quindi la scelta di Sony di affiancargli una GPU è ancora più giustificata.

Però credo lo stesso che un eventuale MacMini col Cell non avrà un GPU, anche perchè una GeForce 6800 (NV40, giusto?) a Roma non si trova a meno di 300Eur, altro che 10$!!!

Bene, quindi secondo te il modello di programmazione del Cell non è adatto alla grafica 3D (o almeno ad alcuni suoi algoritmi, perchè penso che per altri, vada bene). Quindi la scelta di Sony di affiancargli una GPU è ancora più giustificata.

Mi indichi quale algoritmo di grafica 3d pensi che andrebbe bene al Cell?


Però credo lo stesso che un eventuale MacMini col Cell non avrà un GPU, anche perchè una GeForce 6800 (NV40, giusto?) a Roma non si trova a meno di 300Eur, altro che 10$!!!

Quanto costa una 6200 Turbo Cache a Roma? NVIDIA produce il suo chip video spendendo attorno ai 10$, ed e' un signor chip video a basso costo, una cui pipeline e' in grado di eseguire tutte quelle operazioni per colpo di clock che avevo elencato in un altro post.

criceto, ma hai fatto due conti di quanti transistor ci sono tra cpu e gpu ora come ora nel mac mini? ce ne sono un terzo di quelli che ci sono nel cell, e tu ci vedresti bene un cell per fare cosa? per fare male ciò che il g4 e la radeon 9200 fanno onestamente? per non parlare del costo industriale di avere un tot di milioni di transistor su due chip differenti oppure di averne un tot su un die unico (nel primo caso se un pezzo è difettato scarti solo quello, nel secondo caso scarti tutto quanto)

cioè... il cell può fare bene, anzi, benissimo il 10% (dico per dire) di ciò che fa la gpu e di ciò che fa la cpu... pensare di mettere il cell al posto della scheda video è un po' come dire mettere un athlon 64 al posto della scheda video... non c'entra niente!

Qui (http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm) ci sono alcune slide che spiegano il funzionamento delle SPE, fra cui l'accesso alla memoria centrale. Quella più interessante per il nostro discorso è questa:
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai068.jpg

L'esempio mostra 3 SPE che eseguono gli stessi calcoli su uno stream di dati. Ognuna ha 3 blocchi nella memoria, un blocco in caricamento, un blocco su cui sono eseguie le operazioni, un blocco che attende di essere copiato in memoria centrale. Queste operazioni sono eseguite con istruzioni dedicate (get e put) per caricare/scaricare la memoria locale (si trova qui (http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf) a pag. 7)

Avevo anche trovato una presentazione abbastanza interessante sul modello di programmazione di Cell, ma non riesco a trovarla.

Riguardo all'uso di Cell come processore grafico, ho visto dei benchmark di Imagine, e l'impressione è che gli stream processor sono sicuramente migliori delle CPU, ma le GPU dedicate hanno comunque prestazioni più alte. La maggiore flessibilità comunque permette alte prestazioni in casi come l'uso di subdivision surfaces, oppure tecniche di rendering non accelerate dalle GPU.

criceto, ma hai fatto due conti di quanti transistor ci sono tra cpu e gpu ora come ora nel mac mini? ce ne sono un terzo di quelli che ci sono nel cell, e tu ci vedresti bene un cell per fare cosa? per fare male ciò che il g4 e la radeon 9200 fanno onestamente? per non parlare del costo industriale di avere un tot di milioni di transistor su due chip differenti oppure di averne un tot su un die unico (nel primo caso se un pezzo è difettato scarti solo quello, nel secondo caso scarti tutto quanto)


La 9200 del Mini non ha gli shader programmabili (si dice così?).
Hanno messo da pochi giorni la 9600 sugli altri Mac per sfruttare meglio Core-Image, più che per i giochi... Sul Mini ancora no.

Sì tra G4 e 9200 ci saranno 1/4 dei transistor del Cell, forse meno.
Ma il Cell prima di andare a 65nm non sarà un prodotto di massa, e a quel punto i costi non dovrebbero essere molto differenti dagli attuali... e poi se lo mettono in una Playstation e nei televisori, spero bene che sarà abbordabile anche per un Mini! :)

cioè... il cell può fare bene, anzi, benissimo il 10% (dico per dire) di ciò che fa la gpu e di ciò che fa la cpu... pensare di mettere il cell al posto della scheda video è un po' come dire mettere un athlon 64 al posto della scheda video... non c'entra niente!

Al posto magari no. Però potrebbe coadiuvarne una meno sofisticata. Sarebbe interessante vedere quella della PS3 cos'ha di diverso da quelle "tradizionali"...

La 9200 del Mini non ha gli shader programmabili (si dice così?).

La 9200 e' Shader Model 2.0, un derivato economico dell'architettura R300. Un'ottima architettura per altro.

La 9200 e' Shader Model 2.0, un derivato economico dell'architettura R300. Un'ottima architettura per altro.

Una Ati 9200 è una 8500 a tutti gli effetti (R2x0) :confused:

Si, infatti, è una Direct X 8.1 . Le DX 9 partono dalla 9550 in su.

Si, infatti, è una Direct X 8.1 . Le DX 9 partono dalla 9550 in su.

Ho detto la seconda scemenza del thread confondendomi con la 9600. Vacche grasse.

A me è cdimauro che mi sfianca.
Abbandono anch'io :)
Comunque per il Cell sul MacMini entro Natale 2006 possiamo sempre scommettere...
SLURP. Soldi facili, come dice fek, e mi associo alla sua "sfida". :D

Comunque se accetti non è che te la passi liscia, eh! Io sono immediatamente rintracciabile, fek quasi, ma di te non sappiamo niente... ;)

'Na pizza? :D
Cos'è, non ti fidi abbastanza di IBM e Apple? :D
Io mi fido e affido esclusivamente alle mie capacità logico-deduttive, quindi in teoria dovrei partire in notevole svantaggio rispetto a quei due colossi, no? ;)
Insomma entro 1 anno escono 2 consolle: una con 3 PowerPC da 3Ghz, e un'altra con un PowerPC da 256Gflops...
Sì, ma non sono PowerPC e i 250GFlops di Cell li erogano le SPE e non il PPE... ;)
Come può la Apple continuare a vendere Mac con i G4?!?!?!
Vuol dire che venderà Mac coi G5 di Motorola/FreeScale... :D
Qualcosa si deve inventare...
Vedi sopra. Al più per i server potrà farsi prestare un Power5 da IBM, perché penso che sarà difficile vedere un cut-down di questo mostro ad uso desktop per i Mac (la strada, IMHO è e rimarrà sempre quella del PPC970 fatto "evolvere" a dual o multicore).
E poi la PPE del Cell ha Altivec: è FATTA per Apple!
Vuoi mettere quella "schifezza" di Altivec con le SPE? ;)

Ma, scusa, come utente Mac non ti converrebbe avere un dual PPC970 E (congiunzione) un Cell da dare in pasto a core-video/image? ;) Mi sembra una mossa più razionale e realizzabile, no? ;)

:doh: Ahi ahi... era meglio se non lo dicevi.

Se lo vede Cesare... :muro:

;)

Cmq...mi permetto di scommettere con Fek...scegliete voi la quota :D
Visto, visto e mi associo: per me è la manna caduta dal cielo questa... :p

Non più molto!!

prototype:

1 VMX
1 FPU
1 INT ALU
2 instrtuctions/cycle
2 thread
32 Gflops at 4 Ghz

new modell:

1 full VMX
1 extra multiply-add VMX unit
1 FPU
2 INT ALU
4 instructions/cycle
2 thread
64 Gflops at 4 Ghz
Santa pazienza, è certamente meglio rispetto a prima, ma vogliamo almeno capire come sono legati questi numeretti? A me non basta vedere un mucchio di mattoncini Lego: voglio vedere com'è possibile costruire la Morte Nera con essi! :D

1) 4 istruzioni per ciclo di clock non si sa ancora come verranno distribuiti: se affidati a un solo thread (considerata l'architettura in order del PPE sarebbe puro suicidio), due per thread (soluzione migliore della precedente nel caro generale, ma non ottimale), oppure se dinamicamente smistati ai due thread (soluzione ottimale: potrebbe dare un'istruzione al primo thread e tre al secondo, ad esempio; però richiede molta più logica ed è molto più difficile da implementare).

2) Puoi eseguire 4 istruzioni, ma hai soltanto 5 (sembra) unità di esecuzione: sei per forza vincolato a usare quasi sempre le stesse unità di esecuzione (e vai col valzer di stalli alla pipeline e con le unità di esecuzione che rimangono a girarsi i pollici per lo più). Inoltre non è detto che siano 5 unità vere e proprie: non si capisce bene se il moltiplicatore/sommatore rappresenta un "aiuto" all'unità VMX, o è in grado di accollarsi un'istruzione VMX in maniera del tutto indipendente dall'altra unità VMX.

Come vedi la situazione è più rosea, ma non più di tanto.

Chissà come ci girerà il MAME... :p

Su http://it.wikipedia.org/wiki/AltiVec si dicono cose abbastanza diverse:
A me sembra che non sia dissimile da quanto si trova scritto per il Cell: una notevole imprecisione.

Quando è stato presentato AltiVec era il migliore sistema SIMD disponibile per per personal computer. Gli equivalenti prodotti della Intel non erano confrontabili.
Che Altivec fosse la soluzione più elegante ed efficiente (sulla carta) non c'erano dubbi. Anche perché è arrivata dopo MMX, 3DNow! ed SSE(1).
l'MMX non lavorava in virgola mobile ma trattava solamente numeri interi
L'MMS è nata coi primi Pentium 166Mhz: stiamo parlando di una decina d'anni fa...
mentre l'SSE pur trattando i numeri in virgola mobile era molto più lento e limitato dell'AltiVec.
In cosa? Dati disponibili? E poi le SSE sono arrivate prima di Altivec. E prima ancora c'erano le 3DNow! di AMD...
Alla fine la quarta versione di sistema SIMD dell'Intel l'SSE2
La quarta? Me ne sono perso altre due allora... :p
risolse la maggior parte dei problemi e adottò molte delle soluzioni utilizzata dall'AltiVec.
Dove sta scritto?
AltiVec e SSE2 utilizzano dei registri a 128 bit. Questi registri sono in grado di rappresentare 16 dati a 8 bit con o senza segno, otto dati a 16 bit con o senza segno e quattro dati a 32 bit con o senza segno che possono essere anche in virgola mobile.
Le SSE/2 permettono di usare anche due interi a 64 bit e uno a 128 bit, e due a doppia precisione.
Inoltre dispongono di un gestore della cache delle istruzioni che provvede a organizzare le istruzioni in modo da minimizzare i conflitti di accesso alla memoria.
Forse si riferiscono agli stream, ma è chiaro che chi ha scritto questo pezzo deve avere le idee molto confuse, oltre al fatto di non avere esperienza/conoscenza nel campo delle architetture dei processori...
A differenza di SSE2 AltiVec supporta direttamente la gestione dei pixel con la modalità RGB nativa che non si appoggia alla gestione a 64 bit del processore.
Quindi?
Adeguandosi alla filosofia RISC del PowerPC le istruzioni AltiVec sono in grado di manipolare esclusivamente i dati immagazzinati nei registri ma a differenza del SSE2 non esistono registri speciali e tutte le operazioni possono utilizzare tutti i registri.
1) Anche il PowerPC ha dei registri speciali oltre a quelli general purpose.
2) Le operazioni delle SSE2 lavorano sui registri general purpose. Poi è chiaro che ci sono anche quelle che permettono di accedere ai flag dei risultati, come in tutte le architetture.
L'unità di calcolo AltiVec è dotata di 32 registri a 128 bit a differenza dei 8 registri a 128 dell'unità SSE2
Sono 16 per x86-64...
e quindi è in grado di trattare un maggior numero di informazioni prima di dover accedere alla memoria centrale.
Bisogna vedere se l'algoritmo da implementare ha effettivamente bisogno di più di 8 registri. Considerato che ogni registro può contenere parecchi dati, penso che siano pochi i casi.
Inoltre molte operazioni AltiVec sono in grado di utilizzare tre registri contemporaneamente a differenza dell'SSE2 che può utilizzare al massimo due registri contemporaneamente.
Benissimo: è più flessibile e non c'è dubbio, come l'architettura PowerPC d'altra parte.
Ma alla fine contano i risultati, no? Fra PowerPC / Altivec e x86 / SSEx mediamente sono questi ultimi a presentare prestazioni migliori...
Le ultime versioni del compilatore GNU e del compilatore dell'IBM il Visual Age sono in grado di compilare codice in grado di avvantaggiarsi delle istruzioni AltiVec. Il compilatore si preoccupa di fornire delle primitive ad alto livello al programmatore in modo che questo possa scrivere un programma in C che si avvantaggi dell'unità di calcolo. Il programmatore deve solo definire la tipologia di dato da trattare e le operazioni da eseguire e poi il compilatore provvede a realizzare il codice più appropriato, utilizzando le istruzioni corrette e provvedendo a immagazzinare i dati nella modalità migliore per il processore.
Cosa che permettava già Intel coi suoi compilatori all'epoca delle MMX... :p

E' chiaro che non ho risposto a te, che hai semplicemente riportato quelle informazioni... ;)

Ma il Cell prima di andare a 65nm non sarà un prodotto di massa, e a quel punto i costi non dovrebbero essere molto differenti dagli attuali...
Nel frattempo Intel, AMD, nVidia, Ati, ecc. ovviamente non passeranno ai 65nm per rendere più economici e competitivi i loro prodotti, vero? :asd:

Qualcuno arriva e costruisce un processore 10 volte meglio di Intel o Amd?
Ho l'impressione che ci sia un pò di gente che crede in babbo natale.

Ma hai capito chi è questo 'qualcuno'?:D


Ti faccio notare che ci sono sempre stai costruttori che costruiscono chip 10 volte meglio di Intel e AMD,vai su www.sgi.com o su www.sun.com...

Vuol dire che venderà Mac coi G5 di Motorola/FreeScale... :D

Può essere...

Vedi sopra. Al più per i server potrà farsi prestare un Power5 da IBM, perché penso che sarà difficile vedere un cut-down di questo mostro ad uso desktop per i Mac (la strada, IMHO è e rimarrà sempre quella del PPC970 fatto "evolvere" a dual o multicore).

E' strano che non sia ancora successo, invece. Quando è stato presentato il Power5, IBM diceva che in contemporanea stava sviluppando versioni "desktop" del processore...
D'altra parte il 970 è una versione "desktop" del Power4, con 1 solo core e meno cache ma l'aggiunta di Altivec, sostanzialmente.

Vuoi mettere quella "schifezza" di Altivec con le SPE? ;)

Appunto. Se ce l'hanno messa è perchè serviva a qualcuno... E chi è l'unica che usa Altivec?!

Ma, scusa, come utente Mac non ti converrebbe avere un dual PPC970 E (congiunzione) un Cell da dare in pasto a core-video/image? ;) Mi sembra una mossa più razionale e realizzabile, no? ;)

Beh i supercomputer con millanta processori ci sono anche adesso. Però costicchiano... A parte il discorso economico, è altamente improbabile che facciano computer con PowerPC "tradizionali" + Cell perchè:
1°] perchè sono troppo simili, la PPE sarebbe un doppione;
2°] perchè il bus è completamente differente e dovendoli interfacciare con un bus comune le prestazioni del Cell verrebbero in buona parte compromesse.

Molto più semplice mettere 2-4-n Cell. Sono fatti per quello!

Mindphasr: mah, io non vedo questi grandi processori... è chiaro che se mi confronti una cpu desktop con una server abbiamo qualche problema, ma per il resto nei rispettivi segmenti non mi sembra che sgi o sun brillino particolarmente... non a caso - tanto per farti un esempio - sun vende anche opteron

Criceto: continuiamo a parlare di un vago esagerato. un supercomputer può avere un'infinità di applicazioni. a seconda di queste, può essere costruito in un modo piuttosto che in un altro. se hai bisogno di lavorare esclusivamente con il calcolo vettoriale fai una scelta di un tipo, se invece devi lavorare anche con altri aspetti fai una scelta di un altro tipo. se prevedi che gli farai macinare problemi massivamente paralleli in cui le varie macchine e i vari nodi dovranno continuamente scambiarsi dati fra loro dovrai pensare a macchine in grado di avere un I/O importante e ad una rete strutturata in modo completamente diverso rispetto a un supercluster dove il problema tipico viene affrontato a livello di macchina singola e sulla rete alla fin fine passano poco più che i risultati. e così via. dire che il cell va bene a priori o che "è inutile ci mettano a fianco un powerpc perchè tanto è simile al PPE" è un po' come dire che per te è inutile prendere uno scooter che una bicicletta va bene lo stesso.

oh, posso dirtelo in simpatia? vai un po' a spanne eh :D

anche confrontare la PPE con un powerpc desktop / workstation moderno... beh, dato che non ti fidi di quello che diciamo, ASPETTA, aspetta di vedere le performance in ambito general purpose del cell e poi ci dirai se è meglio avere un g4 E un cell o avere un cell e basta, ok? =) la PPE serve poco più che a coordinare le SPE, se lo metti a lavorare nel general purpose si, lo fa, come lo fa una scheda grafica... anni luci da una cpu che fa quello di mestiere. comunque ripeto, vedremo, eh? =)

anche confrontare la PPE con un powerpc desktop / workstation moderno... beh, dato che non ti fidi di quello che diciamo, ASPETTA, aspetta di vedere le performance in ambito general purpose del cell e poi ci dirai se è meglio avere un g4 E un cell o avere un cell e basta, ok? =) la PPE serve poco più che a coordinare le SPE, se lo metti a lavorare nel general purpose si, lo fa, come lo fa una scheda grafica... anni luci da una cpu che fa quello di mestiere. comunque ripeto, vedremo, eh? =)

Beh a questo punto di speculazioni ne sono state fatte abbastanza. A quanto pare un po' di prototipi funzionanti del Cell ce ne sono già un po' in giro, non resta che aspettare qualche bench...

qualche bench di terze parti, ci aggiungerei :D

E' strano che non sia ancora successo, invece. Quando è stato presentato il Power5, IBM diceva che in contemporanea stava sviluppando versioni "desktop" del processore...
Non ricordo di queste voci...
D'altra parte il 970 è una versione "desktop" del Power4, con 1 solo core e meno cache ma l'aggiunta di Altivec, sostanzialmente.
Non è certo la stessa cosa: Power5 è un mostro che è stato pensato e realizzato proprio per essere dual core e dual-threaded per ogni core. Il suo progettista in un'intervista non ha escluso che possa essere "castrato" per uso desktop, ma era abbastanza scettico proprio per come è stato progettato il Power5.
Appunto. Se ce l'hanno messa è perchè serviva a qualcuno... E chi è l'unica che usa Altivec?!
Apple, indubbiamente, ma se il PPE ha bisogno per poter fare dei calcoli velocemente e per poco tempo, secondo te avrebbe senso che per farlo dovrebbe scomodare una SPE? Perde meno tempo a "fare in casa" che a programmarla e a aspettare il risultato.
Beh i supercomputer con millanta processori ci sono anche adesso. Però costicchiano... A parte il discorso economico, è altamente improbabile che facciano computer con PowerPC "tradizionali" + Cell perchè:
1°] perchè sono troppo simili, la PPE sarebbe un doppione;
Non lo è perché invece è un controller per le SPE, e ha poca potenza di calcolo rispetto a un core PowerPC attuale.
2°] perchè il bus è completamente differente e dovendoli interfacciare con un bus comune le prestazioni del Cell verrebbero in buona parte compromesse.
Appunto, vedi? Il Cell attualmente è in grado di indirizzare 256MB di ram "sua" (Rambus): proprio per questo si candida ad essere sistemato a parte, e chiamato a lavorare al momento del bisogno. Come le GPU.
Molto più semplice mettere 2-4-n Cell. Sono fatti per quello!
Certo, ma li metto a lavorare come schiavi quando servono (calcolo vettoriale e distribuito): per tutto il resto ci sarebbe un ben più potente PowerPC... ;)

Figo sto thread :)

Non ricordo di queste voci...


nei siti di rumors per mac si sentono cose anche più incredibili, vai tranquillo :D

Le capacità di calcolo sono simili: SSE (ma anche le "vecchie" 3DNow! di AMD) e Altivec sono in grado di effettuare 4 operazioni sui 4 dati per ciclo di clock.
Dipende molto dal tipo di operazioni che devono essere effettuate.
Altivec dispone di 2 unità di esecuzione SIMD indipendenti e di 32 registri dedicati a 128bit (contro gli 8 della SSE), mentre SSE condivide parte dell'unità di moltiplicazione con la FPU e quindi deve fare uno state switch ogni volta che la CPU deve usare l'x87 oppure l'unità MMX/SSE.
http://arstechnica.com/articles/paedia/cpu/simd.ars/5

Il numero di operazioni, invece, è superiore nel caso delle SSE: ne conta più di 200, se non erro.
Erri.
MMX -> 57 Istruzioni
SSE -> 70 Istruzioni
SSE2 -> 144 Istruzioni
SSE3 -> 157 Istruzioni
Altivec -> 162 Istruzioni
http://people.ac.upc.edu/alvarez/multimedia/media_isa.html

nel primo articolo che hai citato parlano di SSE, non di SSE2

cmq il vantaggio di altivec è il fatto di avere molti registri dedicati...

Dipende molto dal tipo di operazioni che devono essere effettuate.
Infatti.
Altivec dispone di 2 unità di esecuzione SIMD indipendenti
Non è così: può eseguire una permutazione e un'altra operazione.
e di 32 registri dedicati a 128bit (contro gli 8 della SSE),
Ho già scritto che x86-64 ne ha 16, ma che comunque è difficile trovare algoritmi che utilizzano più di 8 registri.
mentre SSE condivide parte dell'unità di moltiplicazione con la FPU e quindi deve fare uno state switch ogni volta che la CPU deve usare l'x87 oppure l'unità MMX/SSE.
http://arstechnica.com/articles/paedia/cpu/simd.ars/5
Ti stai confondendo con l'uso della FPU x87 quando si usa l'MMX, e viceversa, che richiede appunto un cambio di stato per l'FPU.
Le SSE sono totalmente indipendenti e possono essere eseguite "in parallelo" con altre istruzioni intere o x87 (vedi il manuale intel dell'architettura x87, volume 1: architettura base).
L'unico "problema" è, appunto, la condivisione delle risorse disponibili fra SSE e x87.
Erri.
MMX -> 57 Istruzioni
SSE -> 70 Istruzioni
SSE2 -> 144 Istruzioni
SSE3 -> 157 Istruzioni
Altivec -> 162 Istruzioni
http://people.ac.upc.edu/alvarez/multimedia/media_isa.html
Direi proprio di no: sbaglia quel link, e quindi anche tu.
Se vai a leggere il volume di cui sopra, noterai che le sole SSE hanno AGGIUNTO 48 istruzioni proprie della "sezione" SSE e 14 istruzioni alla "sezione" MMX, per un totale di 62.
Queste si vanno ad aggiungere alle 57 istruzioni introdotte con le MMX.
Le SSE2 AGGIUNGONO altre 144 istruzioni, "duplicando" le istruzioni MMX (rendendole "disponibili" anche per i registri a 128 bit propri delle SSE), e introducendone altre "proprie".
Quindi, a conti fatti, siamo ben oltre le 200 istruzioni per le SSE (e con ciò mi riferivo a tutte le estensioni, in quel contesto).

cmq il vantaggio di altivec è il fatto di avere molti registri dedicati...
Solo se vengono usati... :p

sul fatto che ci siano poche applicazioni che se ne avvantaggiano sono d'accordo, però dovrebbe essere questa la differenza ad esempio in software molto verticali come BLAST dove altivec ha un buon margine su SSE

comunque che io sapevo SSE è più orientato sull'SIMD mentre altivec più sul vettoriale (una cosa non è che escluda l'altra eh)... sbaglio?

sul fatto che ci siano poche applicazioni che se ne avvantaggiano sono d'accordo, però dovrebbe essere questa la differenza ad esempio in software molto verticali come BLAST dove altivec ha un buon margine su SSE
Francamente non so: bisognerebbe analizzare l'algoritmo per esprimere un giudizio. Può anche darsi che utilizzi pochi registri (come accade di solito), ma che si "sposi meglio" con l'implementazione SIMD di Altivec.
comunque che io sapevo SSE è più orientato sull'SIMD mentre altivec più sul vettoriale (una cosa non è che escluda l'altra eh)... sbaglio?
Sono entrambe SIMD, e offrono più o meno le stesse cose. Altivec è sicuramente più "elegante", ma sostanzialmente si equivalgono.

dovrei vedere le istruzioni per farmi un'idea, mi devo aggiornare :D

ps: ma anche il picco in termini di flops è lì lì?

Sì, perché se escludiamo le permutazioni (che servono solamente a "ridisporre" i dati), le istruzioni "utili" (somme, moltiplicazioni, divisioni, ecc.: sto generalizzando, perché in realtà bisognerebbe prendere il throughput di ogni tipo di istruzione) possono essere applicate in misura di una ogni ciclo di clock per entrambe le implementazioni SIMD.

Clock alla mano, non è difficile tirare fuori una stima del valore di picco di FLOPS di un'unità SIMD... ;)

Poi, però, sappiamo che nel mondo reale le cose sono MOLTO diverse... :p

Ho già scritto che x86-64 ne ha 16, ma che comunque è difficile trovare algoritmi che utilizzano più di 8 registri.
Gli ulteriori 8 registri non sono visibili quando la CPU lavora in legacy mode, quindi è come se non esistessero.

Gli ulteriori 32 bit dei registri del G5 non sono visibili quando la CPU lavora in legacy mode, quindi è come se non esistessero.

Gli ulteriori 32 bit dei registri del G5 non sono visibili quando la CPU lavora in legacy mode, quindi è come se non esistessero.

...E quale sarebbe il legacy mode dei G5?

...E quale sarebbe il legacy mode dei G5?

Non sa di cosa sta parlando. Non c'è nessun "legacy mode" sui G5. I PowerPC sono un'architettura a 64 bit fin dall'inizio. E' che le prime implementazioni erano un subset a 32bit...

Ti stai confondendo con l'uso della FPU x87 quando si usa l'MMX, e viceversa, che richiede appunto un cambio di stato per l'FPU.
Le SSE sono totalmente indipendenti e possono essere eseguite "in parallelo" con altre istruzioni intere o x87 (vedi il manuale intel dell'architettura x87, volume 1: architettura base).
L'unico "problema" è, appunto, la condivisione delle risorse disponibili fra SSE e x87.
No.
http://arstechnica.com/articles/paedia/cpu/simd.ars/5
As far as the registers, Intel went ahead and added an extra 8, 128-bit registers for holding SIMD floating-point instructions. These eight are in addition to the 8 MMX/x87 registers that were already there. Since these registers are totally new and independent, Intel had to hold their nose and add an extra processor state to accommodate them. This means a state switch if you want to go from using x87 to MMX or SSE. It also means that OS code had to be rewritten to accommodate the new state.

Direi proprio di no: sbaglia quel link, e quindi anche tu.
Certo. Al politecnico di catalonia pubblicano informazioni sbagliate, certo...

Se vai a leggere il volume di cui sopra, noterai che le sole SSE hanno AGGIUNTO 48 istruzioni proprie della "sezione" SSE e 14 istruzioni alla "sezione" MMX, per un totale di 62.
Queste si vanno ad aggiungere alle 57 istruzioni introdotte con le MMX.
Le SSE2 AGGIUNGONO altre 144 istruzioni, "duplicando" le istruzioni MMX (rendendole "disponibili" anche per i registri a 128 bit propri delle SSE), e introducendone altre "proprie".
Quindi, a conti fatti, siamo ben oltre le 200 istruzioni per le SSE (e con ciò mi riferivo a tutte le estensioni, in quel contesto).

Il tuo conteggio fa' acqua da tutte le parti. Le istruzioni "aggiunte" sono spesso estensioni ad istruzioni già esistenti: non puoi contarle 2 volte.
Leggi il documento di Alvarez, sono elencate e descritte una per una le singole istruzioni...

Non sa di cosa sta parlando. Non c'è nessun "legacy mode" sui G5. I PowerPC sono un'architettura a 64 bit fin dall'inizio. E' che le prime implementazioni erano un subset a 32bit...

no ma spiegami, i binari a 32 bit sfruttano i 64 bit? =)

...E quale sarebbe il legacy mode dei G5?
http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/A1387A29AC1C2AE087256C5200611780/$file/PPC970_MPF2002.pdf

"64-bit Processing - 32-bit Compatibility

• 64-bit advantages
– Driven by need to address larger memory spaces
– Performance advantage for data intensive applications
– Enable new 64-bit solutions

• Native 64-bit mode
– 64-bit fixed point processing
– 64-bit effective addresses
– 42-bit real addresses
– Segment lookaside buffer caches segment table entries

• Native 32-bit mode
– High word of all effective addresses are cleared
– 32-bit PPC application code supported
– First 16 entries of SLB are used as segment registers"

Non sa di cosa sta parlando. Non c'è nessun "legacy mode" sui G5. I PowerPC sono un'architettura a 64 bit fin dall'inizio. E' che le prime implementazioni erano un subset a 32bit...
Vedi sopra: se non sai nulla di quello di cui si parla, faresti meglio a startene zitto...

No.
http://arstechnica.com/articles/paedia/cpu/simd.ars/5
As far as the registers, Intel went ahead and added an extra 8, 128-bit registers for holding SIMD floating-point instructions. These eight are in addition to the 8 MMX/x87 registers that were already there. Since these registers are totally new and independent, Intel had to hold their nose and add an extra processor state to accommodate them. This means a state switch if you want to go from using x87 to MMX or SSE. It also means that OS code had to be rewritten to accommodate the new state.
Invece sì: prenditi i manual di Intel sull'architettura e studiateli.
Certo. Al politecnico di catalonia pubblicano informazioni sbagliate, certo...
Esattamente. A meno che tu non mi voglia dire che sia Intel, da cui sono gli altri a prendere le informazioni, a pubblicarle sbagliate... :rolleyes:
Il tuo conteggio fa' acqua da tutte le parti.
1) ho imparato a contare da tempo;
2) prenditi il manuale di cui sopra e fallo tu il conteggio. :mc:
Le istruzioni "aggiunte" sono spesso estensioni ad istruzioni già esistenti: non puoi contarle 2 volte.
No, quelle sono NUOVE istruzioni. Poi se mi dici anche cosa intendi per "estensioni" di istruzioni già esistenti, e mi fai qualche esempio, magari riesco a capire cosa vuoi dire. Fermo restando quanto già scritto...
Leggi il documento di Alvarez, sono elencate e descritte una per una le singole istruzioni...
Sarebbe meglio che lui leggesse qualche manuale di Intel, e poi si rifacesse i conti.

Io mi fido di quel che pubblica Intel: delle balle che raccontano gli altri non me ne può fregar di meno...

http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/A1387A29AC1C2AE087256C5200611780/$file/PPC970_MPF2002.pdf

"64-bit Processing - 32-bit Compatibility

Appunto, come dice Criceto non hai le idee chiare.
PowerPC permette di far girare le applicazioni a 32bit in compatibility mode non in legacy mode (che non esiste...)
La stessa cosa avviene in x86-64 dove le applicazioni x86-32 possono girare in compatibility mode solo quando la CPU è in modalità long mode, mentre in legacy mode le istruzioni a 64bit non sono visibili, nè lo sono gli ulteriori 8 registri SSE

Appunto, come dice Criceto non hai le idee chiare.
PowerPC permette di far girare le applicazioni a 32bit in compatibility mode non in legacy mode (che non esiste...)

Capzioso. "Compatibility" e "Legacy" sono sinonimi in questa accezione informatica dei termini.

Certo. Al politecnico di catalonia pubblicano informazioni sbagliate, certo...


Possibile. Nessuno gode dell'infallibilita' papale.

Capzioso. "Compatibility" e "Legacy" sono sinonimi in questa accezione informatica dei termini.

Affatto. Sono due modalità differenti in cui possono lavorare i processori x86-64: Long mode (al cui interno le applicazioni a 32bit possono girare in compatibility mode) e Legacy Mode (quella in cui simula un x86 e unica altamente sfruttata da WindowsXP).
http://arstechnica.com/cpu/03q1/x86-64/x86-64-4.html

Possibile. Nessuno gode dell'infallibilita' papale.
Certo, ma siccome nel link che ho riportato sono elencate una per una, basta un esempio del tipo "l'istruzione blabla non è riportata nella tabella"...

Affatto. Sono due modalità differenti in cui possono lavorare i processori x86-64: Long mode (al cui interno le applicazioni a 32bit possono girare in compatibility mode) e Legacy Mode (quella in cui simula un x86 e unica altamente sfruttata da WindowsXP).
http://arstechnica.com/cpu/03q1/x86-64/x86-64-4.html

Non sono entrato nel merito della discussione (non so molto a riguardo). Ho solo detto che in inglese Compatibility e Legacy in accezione informatica sono sinonimi.
Se scrivi solo "Affatto", dai ragione all'interlocutore ;)

Non sono entrato nel merito della discussione (non so molto a riguardo). Ho solo detto che in inglese Compatibility e Legacy in accezione informatica sono sinonimi.
Se scrivi solo "Affatto", dai ragione all'interlocutore ;)

Intendevo "niente affatto", comunque "legacy mode" è una modalità in cui possono funzionare i processori x86-64, come "real mode" e "protected mode" per gli x86-32.

Intendevo "niente affatto", comunque "legacy mode" è una modalità in cui possono funzionare i processori x86-64, come "real mode" e "protected mode" per gli x86-32.

Se intendi no, scrivi no, non si'. Dai, sto scherzando :)
Ti ho detto che non sto entrando nel merito della vostra questione, ho solo puntualizzato che i termini legacy e compatibility possono essere usati uno per l'altro, non e' un errore.

Se intendi no, scrivi no, non si'. Dai, sto scherzando :)
Ti ho detto che non sto entrando nel merito della vostra questione, ho solo puntualizzato che i termini legacy e compatibility possono essere usati uno per l'altro, non e' un errore.
No, in compatibility mode il control bit LMA è settato mentre in legacy è a 0.
Sono due modalità operative completamente diverse!
http://www.dinoxpc.com/Tests/PROCESSORI/Preview_AMD64/images/athlon64_1.gif
http://www.hwupgrade.it/articoli/902/5.html
http://arstechnica.com/cpu/03q1/x86-64/x86-64-4.html
http://www.extremetech.com/article2/0,1558,1196657,00.asp
http://www.dinoxpc.com/Tests/PROCESSORI/Preview_AMD64/pag2.asp

Appunto, come dice Criceto non hai le idee chiare.
PowerPC permette di far girare le applicazioni a 32bit in compatibility mode non in legacy mode (che non esiste...)
La stessa cosa avviene in x86-64 dove le applicazioni x86-32 possono girare in compatibility mode solo quando la CPU è in modalità long mode, mentre in legacy mode le istruzioni a 64bit non sono visibili, nè lo sono gli ulteriori 8 registri SSE
T'hanno già risposto: è quel che intendevo. Compatibilità all'indietro con le applicazioni a 32 bit.

Poi è singolare che proprio tu ti attacchi a dei cavilli di poco conto ai fini della discussione, quando in certi thread hai battuto in ritirata su questioni ben più importanti...

E' chiaro che le due architetture sono completamente differenti e hanno una diverso modo di gestire l'esecuzione di applicazioni a 32 bit in un ambientee / s.o. a 64 bit. Mi sembra ovvio, no?

EDIT: corretto "cavalli" con "cavilli"... :asd:

Certo, ma siccome nel link che ho riportato sono elencate una per una, basta un esempio del tipo "l'istruzione blabla non è riportata nella tabella"...
Se invece prendi i MANUALI DI INTEL, che il processore l'ha fatto, e ti fai i conti, non pensi che sia ancora meglio?
O vuoi dirmi che Intel non è una fonte abbastanza autorevole per quanto riguarda informazioni sull'architettura che lei stessa ha sviluppato? :rolleyes:

No, in compatibility mode il control bit LMA è settato mentre in legacy è a 0.

Forse non mi sono spiegato. Non mi interessa, non sto entrando nel merito di una questione che non conosco abbastanza per intervenire.
Ho detto, ed e' inutile ripeterlo, che i due termini possono essere usati come sinonimi in inglese in questa accezione.

Se invece prendi i MANUALI DI INTEL, che il processore l'ha fatto, e ti fai i conti, non pensi che sia ancora meglio?
O vuoi dirmi che Intel non è una fonte abbastanza autorevole per quanto riguarda informazioni sull'architettura che lei stessa ha sviluppato? :rolleyes:

No, dico solo che la tua interpretazione dei manuali intel non è autorevole.

xfek: ed è proprio quello che ho fatto io... ;)

Speriamo che si capisca una volta per tutte e si torni a parlare di qualcosa di più serio che l'uso di un termine piuttosto che un altro per indicare la stessa cosa... :p

No, dico solo che la tua interpretazione dei manuali intel non è autorevole.
Allora se mi spieghi gentilmente come dovrebbero essere interpretati, facendo qualche esempio pratico (preso dai suddetti manuali, ovviamente), magari riusciamo a chiudere anche questo punto della discussione... ;)

Forse non mi sono spiegato. Non mi interessa, non sto entrando nel merito di una questione che non conosco abbastanza per intervenire.
Ho detto, ed e' inutile ripeterlo, che i due termini possono essere usati come sinonimi in inglese in questa accezione.
Va ben, ma io parlavo di "legacy mode" come modalità operativa dei processori x86-64.

Va ben, ma io parlavo di "legacy mode" come modalità operativa dei processori x86-64.

Perfetto, niente in contrario.

Va ben, ma io parlavo di "legacy mode" come modalità operativa dei processori x86-64.
E vabbé, lo sappiamo benissimo che è un termine usato nell'architettura x86-64, ma hai mai visto usare la parola "legacy" in altri contesti, anche simili? Direi che esempi non ne mancano certo...

Con ciò, e l'ho già ripetuto fino alla nausea, intendevo la compatibilità all'indietro con le "vecchie" applicazioni: a 32 bit in questo caso, per Tiger col G5, come potevano essere le vecchie applicazioni (e codice) a 16 bit (DOS, Windows 3.1) che Windows 95 supportava, ecc. ecc. ecc. ecc.

C'è bisogno di continuare sulla stessa, inutile, strada ancora?

Inutile che cerchi di girare la frittata. Hai detto:

Gli ulteriori 32 bit dei registri del G5 non sono visibili quando la CPU lavora in legacy mode, quindi è come se non esistessero.

Ammesso anche che si possa confondere compatibility con legacy mode (cosa che IBM e AMD non fanno) non è vero che i 32 registri Altivec non sono disponibili in compatibility mode visto che esistono anche nel G4.

Inutile che cerchi di girare la frittata. Hai detto:
Non sono il tipo, e ormai dovresti saperlo molto bene: non ho difficoltà ad ammettere di aver sbagliato, l'ho già fatto altre volte, e al contrario di te... :rolleyes:

Quanto a quello che ho scritto: ti sei accorto che ho preso in prestito quella tua frase e l'ho "ritoccata"? Era (chiaramente, per me) una battuta sull'argomento.
Questo, per essere precisi, era il mio pensiero: "come gli 8 registri in più delle SSE implementate con gli x86-64 sono un'innovazione inutilizzabile coi vecchi processori, lo stesso vale per i 64 bit dei G5".

In buona sostanza, le architetture si evolvono e rendono disponibili innovazioni non fruibili per le macchine passate. Questo è particolarmente vero per l'ISA dei processori, e le SIMD in particolare che sono l'oggetto della discussione.

A tal fine basta fermarsi a riflettere sulla loro storia: le Altivec sono state le prime estensioni SIMD dell'architettura PowerPC, sono state introdotte coi G4 e sono rimaste immodificate fino al G5; le MMX sono state le prime (in assoluto) SIMD arrivate su computer desktop, e col passare del tempo sono arrivate le SSE, le SSE2, le SSE3 (sto tralasciando le 3DNow! di AMD, arrivate dopo le MMX e prima delle SSE) e in ultimo il raddoppio dei loro registri con "l'implementazione x86-64".

Se volessimo togliere di mezzo quest'ultima loro evoluzione, quando dovremmo fermarci a livello temporale? A rigor di logica, dopo quello che è stato scritto, alle SSE, che sono le ultime SIMD per x86 arrivate prima dell'avvento di Altivec; soltanto che le SSE hanno fatto storia e le più usate ADESSO sono le SSE2, e anche le SSE3 stanno iniziando ad essere usate (sebbene apportino ben pochi benefici a livello prestazionale), e allo stesso modo gli altri 8 registri delle SSEx per x86-64 saranno utilizzati presto, visto che la piattaforma x86 si sta spostando su questa nuova architettura.

Concludendo: se dobbiamo confrontare le estensioni SIMD, dobbiamo farlo con quanto ADESSO ci propone il mercato; lo stesso vale per le architetture in generale: ADESSO ci sono i G5 che sono a 64 bit, e lo stesso vale per x86-64.
Ammesso anche che si possa confondere compatibility con legacy mode
Direi proprio di sì, visto che il significato di "legacy" in questo contesto è univoco. D'altra parte è un termine che nell'ambito dell'informatica è stato usato da anni con un preciso significato: la "compatibilità all'indietro". Hai qualcosa da ridire anche su questo?
(cosa che IBM e AMD non fanno)
IBM e AMD possono chiamare la compatibilità all'indietro dei loro processori "capra mode" e "cavoli mode", rispettivamente: cambierebbe qualcosa nella nostra discussione?
non è vero che i 32 registri Altivec non sono disponibili in compatibility mode visto che esistono anche nel G4.
E chi lo nega questo? Quel che volevo dire era tutt'altra cosa: vedi sopra... ;)

Quanto a quello che ho scritto: ti sei accorto che ho preso in prestito quella tua frase e l'ho "ritoccata"? Era (chiaramente, per me) una battuta sull'argomento.
Questo, per essere precisi, era il mio pensiero: "come gli 8 registri in più delle SSE implementate con gli x86-64 sono un'innovazione inutilizzabile coi vecchi processori, lo stesso vale per i 64 bit dei G5".
...A parte il fatto che sbaglieresti ancora perché MacOsX supporta già i 64bit:
http://www.apple.com/macosx/features/64bit/
...si stava parlando di altivec e SSE!

A tal fine basta fermarsi a riflettere sulla loro storia: le Altivec sono state le prime estensioni SIMD dell'architettura PowerPC, sono state introdotte coi G4 e sono rimaste immodificate fino al G5; le MMX sono state le prime (in assoluto) SIMD arrivate su computer desktop, e col passare del tempo sono arrivate le SSE, le SSE2, le SSE3 (sto tralasciando le 3DNow! di AMD, arrivate dopo le MMX e prima delle SSE) e in ultimo il raddoppio dei loro registri con "l'implementazione x86-64".
Quindi secondo te è meglio introdurre MMX, poi 3DNow, poi SSE, poi 3dNow+, poi SSE2, poi SSE3, .... in modo da spiazzare i programmatori o è meglio introdurre un'architettura Altivec definitiva fin dall'inizio e poi potenziarla mantenendone invariate le istruzioni e migliorando le unità di esecuzione (aumento di pipeline da 2 a 4 da G4 a G4e, aumento e potenziamento delle VU, ecc...)?

Direi proprio di sì, visto che il significato di "legacy" in questo contesto è univoco. D'altra parte è un termine che nell'ambito dell'informatica è stato usato da anni con un preciso significato: la "compatibilità all'indietro". Hai qualcosa da ridire anche su questo?
IBM e AMD possono chiamare la compatibilità all'indietro dei loro processori "capra mode" e "cavoli mode", rispettivamente: cambierebbe qualcosa nella nostra discussione?
Certo, certo, AMD e IBM danno i nomi "a vanvera" per le modalità di funzionamento dei loro processori....

...A parte il fatto che sbaglieresti ancora perché MacOsX supporta già i 64bit:
http://www.apple.com/macosx/features/64bit/
...si stava parlando di altivec e SSE!
Ed è proprio di quello che parlavo io.

Poi, rimanendo in tema con ciò che ho scritto (rileggitelo, che è meglio), mi fai vedere come gira OS X a 64 bit coi G4... :asd:
Quindi secondo te è meglio introdurre MMX, poi 3DNow, poi SSE, poi 3dNow+, poi SSE2, poi SSE3, .... in modo da spiazzare i programmatori o è meglio introdurre un'architettura Altivec definitiva fin dall'inizio e poi potenziarla mantenendone invariate le istruzioni e migliorando le unità di esecuzione (aumento di pipeline da 2 a 4 da G4 a G4e, aumento e potenziamento delle VU, ecc...)?
1) Questo è UN ALTRO DISCORSO (a cui comunque rispondo, non c'è problema);
2) le 3DNow! AMD le ha create per avere una posizione di vantaggio su Intel, che rispose soltanto 6 mesi più tardi con le SSE;
3) è chiaro che avere un unico ISA fin dall'inizio è meglio; ciò non toglie che le MMX sono state il primo esperimento di Intel nel campo desktop: potevano andare bene come pure male, e occupavano (preziosi) transistor: alla luce dei benefici ottenuti, AMD prima e Intel poi, hanno pianificato le estensioni con valori in virgola mobile, che hanno un ambito di utilizzo completamente diverso, per cui i programmatori non si sono trovati spiazzati (fino a questo punto); le SSE2 sono state introdotte per aggiungere il supporto ad altri tipi di dati (interi a 64 bit e valori in doppia precisione, che mancano ad Altivec), migliorare il set d'istruzioni e per fare a meno delle MMX per quanto riguarda l'elaborazione con valori interi (in precedenza MMX era esclusivamente deputato agli interi, mentre le SSE alla virgola mobile in singola precisione), quindi per dare ai programmatori un set d'istruzioni "omogeneo";
4) non hai risposto all'osservazione che ho fatto, e di cui ti faccio un riepilogo: quando si confrontano le estensioni SIMD, dove ci si deve fermare (SSE, SSE2, SSE3, "estensione" x86-64)?
Certo, certo, AMD e IBM danno i nomi "a vanvera" per le modalità di funzionamento dei loro processori....
:mc: Continui ad arrampicarti sugli specchi... :rolleyes: Il discorso è chiaro: A PRESCINDERE DA COME LO SI CHIAMI, il discorso verte(va) sulla COMPATIBILITA' COL PASSATO dei processori.
Poi se a te interessa continuare a disquisire sulle etichette anziché sul ben più importante contenuto, non hai che da dirlo chiaramente... :rolleyes:

Ed è proprio di quello che parlavo io.

Poi, rimanendo in tema con ciò che ho scritto (rileggitelo, che è meglio), mi fai vedere come gira OS X a 64 bit coi G4... :asd:

Fammi vedere come gire WindowsXP a 64bit (quando uscirà, nel 2027) sugli AthlonXP, allora! :asd:

1) Questo è UN ALTRO DISCORSO (a cui comunque rispondo, non c'è problema);
2) le 3DNow! AMD le ha create per avere una posizione di vantaggio su Intel, che rispose soltanto 6 mesi più tardi con le SSE;
3) è chiaro che avere un unico ISA fin dall'inizio è meglio; ciò non toglie che le MMX sono state il primo esperimento di Intel nel campo desktop: potevano andare bene come pure male, e occupavano (preziosi) transistor: alla luce dei benefici ottenuti, AMD prima e Intel poi, hanno pianificato le estensioni con valori in virgola mobile, che hanno un ambito di utilizzo completamente diverso, per cui i programmatori non si sono trovati spiazzati (fino a questo punto); le SSE2 sono state introdotte per aggiungere il supporto ad altri tipi di dati (interi a 64 bit e valori in doppia precisione, che mancano ad Altivec), migliorare il set d'istruzioni e per fare a meno delle MMX per quanto riguarda l'elaborazione con valori interi (in precedenza MMX era esclusivamente deputato agli interi, mentre le SSE alla virgola mobile in singola precisione), quindi per dare ai programmatori un set d'istruzioni "omogeneo";
Quindi, secondo te, è meglio questo caos ad un set di istruzioni per il calcolo vettoriale definitivo fin dall'inizio? :asd:

4) non hai risposto all'osservazione che ho fatto, e di cui ti faccio un riepilogo: quando si confrontano le estensioni SIMD, dove ci si deve fermare (SSE, SSE2, SSE3, "estensione" x86-64)?
E' proprio questo il problema.
Alla IBM hanno stabilito un set di istruzioni definitivo fin dall'inizio aumentando poi l'efficienza delle unità vettoriali e mantenendo costante il set. Un programmatore che vuole utilizzare la tecnologia SIMD sa che Altivec funziona, pur con prestazioni differenti, dai primi G4 a 300 Mhz (o quel che è) fino agli attuali G5.
Un programmatore che vuole utilizzare il SIMD sui processori x86 dove si deve fermare? Alle MMX, alle 3DNow, alle 3DNow+, alle SSE, alle SSE2, alle SSE3, alle estensioni introdotte con l'x86-64, oppure deve aspettare le TejasNewInstructions o cosa?

:mc: Continui ad arrampicarti sugli specchi... :rolleyes: Il discorso è chiaro: A PRESCINDERE DA COME LO SI CHIAMI, il discorso verte(va) sulla COMPATIBILITA' COL PASSATO dei processori.
Poi se a te interessa continuare a disquisire sulle etichette anziché sul ben più importante contenuto, non hai che da dirlo chiaramente... :rolleyes:
Legacy e Compatibility servono entrambe alla compatibilità con il passato, ma essa viene raggiunta con modalità completamente differenti.

Fammi vedere come gire WindowsXP a 64bit (quando uscirà, nel 2027) sugli AthlonXP, allora! :asd:
Non provare a rigirare la frittata: il discorso è fin troppo chiaro... :rolleyes:

Preferisci che ti faccia il copia & incolla di tutto quello che abbiamo detto in merito, in sequenza temporale e commentato? Oppure la finisci di continuare ad arrampicarti sugli specchi cercando di cambiare discorso?
Quindi, secondo te, è meglio questo caos ad un set di istruzioni per il calcolo vettoriale definitivo fin dall'inizio? :asd:
Questa è UN'ALTRA DOMANDA, a cui rispondo (a differenza di te) che è chiaramente preferibile la soluzione già bella e pronta.

Però a quanto vedo tu ami non rispondere (sto ancora ancora aspettando) né tanto meno valutare il contesto storico di ogni cosa e trarne le giuste valutazioni... :rolleyes:
E' proprio questo il problema.
Alla IBM hanno stabilito un set di istruzioni definitivo fin dall'inizio aumentando poi l'efficienza delle unità vettoriali e mantenendo costante il set. Un programmatore che vuole utilizzare la tecnologia SIMD sa che Altivec funziona, pur con prestazioni differenti, dai primi G4 a 300 Mhz (o quel che è) fino agli attuali G5.
Indubbiamente, e ho anche detto che Altivec è l'architettura SIMD più elegante.

Una precisazione, comunque: i primi G4 avevano 4 stadi di pipeline, e i G4e 7.
Un programmatore che vuole utilizzare il SIMD sui processori x86 dove si deve fermare? Alle MMX, alle 3DNow, alle 3DNow+, alle SSE, alle SSE2, alle SSE3, alle estensioni introdotte con l'x86-64, oppure deve aspettare le TejasNewInstructions o cosa?
Usa compilatore che gli permette di usare quel che è disponibile.

A questo punto ti faccio un'altra domanda sul tema: preferisci avere un pezzo di tecnologia oggi, un altro pezzo domani, un altro dopodomani, ecc. oppure aspettare un bel po' di tempo prima di poter avere tutta la tecnologia tra le mani e poterla sfruttare?

E un'altra ancora (legata alla precedente): secondo te l'evoluzione delle architetture deve necessariamente procedere "a salti" che determinano un contesto determinato e scevro di ulteriori cambiamenti, oppure procedere gradualmente, presentando dei miglioramenti col passare del tempo, che è possibile sfruttare subito, e che rispondo alle nuove esigenze che sono intervenute nel sistema?
Legacy e Compatibility servono entrambe alla compatibilità con il passato, ma essa viene raggiunta con modalità completamente differenti.
Lapalisse ti fa un baffo, visto che si tratta di architetture completamente diverse che hanno problemi diversi per quanto riguarda la compatibilità col passato...
Ma il nocciolo, alla fine, è sempre lo stesso.

Non provare a rigirare la frittata: il discorso è fin troppo chiaro... :rolleyes:

Preferisci che ti faccia il copia & incolla di tutto quello che abbiamo detto in merito, in sequenza temporale e commentato? Oppure la finisci di continuare ad arrampicarti sugli specchi cercando di cambiare discorso?
Si stava parlando di altivec. Hai tirato fuori dal nulla i 64bit, chissà perché, poi.
Windows a64bit non girerà sui processori a 32bit così come MacOsX non gira sui G4. E allora? Quale sarebbe tutto questo vantaggio di Intel e AMD rispetto ai PPC?

è chiaramente preferibile la soluzione già bella e pronta.
Finalmente ci sei arrivato anche tu!

Usa compilatore che gli permette di usare quel che è disponibile.
Quindi proponi che l'utente si ricompili i sorgenti in base alle istruzioni vettoriali disponibili sulla sua macchina?
Comodo! :asd:

A questo punto ti faccio un'altra domanda sul tema: preferisci avere un pezzo di tecnologia oggi, un altro pezzo domani, un altro dopodomani, ecc. oppure aspettare un bel po' di tempo prima di poter avere tutta la tecnologia tra le mani e poterla sfruttare?
La seconda.

E un'altra ancora (legata alla precedente): secondo te l'evoluzione delle architetture deve necessariamente procedere "a salti" che determinano un contesto determinato e scevro di ulteriori cambiamenti, oppure procedere gradualmente, presentando dei miglioramenti col passare del tempo, che è possibile sfruttare subito, e che rispondo alle nuove esigenze che sono intervenute nel sistema?
A salti.

Comunque sono due quesiti che non rappresentano la realtà. AMD/Intel hanno deciso di evolvere la loro architettura di calcolo vettoriale aggiungendo le istruzioni "a rate" e spiazzando i programmatori mentre alla IBM hanno deciso di presentare un'architettura vettoriale già completa all'inizio (con buona pace dei programmatori) e di evolverla aumentando la velocità con cui vengono eseguite le istruzioni.
Non è vero che IBM non ha fatto evolvere la tecnologia altivec e non è vero che la SSE è arrivata tanto prima dell'Altivec. Solo le MMX esistevano da prima, ma non sono neppure lontanamente paragonabili all'Altivec.
Il mercato delle console per videogiochi, poi, dove le istruzioni vettoriali sono molto sfruttate, sta premiando l'architettura IBM/Altivec. Sarà un caso?

Si stava parlando di altivec. Hai tirato fuori dal nulla i 64bit, chissà perché, poi.
Ecco la cronistoria:

TU: L'unità di calcolo AltiVec è dotata di 32 registri a 128 bit a differenza dei 8 registri a 128 dell'unità SSE2
IO: Sono 16 per x86-64...

Qui ho semplicemente precisato che con x86-64 ce ne sono 16 e non 8 (come accade con le architetture precedenti).

TU: Altivec dispone di 2 unità di esecuzione SIMD indipendenti e di 32 registri dedicati a 128bit (contro gli 8 della SSE)
IO: Ho già scritto che x86-64 ne ha 16

Idem come sopra. Come dire: non puoi generalizzare e dire che le SSE ne hanno soltanto 8; questo vale per le vecchie architetture, ma non per quelle nuove, che ne hanno 16.

TU: Gli ulteriori 8 registri non sono visibili quando la CPU lavora in legacy mode, quindi è come se non esistessero.
IO: Gli ulteriori 32 bit dei registri del G5 non sono visibili quando la CPU lavora in legacy mode, quindi è come se non esistessero.

Qui ho ribadito (con un battuta: predendo in prestito le tue parole) che gli 8 registri in più degli x86-64 non sono visibili quando la CPU lavora in legacy mode tanto quanto i 32 bit superiori dei registri del G5 non lo sono quando la CPU lavora in compatibily mode (ho usato i termini giusti: contento?)
In buona sostanza: le innovazioni introdotte dai nuovi processori ovviamente non sono sfruttabili dai vecchi processori o quando quelli nuovi lavorano in modalità "legacy" (qui uso il termine informatico per tutti e due).

Poi il discorso è passato sulla diatriba compatibility vs legacy, che ho precisato con questa frase:

IO: Con ciò, e l'ho già ripetuto fino alla nausea, intendevo la compatibilità all'indietro con le "vecchie" applicazioni: a 32 bit in questo caso, per Tiger col G5, come potevano essere le vecchie applicazioni (e codice) a 16 bit (DOS, Windows 3.1) che Windows 95 supportava, ecc. ecc. ecc. ecc.

Al che tu hai continuato sullo stesso binario di cui sopra:

TU: non è vero che i 32 registri Altivec non sono disponibili in compatibility mode visto che esistono anche nel G4.
IO: il mio pensiero: "come gli 8 registri in più delle SSE implementate con gli x86-64 sono un'innovazione inutilizzabile coi vecchi processori, lo stesso vale per i 64 bit dei G5".
In buona sostanza, le architetture si evolvono e rendono disponibili innovazioni non fruibili per le macchine passate. Questo è particolarmente vero per l'ISA dei processori, e le SIMD in particolare che sono l'oggetto della discussione.
[...]
Concludendo: se dobbiamo confrontare le estensioni SIMD, dobbiamo farlo con quanto ADESSO ci propone il mercato; lo stesso vale per le architetture in generale: ADESSO ci sono i G5 che sono a 64 bit, e lo stesso vale per x86-64.

Questo si commenta da solo. Da notare che NON PARLAVO DI SISTEMI OPERATIVI, ma di architetture.

TU: ...A parte il fatto che sbaglieresti ancora perché MacOsX supporta già i 64bit:
http://www.apple.com/macosx/features/64bit/
...si stava parlando di altivec e SSE!
IO: Poi, rimanendo in tema con ciò che ho scritto (rileggitelo, che è meglio), mi fai vedere come gira OS X a 64 bit coi G4...

Quindi tu tiri fuori OS X, un s.o. (non si parlava di architetture? ;)), e dici che già supporta i 64 bit. Il che è indubbiamente vero, ma per farlo DEVE GIRARE PER FORZA SU UN G5, che supporta appunto i 64 bit.
Quindi per sfruttare i 64 bit devi avere un s.o. operativo che li supporti (OS X) E (congiunzione) un processore che permetta di usarli (G5).
Da qui la mia battuta su OS X a 64 bit e G4.

Lo stesso vale per gli 8 registri in più delle SSE degli x86-64: li posso usare, ma soltanto con un s.o. che supporti quest'architettura nativamente (Linux a 64 bit, XP / 64). Altrimenti, in "legacy mode" (termine generico), è come se non esistessero, appunto.
Idem per i processori "vecchi": XP / 64 non ci gira e non possono sfruttare gli 8 registri in più delle SSE.

Conclusione: se tu mi parli di OS X che supporta i 64 bit, vuol dire che prendi come base di partenza i G5, c'è poco da fare; quindi per usare strumenti nuovi (OS X a 64 bit) sono assolutamente necessarie architetture nuove (G5).

TU: Fammi vedere come gire WindowsXP a 64bit (quando uscirà, nel 2027) sugli AthlonXP, allora!

Dopo tutto quello che si è detto, è evidente che questa che hai scritto è una battuta fuori luogo. Infatti il discorso era già chiaro (e pure ovvio): strumenti nuovi richiedono architetture nuove.
Se tiri in ballo OS X a 64 bit, devi necessariamente far riferimento al G5 (nuova architettura che permette di usare registri a 64 bit), a allo stesso modo posso fare con x86-64: è una nuova architettura, che introduce altri 8 registri per le SSE, e che posso sfruttare con un s.o. che la richieda espressamente.
Windows a64bit non girerà sui processori a 32bit così come MacOsX non gira sui G4. E allora?
Vedi sopra. Ti basta come spiegazione? ;)
Quale sarebbe tutto questo vantaggio di Intel e AMD rispetto ai PPC?
Di cosa stai parlando? Questo è (ancora una volta) UN ALTRO DISCORSO (vedi sopra la ricostruzione), e tra l'altro non ti posso neppure rispondere perché il contesto non è affatto chiaro (parli di vantaggio, ma dove / come / quando / perché?)
Finalmente ci sei arrivato anche tu!
Da un pezzo, ma non è che ci voglia molto per trarre una conclusione banale come quella... ;)
Poi c'è gente che purtroppo ha bisogno che gli si scriva anche le banalità...
Quindi proponi che l'utente si ricompili i sorgenti in base alle istruzioni vettoriali disponibili sulla sua macchina?
Comodo! :asd:
A quali compilatori sei rimasto? A quelli di dieci anni fa? :rolleyes:

Gli utenti devono semplicemente clickare su setup.exe: il compilatore ha già provveduto a infilarci il codice giusto per le architetture che supporta, e a selezionare i code path adeguati da eseguire a runtime. Ed è lavoro che fa il programmatore all'atto della compilazione, non l'utente... :mc:
La seconda.

A salti.

Comunque sono due quesiti che non rappresentano la realtà.
Direi di sì, invece, se ri fa riferimento alla storia: cosa che tu trascuri spesso nei tuoi discorsi...
AMD/Intel hanno deciso di evolvere la loro architettura di calcolo vettoriale aggiungendo le istruzioni "a rate" e spiazzando i programmatori
Non è affatto così, e te l'ho già scritto. E' stata Intel la prima, ed è stata una "scommessa" che ha fatto con le MMX.
Considerati i tempi di allora, i processi produttivi utilizzabili dai i processori, il numero di transistor che era possibile / sensato infilare in un core, direi che è stato un giusto compromesso.

Le 3DNow! prima e le SSE(1) dopo sono nate grazie al successo ottenuto dalle MMX, e all'evoluzione dei fattori di cui sopra.
mentre alla IBM hanno deciso di presentare un'architettura vettoriale già completa all'inizio (con buona pace dei programmatori) e di evolverla aumentando la velocità con cui vengono eseguite le istruzioni.
Non è stata IBM, ma Motorola. Comunque complimenti: è arrivata DOPO che gli altri avevano già sperimentato (e su cui ha potuto studiare e confrontarsi), e con gli strumenti (di cui sopra) maturi per poterlo fare. E' chiaro che è stato più semplice per lei aggiungere le Altivec in colpo solo, e farla evolvere esclusivamente a livello di implementazione (quelle di Motorola e IBM sono abbastanza diverse).
Non è vero che IBM non ha fatto evolvere la tecnologia altivec
Infatti non l'ha fatta evolvere: ha migliorato / adattato l'implementazione di Motorola (e infatti non può usare Altivec come nome perché è di proprietà di Motorola;)).
e non è vero che la SSE è arrivata tanto prima dell'Altivec.
E' arrivata DOPO. Punto.
Solo le MMX esistevano da prima,
Esistevano MMX, 3DNow! (arrivate 6 mesi prima delle SSE di Intel) e le SSE prima di Altivec.
ma non sono neppure lontanamente paragonabili all'Altivec.
E chi l'ha mai negato? Hai presente quando sono state introdotte le MMX, e in quale contesto storico (vedi sopra)?

Tu lo vedi un Pentium MMX con tanti milioni di transistor per implementare una soluzione equivalente ad Altivec? Quanti transistor doveva avere? Quanto doveva essere grande il core? Quanto doveva consumare quel processore?

Come fai a non considerare tutte queste cose importantissime quando scrivi? :rolleyes:
Il mercato delle console per videogiochi, poi, dove le istruzioni vettoriali sono molto sfruttate, sta premiando l'architettura IBM/Altivec. Sarà un caso?
Il mercato dei PC usati per videogiochi, poi, dove le istruzioni vettoriali sono molto sfruttate, sta premiando l'architettura Intel-AMD/SSEx. Sarà un caso?

Vediamo se questa la capisci (e non dirmi il mercato dei giochi per PC è una miseria rispetto a quello delle console, perché comincio a ridere già da adesso) o dobbiamo ricominciare con il solito ping-pong di messaggi, che poi finiscono come il riassunto delle puntate precedenti delle soap opera... :asd:

A quali compilatori sei rimasto? A quelli di dieci anni fa? :rolleyes:

Gli utenti devono semplicemente clickare su setup.exe: il compilatore ha già provveduto a infilarci il codice giusto per le architetture che supporta, e a selezionare i code path adeguati da eseguire a runtime. Ed è lavoro che fa il programmatore all'atto della compilazione, non l'utente... :mc:


Il compilatore C++ del VS2004 ha opzioni per produrre auotamticamente codice SSE, SEE2 e 3DNow! (se non ricordo male). Non e' gran codice, ma meglio di nulla.
E' un nulla compilare lo stesso file in tre versioni diverse, coprirlo da un'interfaccia e selezionare a runtime l'implementazione in base alla piattaforma; e' una banale applicazione di uno Strategy Pattern.

Infatti. Poi ci sono i compilatori Intel che sono dei veri gioielli, visto che infilano in un unico eseguibile il codice ottimizzato per diverse piattaforme (purtroppo solamente quelle per CPU Intel), e che alla partenza scelgono il code path "ottimale" per il processore riconosciuto.

Il massimo sarebbe, estendendo il funzionamento degli exe, delegare al s.o. il riconoscimento delle risorse disponibili (tipo di CPU, tipo di GPU) e selezionare / caricare dall'eseguibile i soli hunk necessari per il sistema corrente... :p

Il massimo sarebbe, estendendo il funzionamento degli exe, delegare al s.o. il riconoscimento delle risorse disponibili (tipo di CPU, tipo di GPU) e selezionare / caricare dall'eseguibile i soli hunk necessari per il sistema corrente... :p

Stai parlando di .NET? ;)

X fek:
Non esiste il visual studio 2004. C'è il 2003 ed uscirà presto il 2005 (è in beta).

Infatti. Poi ci sono i compilatori Intel che sono dei veri gioielli, visto che infilano in un unico eseguibile il codice ottimizzato per diverse piattaforme (purtroppo solamente quelle per CPU Intel), e che alla partenza scelgono il code path "ottimale" per il processore riconosciuto.

Uso il visual studio 2003.
Mi fai un esempio di codice in C o C++ che compilato produce ciò che hai appena detto?

Vediamo cosa dice la Microsoft del supporto alle MMX SSEx, ecc:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrfmmxssesse2intrisics.asp
Data alignment e Inline assembly. Altro che code path, versioni di codice differenti per ogni tipo di processore.... :asd:

Vediamo cosa dice la Apple:
http://developer.apple.com/hardware/ve/vector_libraries.html
Un framwork per il DSP, uno per l'image processing, BLAS/LAPACK per l'algebra lineare....

Proprio la stessa cosa ;)

1) Per VisualStudio fek ti ha già risposto.
2) Per cosa dice MS, idem.
3) Cosa c'entra il link di Apple? A cosa vuoi arrivare?
4) Per quanto riguarda Intel e i suoi compilatori, che era il pezzo che mi hai quotato, ti faccio vedere come si fa.

Intanto un bel link informativo, che non fa mai male: http://www.intel.com/software/products/compilers/cwin/cwindows.htm#advancedoptimizationfeatures
In particolare:
Runtime Support for Generations of Intel Processors: Processor Dispatch (IA-32 processors only): Optionally build applications for a specific generation of Intel processor using processor dispatch. Dispatch now allows for multiple specific targets. Perform application development for the latest Intel processor - the Pentium 4 processor - while simultaneously maintaining the ability for the executable to run on previous IA-32 processors
Ecco lo switch del compilatore da usare per ottenere ciò: /Qax{K|W|N|B|P}. Qui c'è la descrizione di questo switch:
Automatic Processor Dispatch. Generates specialized code for the indicated processors while also generating
generic IA-32 code. You can use more than one code to tune for multiple processors in the same executable.
K Intel Pentium III and compatible Intel processors
W - Intel Pentium 4 and compatible Intel processors, excluding those with Intel EM64T
B - Intel Pentium M and compatible Intel processors
P - Intel Pentium 4 processor with Streaming SIMD Extensions 3 and compatible Intel processors
N - provides additional Pentium 4 processor tuning beyond W.
Only the -axW and -axP options are available for Intel EM64T.
Ed ecco altre informazioni prese dal link di cui sopra:
Full Support for Streaming SIMD Extensions 3 (IA-32 processors only): Obtain support for architectural features of Intel processors. The IA-32 features support the Streaming SIMD Extensions 3 that distinguish the Intel NetBurst microarchitecture introduced with the Pentium 4 processor. Maintain support for legacy performance features such as MMX technology. Streaming SIMD Extensions 3 go beyond the initial, performance-oriented support for multimedia or graphical components of applications and include improved performance for floating point and double-precision computational needs. The new instructions are supported in a number of ways including inline ASM, compiler intrinsics, class libraries, the vectorizer, and the Intel Performance Libraries.
Quindi come vedi il compilatore è capace di generare anche codice per le altre SIMD (quelle di riferimento per Intel sono ovviamente le ultime, le SSE3).
Automatic Vectorizer (IA-32 processors only): Automatically parallelize code to maximize underlying processor capabilities. Vectorizer examples demonstrate how to increase the speed of application execution. New features include support for advanced, dynamic data alignment strategies, including loop peeling to generate aligned loads and loop unrolling to match the prefetch of a full cache line.
Questa è una funzionalità molto avanzata che né MS né Apple mettono a disposizione. Prendendendo in prestito le tue parole: "proprio la stessa cosa", vero?
Auto-Parallelization: Improve application performance on multiprocessor systems using auto-parallelization for automatic threading of loops. This option detects parallel loops capable of being executed safely in parallel and automatically generates multi-threaded code. Automatic parallelization relieves the user from having to deal with the low-level details of iteration partitioning, data sharing, thread scheduling and synchronizations. It also provides the benefit of the performance available from multiprocessor systems and systems that support Hyper-Threading Technology.
Idem come sopra: "proprio la stessa cosa".

Come vedi, c'è una differenza sostanziale fra di noi: io ho una base di conoscenza acquisita, che utilizzo ogni qual volta si discute di qualche cosa; google e qualche ricerchina dedicata (sul sito della Intel in questo caso) li uso soltanto se è necessario per portare dei dettagli su quanto ho scritto, che ne dimostrino l'attendibilità. L'informazione corretta, insomma, "c'è già".

Tu, invece, la conoscenza te la costruisci a colpi di google, andando spasmodicamente a ricercare informazioni per cercare di supportare le idee che ti sei fatto chissà come su un certo argomento, o per cercarne alcune per smontare quel che dicono gli altri. Non hai un'informazione corretta in partenza, sulla quale incentrare una discussione.
Google non è un certo una base di informazioni "affidabile": non è che tutto ciò trovi scritto diventa automaticamente vero soltanto perché l'hai trovato su qualche sito.

Poi è preferibile costruirsi una base di conoscenza leggendo documentazione proveniente da fonte "affidabile", come possono essere i manuali della casa produttrice nel caso di un processore o di un compilatore, oppure dei testi scritti da luminari su un particolare argomento (es: Aho, Ullman per i compilatori, Patterson per le architetture dei processori, Foley, Perlin, Watt, ecc. per la grafica 2D / 3D, ecc. ecc.).
Ovviamente studiare delle cose di per sé non porta a niente: bisogna capire l'argomento di studio e incamerare le informazioni in maniera da poterle tirare fuori al momento opportuno, nel giusto contesto e con la giusta modalità.

Quando scrivo non lo faccio perché ho fantasticato su qualcosa e volevo dire la mia, ma ogni parola è "pesata", "calibrata", e utilizzata per esprimere in maniera corretta e in un contesto inequivocabile il mio preciso pensiero. Lo puoi notare, ad esempio, quando ho parlato di compilatori che generano codice "ottimizzato" per diverse architetture e che scelgono l'appropriato code path a runtime: non ho MAI parlato di MS o altro, ma sempre e soltanto di Intel. Ricordavo, insomma, che fosse Intel ad avere sviluppato questa "tecnologia" e non altri.
L'informazione C'ERA GIA' nella mia testa: mancava soltanto un dettaglio che la provasse.

Se vuoi sostenere una discussione devi averne le capacità, altrimenti per te sarebbe meglio darci un taglio. Poi se sei masochista e vuoi continuare, amen.

P.S. E aspetto ancora di essere smentito sul numero di istruzioni introdotte da Intel con MMX, SSE/2/3, visto che aprire il manuale Intel sull'architettura x86 (che è IL testo di riferimento) e applicare un'operazione banale quale il loro conteggio (più facile dei "conticini" che si facevano alla prima elementare) per te non è "autorevole"... :rolleyes: :mc:

x fek: per quanto riguarda la CPU sapevo che era in grado di ricompilare (per intero o dinamicamente) l'IL in codice ottimizzato per essa, ma non sapevo che potesse fare qualcosa di simile anche per GPU (e APU, eventualmente).
La mia idea era quella che il s.o. potesse scegliere, fra quelli disponibili, il code path adatto alla GPU (e dell'APU) presente nel sistema. Ad esempio, nell'eseguibile infilo codice e/o dati per GPU di classe DirectX 7, 8, 8.1, 9 / SM2, 9 / SM3, ecc., e il s.o. decide automaticamente quali segmenti di codice e/o dati caricare.

In questo modo non sarebbe necessario avere eseguibili diversi a seconda delle diverse combinazioni di hardware possibili (con notevole dispendio di spazio), ma soltanto n codici relativi ognuno a un ben preciso contesto / caratteristica.
In teoria si potrebbe anche avere codice x86 generico per il codice "meno critico" (come può essere quello della GUI, ad esempio) e che quindi non necessita di particolari ottimizzazioni, e diversi codici (P3, Athlon / 3DNow!, Athlon / SSE, Athlon64, P4 Northwood, P4 Prescott, ecc.) per le sole sezione critiche; idem per le GPU (porzioni di codice e dati / shader diversi) e le APU (codice e dati diversi a seconda del tipo di audio trovato nel sistema Aurial, EAX 1.0, EAX 2.0, ecc.).