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

IBM, Toshiba e Sony svelano alcuni particolari in merito alle future cpu Cell di cui si è già tanto parlato nei mesi scorsi

Click sul link per visualizzare la notizia.

Come già si temeva, sarà un inferno per i programmatori...
Nuove estensioni al C e al C++, nuovi tipi di dati, più la necessità di un multi-threading estremo per sfruttare al meglio questa bestiola.
Il porting da/verso altre piattaforme sarà un macello :(

Le potenzialità devono essere enormi, bisogna vedere se saranno sfruttabili...

Con tutta qst difficoltà poi finisce come per la PS2, dove solo i grandi Team hanno sfornato cose tecnicamente egregie staccandosi nettamente dalla media degli sviluppatori... basti pensare al recentissimo God of War, un gioiello raffinatissimo ma guarda caso sviluppato la Sony America... :)

A mio avviso dev'essere la tecnologia a piegarsi all'uomo, non l'uomo a dover impazzire per ottenere risultati interessanti, il 360 da qst punto di vista è ideato meglio :)

le potenzialità saranno enormi in un ambito specifico, nel general purpose ho dubbi sinceri che - come si dice in gergo tecnico - ne salti fuori :D

cmq è drammatico che si arrivi ormai a settembre a rilasciare qualche specifica quando la concorrenza da qui a 2/3 mesi metterà in commercio il suo prodotto... sinceramente mi aspettavo che per lo meno le specifiche del processore in sè fossero già a posto da un pezzo (tra l'altro forse lo erano, e forse si sono resi conto che l'unico core che si occupava del general purpose era un po' troppo sfigato - dico solo che era un'architettura in-order... tra l'altro non capisco perchè mettere 8 core che di fatto sono DSP e uno solo - ma sono 8 e 1 o 7 e 1? - orientato al general purpose quando avrebbero potuto equilibrare maggiormente le cose come di fatto accade nella xbox 360, la quale ha numeri di picco sui flops più bassi ma ha una flessibilità e una sfruttabilità che il cell si sogna - è da quando si è capito com'erano fatte le due architetture che era chiaro)...

alla fine non mi aspetto più di tanto dal cell... sarà eccezionale a fare poche cose, per le quali non verrà mai adeguatamente sfruttato (a parte nei cluster per calcolo scientifico, forse)...

per la precisione sono 8 ma ne verrano sfruttate solo 7 perchè hanno difficoltà a produrre la cpu con tutte 8. quindi ne verrà disattivata una anche se in quella particolare cpu funzionano tutte.

- Cell Broadband Engine Architecture (Version 1.0 / August 8, 2005) defines a processor structure directed toward distributed processing and multimedia applications

Ancora con questa stronzata del calcolo distribuito?
Ma scrivessero features serie anzichè un mare di sciocchezze ....

Personalmente credo che God of war sia un gioiello di programmazione. Come tanti altri, che non vedremo su pc.
Ora però rischiamo di vederne sempre meno.
Beh,tanto per cominciare addio porting diretto PS2/PC.
E questa in teoria è una cosa buona.
La natura delle cose spingerebbe verso conversioni più curate, con un carico di lavoro maggiore per i programmatori.
Ma scommettiamo che invece la linea sarà semplicemente quella di NON pubblicare per pc? Certo che quando hai speso gli stessi soldi (o più) solo per comprarti la scheda grafica, e qualcuno ti dice che il tuo pc "non ce la fa" a stare dietro a Cell & co., un pò le balle si agitano.
Non voglio fare il nostalgico, ma una cosa mi infastidisce molto.
Quando compri una macchina standard (come le console o perfino l'Amiga, che personalmente ho vissuto come tale, prima che mi accorgessi della sua scalabilità) prima o poi ti rendi conto della potenza che può sviluppare: la killer application arriva, presto o tardi. E regala una sensazione magnifica.
Perchè invece ho sempre e comunque la sensazione che il mio pc sia sottosfruttato, da Wing Commander (386) in poi?

PS per Boneschi: "enthertaninment" va rivisto :)

Il Cell è un'architettura stupenda che mi ricorda la stessa rivoluzione che l'Amiga portò nel settore home nel 1985.
Bollarla come "difficile da programmare" è assurdo! In 2 mesi il team di Unreal ha portato il suo motore sulla PS3 che farà parte del kit di sviluppo ufficiale, stessa cosa vale per l'Havok e per un motore super usato e collaudatissimo come quello NetImmerse di NDL.
Tutto sta nella mentalità e nelle capacità dei programamtori che ormai (soprattutto in Italia) sono troppo abituati ad accontentarsi di VisualBasic per fare qualcosa se non peggio.

Cmq per una vera veduta d'insieme dell'architettura Cell consiglio questo sito

http://www.blachford.info/computer/Cell/Cell0_v2.html

E' abbastanza indicativo di ciò che questo nuovo processore può offrire se non verrà sminuito da chi continua a smerciare per ignoranza o per interesse commenti inutili e lesivi.

>dico solo che era un'architettura in-order

considerando che il codice general purpose sulla xbox 360 sara molto scarso con 3 core e 6 thread possibili quali preformance ci possiamo aspettare da 1 core solo con singolo thread (che nel contempo deve controllare l'esecuzione del codice negli altri DSP).

la grande velocità dei DSP non puo aiutare nel codice che non si puo eseguire in parallelo.

inoltre quando è stato annunciato il CELL si parlava ufficialmente di 4.2Ghz e 8 DSP ora siamo a parlare si 3.2Ghz e 7 (forse ance 6) DSP a causa dell'elevato calore generato e dalle basse rese.
A me sembra una cpu rivoluzionaria che pero esce in un periodo dove non verra sfruttata a dovere perche i programmatori di tutto il mondo devono cominciare appena ora a imparare come sfruttare sistemi multi core e multi thread (sfruttarli bene). Tra 10 anni le cose saranno cambiate completamente ....a mio parere i prossimi sistemi PC e console tra un decennio avreanno decine di core e DSP ma avranno anche le basi per farne un buon uso.

Spero che la sony riesca a muoversi bene nell'ambito del marketing. Sarebbe uno spreco se questo gioillino non dovesse aver successo per errori di marketing.

piu leggo su cell e apple meno capisco l'esistenza di apple e mondo mac, contro ogni regola di mercato isolarsi per mantenere un monopolio in un settore di nicchia.
l'unica cosa buona che ha fatto apple è stato il music store.

Non si tratta di "difficile da programmare" o no.. si tratta di capire se effettivamente le sue potenzialità sono nell'architettura o nella super ottimizzazione del software...

Giustamente avere a disposizione un set di istruzioni "completo" semplifica di molto la vita del programmatore in quanto quest'ultimo non deve fare assurdi giri con il codice per, faccio un esempio, eseguire una moltiplicazione a 128Bit su un sistema a 32.

Se poi si parla di portabilità del codice mi pare che le specifiche ANSI C/C++ esistano da parecchi anni. Aggiungere istruzioni a queste specifiche singnifica uscire dagli standard e creare uno dei tantissimi dialetti del C/C++... la domanda è ne vale veramente la pena?

In fondo stiamo parlando di una console.. non certo di un super cluster.
E' totalmente inutile poi pubblicizzare un elevatissimo numero di core (8 mi pare... è esatto?) se poi 7 di questi altro non sono che processori dedicati alla decodifica dei flussi audio/video e quindi totalmente inutilizzabili da parte dei programmatori.

Insomma Cell a me pare un'integrazione di tutti i vari DSP che ci sono nelle console e similare più che una rivoluzione!

(Anche perchè allo stato attuale dei processori la vera rivoluzione la fa il software se scritto come si deve!! Molti dicono di saper programmare... pochi sanno veramente farlo)

Cioè FX ... ti pagano per scrivere queste panzanate?

_______
alla fine non mi aspetto più di tanto dal cell... sarà eccezionale a fare poche cose, per le quali non verrà mai adeguatamente sfruttato (a parte nei cluster per calcolo scientifico, forse)...
_______

Cioè secondo te, un processore con un core base che è un PPC G5 non è adatto a far girare un programmino Office?
Un processore con 7 Coprocessori programambili non potrà gestire egregiamente anche grossi DB n un confronto diretto con qualunque processore della classe X86?
Guarda che oggi la vera sida tra processori si gioca in campo Multimediale e di calcolo vettoriale, l'unico in cui si chiede TANTA, TANTA potenza di calcolo.
Per rimanere nello stesso ambito in cui il Cell vuole emergere, Un P4 EE o un Athlon 64 FX non sono progettati e spinti attualmente per Word o Access, ma per macinare calcoli in virgola mobile e vettoriali, gli unici che attualmente servono DAVVERO in ambito home perchè, se si escludono progs Multimediali e Giochi, basta anche un semplice Celeron 500 in casa o in ufficio.
Questa fantasiosa idea che il Cell serve solo a giocarei è simile all'affermare che un P4 o un Athlon64 serve solo a giocare e continua a farmi ricordare di quello che si diceva dell'Amiga e del suo OS "Serve solo a giocare" ... poi si è visto sia dal punto di vista software che hardware.
L'amiga OS era un OS con multitask preempitive nel 1985 (allora giudicata cosa "inutile per ambiti home"). L'Amiga 3000 aveva una architettura IDENTICA a quella dei PC attuali con chipset, bus dma, bus esterni accessibili direttamente dal chipset etc ... allora giudicati inutili per sistemi home.
Poi si è visto come è andata e dobbiamo rigraziare solo AMD se grazie alla competizione con Intel il mercato informatico si è mosso in questi anni.

Boh a me pare che per il general purpose 3,2 GHz siano molto al di la' di quanto
serve (con un pentium 700 gia' si faceva tutto, vedi la prima Xbox.... per gestirmi
la rubrica degli indirizzi o i messaggi di posta va piu' che bene).

Bisogna vedere come si comportera' negli ambiti per tradizione "affamati di potenza"
come il multimedia e la grafica (dove si sa gia' che sara' una bomba,e' progettato per
l'encoding di h264 che su PC e' lentooooo) e soprattutto
calcolo scientifico/matematico (rendering 3d in primis) dove invece non si hanno
certezze sulla "convenienza" delle SPU. Anche sui giochi ovviamente!

Non conosco altri ambiti "affamati di potenza", ma se vi vengono a mente
aggiungete/correggetemi pure.

Mah.. già annunciare un 4.2 e poi tirare fuori un 3.2 con un core in meno la vedò già una pubblicità negativa... arrivare pure in ritardo sualla xbox lo vedo un ulteriore pubblicità negativa... non sono partiti molto bene stavolta :p

P.S.: nessuno ha chiamato "inferno per i programmatori" le estenzioni MMX,
MMX 2, SSE, SSE 2, SSE 3....... perche' in questo caso dovrebbe essere diverso?

>Boh a me pare che per il general purpose 3,2 GHz siano molto al di la' di quanto

3,2ghz sembrano tanti ma la cpu non è una OOO come l'intel o AMD quindi alla fine nel general purpose non vanno piu veloci di una cpu x86 della meta di velocita.

Anche http://www.anandtech.com/ ha detto che parlando con gli sviluppatori si stima che 1 core a 3,2ghz vado solo il doppio della cpu dell'xbox 1 (nel general purpose ovviamente).
Quello che importa e che nel calcolo vettoriale invece le potenze siano di un ordine di grandezza superiose sul nuovo core IBM

Ancora non si hanno però dettagli specifici sulla PPE (il core PowerPC). Sì certo è in-order e tutto il resto, ma poi basta.

Carmak sostiene il core in-order abbia prestazioni pari al 50% di un x86 moderno e quindi è piuttosto deluso. Ma tale valore non è poi così scarso, secondo me. Meglio sicuramente del G4 del MacMini, e anche di un G5 di fascia medio/bassa... Processori non proprio intilizzabili nel "general-pourpose".
http://techreport.com/etc/2005q3/carmack-quakecon/index.x?pg=1

E' interessante notare che ci sono state 2 versioni di Cell in tempi molto brevi, la seconda con un core PPC significativamente più grande, probabilmente proprio per contrastare le perplessità sulle prestazioni del core PPC e (forse) per convicere (senza successo) Apple ad adottarlo:
http://www.realworldtech.com/page.cfm?ArticleID=RWT072405191325

A quanto pare, inoltre, il famigerato core PPC del Cell è uguale a quello utilizzato sullo Xenon di Xbox. Ma sullo Xenon ce ne sono 3, mentre il Cell oltre al core PPC ha 7-8 core vettoriali. Quindi meglio 3 core uguali o 8 core asimmetrici per una consolle? Vedremo...

... A che servono?
Inosmma, non mi pare certo il caso: se non resvono già ora che di DSP è pieno il mondo, a che serviranno domani? Perchè ce ne sono 8 o 9?
A me sembra più una bella notizia: talmente potente che il c/c++ necessita di istruzioni .. ed eccoti un'altra bufala tipo new economy!

Per svilupparla in pieno mi aspetto semmai delle LIBRERIE che la sfruttino, scritte da team CAPACI e informati (vedi SONY). NOn certo da un poveraccio come me o altri "piccoli" sviluppatori.
Mah, speriamo che oltre al marketing ci sia davvero qualcosa di grosso in pentola!

.. Chissà perchè 'sto cell mi ricorda tanto Amiga. E la povera fine che ha fatto!

>A quanto pare, inoltre, il famigerato core PPC del Cell è uguale a quello utilizzato sullo Xenon di Xbox.

inoltre i PPC della xbox possono utilizzare 2 thread per core quindi mentre 1 fa calcoli sugli interi il secondo puo utilizzare l'unita in virgola modile cosi da sfruttare meglio l'hardware.

@riuzasan
Il cell nasce per giocare con una console, poi che con questo processore ci si possa fare di tutto a me non interessa, perchè non credo che troverò il Cell vicino ad un processore Amd o Intel dal mio negoziante.

Sai che bello fare un Porting se aumentano le istruzioni al C/C++, poveri noi programmatori. Fortuna che lavoro con VB.Net

riuzasan: sono panzanate o meno a seconda se sai di cosa si parla. il fatto che tu mi venga a dire che le SPU possano gestire grossi database non lascia spazio a dubbi: hai pochi e confusi concetti per la testa, che hai memorizzato ma non capito.

di fatto, come dice coschizza, sul general purpose (e un database non è calcolo vettoriale, mi spiace) il cell sarà piuttosto scarso, tanto che viene paragonato ad un pentium 3 a 700 mhz (il doppio a livello di performance è comunque non paragonabile rispetto agli x86 attuali, ma ci mancherebbe altro, gli x86 sono fatti apposta per avere performance sul general purpose)... se tu preferisci invece credere che un progetto nato dal nulla con investimenti molto modesti rispetto a quelli che si impiegano nella ricerca e sviluppo sugli x86 arrivi e dia la paglia a intel e amd, beh, fai pure, a questo punto puoi anche credere che venga montato su una 500 al posto del motore e vada a vincere il campionato di formula uno.

ripeto, non hai la più vaga idea. basta vedere quando fai i paragoni con l'amiga o mi tiri in ballo a sproposito l'havok...

Soul_to_Soul: si continuerà a sviluppare per pc anche perchè con la famosa PPU di fatto i PC continueranno a mantenere il predominio per quanto concerne la potenza pura (che poi sicuramente verrà sfruttata peggio che sulle console - tuttavia essendocene in sovrabbondanza, chissene), in quanto colmeranno il gap a livello di calcolo vettoriale. è il solito discorso che si fa ogni volta che esce una console, alla fine :D

coschizza: per quanto riguarda il discorso del single o multi-threaded, beh, quello è il grosso problema dei tempi moderni :D la differenza rispetto agli x86, che esistono in versione a core fisico singolo, a core fisico singolo ma logico doppio, a core doppio e logico singolo, a core doppio e logico doppio, è che la soluzione è una e quella è, quindi i programmatori possono adottare fin da subito un approccio diverso, come d'altro canto sarà per i programmatori pc nei prossimi anni... di porzioni di codice che si possono spalmare su più thread ce ne sono, dai, basti pensare all'intelligenza artificiale, compito tipicamente general purpose (e anche impegnativo): ogni "elemento pensante" può essere un thread a sè... ma poi di ambiti in cui avendo la possibilità si riesce ad ottimizzare ne è pieno, il problema ripeto imho è avere la piattaforma di riferimento che ti garantisce SEMPRE la possibilità, e una console lo fa.

freeeak: il motivo per cui non finirà su un computer general purpose è che non è un processore orientato al general purpose ma è un DSP, e quel che serve in un computer general purpose è... il general purpose :D il resto viene dopo, infatti altivec o SSE3 sono estensioni del processore, non il contrario come di fatto accade nel cell

devilsadvocate: il caso è diverso perchè SSE3 è una cosa in più, fai conto di avere un pentium 4 che va ad un decimo con SSE3 che va il doppio (nota: non ottieni il cell, eh, è solo per dire): cosa ci fai per l'uso tipico?

>A quanto pare, inoltre, il famigerato core PPC del Cell è uguale a quello utilizzato sullo Xenon di Xbox.

inoltre i PPC della xbox possono utilizzare 2 thread per core quindi mentre 1 fa calcoli sugli interi il secondo puo utilizzare l'unita in virgola modile cosi da sfruttare meglio l'hardware.

Si quello del Cell pure. Sono uguali...

La cosa "strana" della PPE del Cell è che abbia un'estesa componente vettoriale, cioè il "vecchio" Altivec in un implementazione (a quanto pare) potenziata. Apparentemente inutile, visto i 7-8 core vettoriali.

Pensavo l'avessero fatto per Apple (l'unica che usava Altivec) e forse era anche così, ma visto che il core PPC l'hanno poi "riciclato" per l'Xbox360, quindi l'hanno fatto anche per lo Xenon che altrimenti non avrebbe avuto capacità di calcolo vettoriale...

P.S.: nessuno ha chiamato "inferno per i programmatori" le estenzioni MMX,
MMX 2, SSE, SSE 2, SSE 3....... perche' in questo caso dovrebbe essere diverso?

mmx 2? Sei sicuro di parlare seriamente? Non esistono le MMX 2. :D (ho un manuale originale intel e parla di MMX, SSE, SSE2, SSE3 ma delle MMX 2 mai viste. xD)

riuzasan: sono panzanate o meno a seconda se sai di cosa si parla. il fatto che tu mi venga a dire che le SPU possano gestire grossi database non lascia spazio a dubbi: hai pochi e confusi concetti per la testa, che hai memorizzato ma non capito.

Perchè no?
E' vero che le SPE sono prettamente vettoriali, ma sono anche processori a tutti gli effetti con unità intera a 64bit e FP a doppia precisione (volendo) e possono essere utilizzate in modalità scalare. E sono TANTE.
I principali database sono multithreading, quindi potrebbero sfruttarle tranquillamente come 'normali' processori. Beh, quasi. Hanno memoria locale e tutto il resto, gli algoritmi andranno sicuramente riscritti e ottimizzati per l'hardware, ma è pensabile che possa essere fatto, e se viene fatto le prestazioni saranno sicuramente notevoli! 8 core da 3.2 (o 4+ più per server che non badano troppo ai W) Ghz sono sono uno scherzo!

Scusa mi spieghi perche dicevi che le argomentazioni sul calcolo distribuito erano idiozie?

>Si quello del Cell pure. Sono uguali...

le CPU sono uguali tranne che per il multithread hardware e la cache L2 ,il cell ha 1 thread e 512Kb di L2, L' Xbox 360 ne ha 2 e 1024Kb di cache.

va ricordato che la gestione della L2 delle cpu IBM e molto diversa da quella delle attuali x86, per capirsi vi faccio un esempio.
Se il primo thread utilizza le unita sugli interi e ha bisogno di una sua cache allora blocca 256Kb della L2 solo per s[, il secondo thread utilizza la FPU e utilizza 0Kb di L2 perche richiede che i dati passino dalla memoria direttamente ai registri scavalcando anche la L1. in molti casi poter decidere come partizionare la L2 e scavalcare persino la L1 completamente puo incrementare di molto l'efficienza perche i flussi di dati STREAM molto utilizzati nei calcoli di contenuti multimediali non hanno bisogno di cache e quindi non fanno altro che riempire l'intera L2 di dati che non saranno mai utilizzati e la svuota di informazioni che magari sono utilizzate in spesso.

Sulle cpu attiali x86 i programmatori non possono controllare im maniera cosi precisa la gestione della cache, si devono accontentare degli algoritmi inseriti nell'hardware sperando nella loro efficienza.

>Si quello del Cell pure. Sono uguali...

le CPU sono uguali tranne che per il multithread hardware e la cache L2 ,il cell ha 1 thread e 512Kb di L2, L' Xbox 360 ne ha 2 e 1024Kb di cache.

Anche la PPE del Cell è dual threaded. Leggi le specifiche. Come detto i core PPC sono uguali. Ma tutto il resto (cache, tipo di memorie, bus, ecc) no.

>quindi potrebbero sfruttarle (le SPE) tranquillamente come 'normali' processori.

purtroppo non è possibile utilizzare le SPE come normali CPU per 2 motivi documentati dalla stessa IBM.
1 gli SPE sono ottimizzate per calcopi in virgola mobile e non possono operare sugli interi se non con un calo notevole di performance.
2 purtroppo non gestiscono le previsioni dei salti quindi non possono essere utilizzati come unita general purpose se non con un calo TOTALE delle performance perche deve svuotare e reinizializzare a ogni salto l'intera pipeline. Immaginalevi un P4 senza previsione di salti con una pipeline a 31 stadi, prativamente non si muove.
3 se era possibile farlo allora non sarebbero state progettate perche bastava inserire altre cpu standard come la xbox360.

Perchè no?

ti ha risposto coschizza

>quindi potrebbero sfruttarle (le SPE) tranquillamente come 'normali' processori.

purtroppo non è possibile utilizzare le SPE come normali CPU per 2 motivi documentati dalla stessa IBM.
1 gli SPE sono ottimizzate per calcopi in virgola mobile e non possono operare sugli interi se non con un calo notevole di performance.

Questo dove l'hai letto?

2 purtroppo non gestiscono le previsioni dei salti quindi non possono essere utilizzati come unita general purpose se non con un calo TOTALE delle performance perche deve svuotare e reinizializzare a ogni salto l'intera pipeline. Immaginalevi un P4 senza previsione di salti con una pipeline a 31 stadi, prativamente non si muove.

A parte il fatto che, se non ricordo male, anche le SPE hanno uno stadio di 'branch prediction' benchè semplificato. Poi è proprio l'architettura particolare con memoria locale (e con numero di pipeline ridotto) che limita le penalizzazioni in caso di branch mis-prediction. Se un P4 sbaglia un salto deve svuotare la pipeline e andare a prendere dati nella RAM che ha latenze estremamente alte, prima di ricominciare a macinare numeri. Il Cell può accedere molto più velocemente alla sua memoria locale.

Questo è almeno il razionale dell'architettura particolare del Cell, come illustrato per esempio qui: http://www-128.ibm.com/developerworks/power/library/pa-cbea.html

Certo, poi bisogna vedere se davvero le cose funzionano davvero meglio con questo nuovo approccio oppure no, e in quali casi... ma è un po' presto per dirlo.

L'unica cosa certa è che per sfruttare al meglio il Cell bisognerà programmarlo con un livello di astrazione molto più basso rispetto al trend attuale. Cioè pensando all'hardware che c'è sotto e a come è implementato. Un passo indietro sicuramente...

Fx le tue panzanate continuano, sei pregato di informarti meglio se non vuoi fare la figura dell'ignorante falso saccente.

________
il motivo per cui non finirà su un computer general purpose è che non è un processore orientato al general purpose ma è un DSP
________
Questa è fantastica, dovremmo girarla a chi ha visto un INTERO IBM Blade server basato su 2 "DSP" CELL con tanto di Linux in running ... o a chi ha visto una MB di Toshiba con un solo CELL on Board come main "DSP" (sto per rotolare dal ridere) runanre vari demo tra i quali il famoso con 42 stream mpeg2 in contemporanea.
Fx la tua giunzione delle parole DSP e Cell chiarifica bene cosa sai tu del Cell e del concetto di CPU in generale.
Sarebeb meglio che almeno sul Cell leggessi un pò questa guida, scritta da qualcuno che di processori ne capisce e non da chi ha visto in tutta la sua vita sui desktop solo X86
http://www.blachford.info/computer/Cell/Cell0_v2.html

@riuzasan
Il cell nasce per giocare con una console, poi che con questo processore ci si possa fare di tutto a me non interessa, perchè non credo che troverò il Cell vicino ad un processore Amd o Intel dal mio negoziante.

Sai che bello fare un Porting se aumentano le istruzioni al C/C++, poveri noi programmatori. Fortuna che lavoro con VB.Net

Sei un programmatore e ti vanti di lavorare su .net con vb? Complimenti.

L'estensione di C++ è fondamentale. Vuol dire che sony mette a disposizione delle librerie, senza delle quali dovresti andare via assembly.

Io più che fare accuse di qua e di la starei attento a quello che scrivo.
Linux gira su un'infinità di architettura diverse (persino sui registratori di cassa) anche perchè quando una CPU è in grado di fare le 4 operazioni elementari (che in realtà sono 2 somma e sottrazzione (e shift bitwise per le moltiplicazioni e le divisioni)) è in grado di eseguire tutto il software basta che il compilatore sappia fare il suo dovere.

Poi sinceramente i 42 stream in MPEG 2 mi sembrano più una falsa dimostrazione di forza... all'epoca dei Pentium 2 si aveva bisogno di un 300Mhz per decodificare in "real time" un flusso proveniente da DVD.
Da allora ad oggni ne è passata di acqua sotto i ponti ed oltre all'incremento di frequenza c'è stato un netto miglioramento delle architetture delle CPU (sia RISC che CISC). Quindi, come qualcuno affermava nei commenti alla news sui 42 flussi Mpeg2, non è affatto detto che un 3 GHz x86 riproduca al massimo 10 flussi MPEG2 (Magari il commento non era prorpio questo ma la linea era: se la base è 1 ed incremente di 10 volte la frequenza della CPU ottengo al massimo prestazioni 10 volte superiori).
Inoltre come è facilmente visibile consultando un qualunque libro che parli di archietettura dei microprocessori NON è affatto detto che l'aumento di frequenza porti ad incrementi prestazionali.

Prendere in considerazoine i test SPEC e i dati MIPS (Milion Instructions per second) su architetture diverse è come mettere a confronto un deltaplano con un 737.

Tali test sono troppo influenzabili dall'architettura interna della CPU e quindi validi come valore di paragone solo su test condotti sulla medesima architettura. (Leggasi che una CPU a 34 MIPS (puro valore inventato) può essere tranquillamente più veloce di una CPU con 50 MIPS).

(Per chi non mi crede consiglio la consultazione del libro Computer Organization & Desgin di Patterson Hennessy)

>Estensioni c/c++ ???!!!
Mai sentito niente del genere... forse si può parlare di librerie.

>Inferno per i programmatori???!!
Altra cazzata... I programmatori avranno degli strumenti così potenti che non avranno bisogno di scerverlarsi più di tanto (pensa a tutto il compilatore e i vari strumenti di profiling).
Per non parlare che il 90% dei programmatori lavoreranno con framework di engine già esistenti (es. Unreal Engine, Havok, Novodex quindi Ageia con Phisix ecc.)

>Processore che non va bene per il general purpouse
3.2 GHZ, 64 Bit, banda memoria Cpu di oltre 20 Gbit/s... be allora stiamo scrivendo proprio p*******e.

Io più che fare accuse di qua e di la starei attento a quello che scrivo.
Linux gira su un'infinità di architettura diverse (persino sui registratori di cassa) anche perchè quando una CPU è in grado di fare le 4 operazioni elementari (che in realtà sono 2 somma e sottrazzione (e shift bitwise per le moltiplicazioni e le divisioni)) è in grado di eseguire tutto il software basta che il compilatore sappia fare il suo dovere.

Poi sinceramente i 42 stream in MPEG 2 mi sembrano più una falsa dimostrazione di forza... all'epoca dei Pentium 2 si aveva bisogno di un 300Mhz per decodificare in "real time" un flusso proveniente da DVD.


Ti faccio un elenco delle architetture dove Linux per ovvie ragioni non girerà mai per ovvie ragione (leggi mancanza della mmu, anche se di dice che al 2.6 non serva)

-dal 286 in giù per l'x86
-dal 680ec20 in giù per 68k

e poi penso che un p2/300, senza l'ausilio di una scheda grafica accelerata, non è in grado di decodificare un flusso mpeg2.
E cmq l'esempio dei 42 stream era per sottolineare l'enorme banda passante dell'architettura cell e non la potenza di calcolo.

Ti faccio un elenco delle architetture dove Linux per ovvie ragioni non girerà mai per ovvie ragione (leggi mancanza della mmu, anche se di dice che al 2.6 non serva)

-dal 286 in giù per l'x86
-dal 680ec20 in giù per 68k

e poi penso che un p2/300, senza l'ausilio di una scheda grafica accelerata, non è in grado di decodificare un flusso mpeg2.
E cmq l'esempio dei 42 stream era per sottolineare l'enorme banda passante dell'architettura cell e non la potenza di calcolo.

anche le capacità di multitask.

siliconbrain: io col mio P2 @ 266 riuscivo a vedere quasi fluido un DVD che poi e quindi un flusso MPEG2 con un normale player software...

>Sei un programmatore e ti vanti di lavorare su .net con vb? Complimenti.

il visual basic è utilizzato dal 60% di tutti i programmatori sotto MS quindi per me Spyto è un programmatore

da quando uno e programmatore solo se usa il tuo linguaggio preferito?

io per esempio per anni ho sviluppato in ASM e cosa sarei ? pazzo!

Guarda che non parlano del calcolo distribuito tipo SETI.
Ma di super-computer che sono in realtà composti da centinaia di computer separati.

Sei un programmatore e ti vanti di lavorare su .net con vb? Complimenti.

L'estensione di C++ è fondamentale. Vuol dire che sony mette a disposizione delle librerie, senza delle quali dovresti andare via assembly.
Non mi sto vantando so programmare in C, Java (i miei esami del Poli) ma lavoro con VB.Net.
Sfortunatamente a lavoro mi vengono dati su 10 progetti, 8 di porting, quindi so che rottura è mettersi a risolvere problemi per far funzionare il tutto.

>Sei un programmatore e ti vanti di lavorare su .net con vb? Complimenti.

il visual basic è utilizzato dal 60% di tutti i programmatori sotto MS quindi per me Spyto è un programmatore

da quando uno e programmatore solo se usa il tuo linguaggio preferito?

io per esempio per anni ho sviluppato in ASM e cosa sarei ? pazzo!

Solo che per me è inconcepibile amare la programmazione e dire "fortuna che lavoro con vb". Per me sarebbe una disgrazia e non perchè ho un linguaggio preferito. Perchè ne preferisco 10 al vb.

Non mi sto vantando so programmare in C, Java (i miei esami del Poli) ma lavoro con VB.Net.
Sfortunatamente a lavoro mi vengono dati su 10 progetti, 8 di porting, quindi so che rottura è mettersi a risolvere problemi per far funzionare il tutto.

quello è vero è una rottura.

So che nn è un vanto il tuo, scusa mi sono espresso male.

criceto: come dici tu stesso alla fine, non bastano le feature, bisogna vedere in pratica... il pentium 1 aveva il branch prediction e tutta una serie di feature simpatiche che però oggi sono un po' superate

riuzasan: ti ha risposto narmo, ti inviterei nuovamente a smussare il tono, sai qualcuno potrebbe presumere che soppersici con un tono aggressivo alla mancanza di argomentazioni

siliconbrain: 3.2 ghz, 64 bit e 20 gbit/s di banda (non vado a controllare, ma se è vero sono 2.5 GB/s, accipicchia, l'opteron ne ha 10 volte tanto spalmata su 3 link HT + la banda sulla ram) non vogliono dire proprio nulla in special modo se poi ci metti dietro un'architettura in-order... non a caso la stima che è uscita prende come riferimento un pentium 3 a 700 mhz, come già detto. metti pure che sia equivalente a un pentium 3 a 1400 mhz, sul general purpose, non mi sembra che sia particolarmente adatto a questo tipo di scopo. più che sufficiente per quel che deve fare, eh, però non paragoniamolo con chi fa quello di mestiere.

altra cosa: le tue ovvie ragioni non sono poi così ovvie, dato che linux gira anche su una serie di microcontrollori, informati meglio...

Altra cazzata... I programmatori avranno degli strumenti così potenti che non avranno bisogno di scerverlarsi più di tanto (pensa a tutto il compilatore e i vari strumenti di profiling).

eh già, infatti tutti i software esistenti per pc e mac sono ottimizzati SSE e altivec... su, dai...

Per non parlare che il 90% dei programmatori lavoreranno con framework di engine già esistenti (es. Unreal Engine, Havok, Novodex quindi Ageia con Phisix ecc.)

infatti l'ambito in cui ci sarà un grosso beneficio è proprio la simulazione fisica, ma di questo se n'è abbondantemente parlato... il problema è il resto: per ad esempio degli algoritmi di intelligenza artificiale non te ne fai molto di tutte le mille mila SPE del cell

>Inferno per i programmatori???!!
Altra cazzata... I programmatori avranno degli strumenti così potenti che non avranno bisogno di scerverlarsi più di tanto (pensa a tutto il compilatore e i vari strumenti di profiling).
Per non parlare che il 90% dei programmatori lavoreranno con framework di engine già esistenti (es. Unreal Engine, Havok, Novodex quindi Ageia con Phisix ecc.)

>Processore che non va bene per il general purpouse
3.2 GHZ, 64 Bit, banda memoria Cpu di oltre 20 Gbit/s... be allora stiamo scrivendo proprio p*******e.
per il punto primo parla con fek. ai tempi diceva che mediamente è più facile programmare la xbox 360 che la ps3. Se da allora è cambiato qualcosa non ne ho idea.
Per il secondo punto mi sa ke la p*******a la stai scrivendo tu......
da quando in qua è con la frequenza pura che si misurano le prestazioni??? è meglio un P4 a 4 ghz o un A64 4000+???
Senza aggiungere ke qui stiamo parlando di un arkitettura IN-ORDER chè è inerentemente meno efficiente dell'Out Of Order execution dinamica dei moderni processori x86....
Non per niente *si dice* ke nel general purpose il cell vada solo il doppio del processore della xbox (+ o - a metà strada tra un celeron e un P3 a 700 mhz)....

Senza aggiungere ke qui stiamo parlando di un arkitettura IN-ORDER chè è inerentemente meno efficiente dell'Out Of Order execution dinamica dei moderni processori x86....

è meno efficiente semplicemente perchè è uno stadio evolutivo più basso, erano così anche gli x86...


...'anta anni fa però :D

Fx le tue panzanate continuano, sei pregato di informarti meglio se non vuoi fare la figura dell'ignorante falso saccente.

________
il motivo per cui non finirà su un computer general purpose è che non è un processore orientato al general purpose ma è un DSP
________
Questa è fantastica, dovremmo girarla a chi ha visto un INTERO IBM Blade server basato su 2 "DSP" CELL con tanto di Linux in running ... o a chi ha visto una MB di Toshiba con un solo CELL on Board come main "DSP" (sto per rotolare dal ridere) runanre vari demo tra i quali il famoso con 42 stream mpeg2 in contemporanea.
Fx la tua giunzione delle parole DSP e Cell chiarifica bene cosa sai tu del Cell e del concetto di CPU in generale.
Sarebeb meglio che almeno sul Cell leggessi un pò questa guida, scritta da qualcuno che di processori ne capisce e non da chi ha visto in tutta la sua vita sui desktop solo X86
http://www.blachford.info/computer/Cell/Cell0_v2.html


Occhio a dare dell'ignorante falso alla gente, che rischi la figuraccia:

http://arstechnica.com/news.ars/post/20050207-4594.html

The Cell processor consists of a general-purpose POWERPC processor core connected to eight special-purpose DSP cores. These DSP cores, which IBM calls "synergistic processing elements" (SPE), but I'm going to call "SIMD processing elements" (SPE) because "synergy" is a dumb word, are really the heart of the entire Cell concept. IBM introduced the basic architecture of the SPE today, and they're going to introduce the overall architecture of the complete Cell system in a session tomorrow morning.

Il Cell e' di fatto un DSP molto intelligente con scarse capacita' general purpose. E' stato progettato proprio per essere questo e gli riesce molto bene.

Per siliconbrain

Mi spiace contraddirti ma esistono versioni di sistemi Unix-Like che girano sia su 286 e minori.

Per c'è o il progetto di Tanebanum (mi pare si scriva così) chiamato Minix (potrei avre scritto una troiata... in questo momento non mi viene in mente il nome) oppur ei lprogetto Linux per 16 Bit (basta una rapida ricerca su google)

Su motorola seria 68xx mi pare sia disponibile un progetto anche se non ricordo il nome.....adesso mi metto a sfogliare i preferiti e se lo trovo lo posto!

Fx le tue panzanate continuano, sei pregato di informarti meglio se non vuoi fare la figura dell'ignorante falso saccente.

________
il motivo per cui non finirà su un computer general purpose è che non è un processore orientato al general purpose ma è un DSP
________
Questa è fantastica, dovremmo girarla a chi ha visto un INTERO IBM Blade server basato su 2 "DSP" CELL con tanto di Linux in running ... o a chi ha visto una MB di Toshiba con un solo CELL on Board come main "DSP" (sto per rotolare dal ridere) runanre vari demo tra i quali il famoso con 42 stream mpeg2 in contemporanea.
Fx la tua giunzione delle parole DSP e Cell chiarifica bene cosa sai tu del Cell e del concetto di CPU in generale.
Sarebeb meglio che almeno sul Cell leggessi un pò questa guida, scritta da qualcuno che di processori ne capisce e non da chi ha visto in tutta la sua vita sui desktop solo X86
http://www.blachford.info/computer/Cell/Cell0_v2.html


a me sembra che tu ne sappia veramente poco..in qualsiasi corso di microelettronica di base viene insegnato cos'è un DSP e come è strutturato e ,per quanto negli ultimi 10 anni i DSP si siano avvicinati in quanto a generalizzazione ai processori general purpose,rimangono cmq delle unità dedicate principalmente al calcolo vettoriale.
E,guarda caso il calcolo vettoriale viene utilizzato in ambito scientifico e grafico per velocizzare i calcolo tra matrici o realizzare pixel machines dove ogni DSP effettua un calcolo sua una determinata regione di spazio.

Il motivo per cui i DSP quindi vengono associati ad un core general purpose è proprio per la loro specificità che non può essere gestita da un altro DSP che non riuscirebbe a gestire le molteplici modalità d'indirizzamento o le istruzioni MAC tra i vari core con l'efficienza di un general purpose.

Ha quindi ragione Fx quando ti dice che il cell non è un GP e che è meno efficiente in un computer con applicazioni office dove i salti sono ogni 5/7 istruzioni e possono essere gestiti con grande efficienza dalle unità di branch prediction di un GP mentre con un DSP causerebbero una grandissima perdità di cicli dimezzando l'attività della macchina.

Stai quindi sbagliando alla grande e te lo faccio notare postando una piccola introduzione di uno dei libri di microelettronica che ho a casa.

Nel capitolo "Processori special purpose" (e già questo dice tutto) trovi:
10.2.3 CONFRONTO TRA PROCESSORI GENERAL PURPOSE E DSP
Oggi, molte condizioni tecnologiche che hanno favorito lo sviluppo dei processori DSP, stanno
venendo meno: i processori general purpose, grazie allo sviluppo tecnologico, possono essere
competitivi, come prestazioni, con i DSP, anche su applicazioni di elaborazione numerica, con
minori costi; un altro motivo è lo sviluppo delle logiche programmabili: oggi, con talune FPGA, è
possibile realizzare un filtro numerico che, in applicazioni molto specifiche, raggiunge prestazioni
superiori a quelle ottenute con DSP, perché l'architettura è fortemente dedicata (e parallelizzata).
Le caratteristiche a favore dei DSP si basano sul fatto che, per alcune applicazioni, hanno,
comunque, prestazioni superiori rispetto ai general purpose e sul fatto che, nel corso degli anni, le
case che producono DSP, hanno prodotto una tale quantità di strumenti SW per applicazioni
numeriche, da rendere vantaggioso utilizzare un DSP piuttosto che un MIPS o un Pentium, nel
campo delle applicazioni embedded. C'è un compilatore con librerie per l'elaborazione numerica
dotate di una notevole quantità di documentazione, reperibile anche in internet, mentre nel caso del
Pentium questo non è possibile (l'elaborazione numerica ha un mercato più grande di quello dei
personal computer).
Per le applicazioni, si va dalla modulazione/demodulazione digitale, alle applicazioni audio, alle
applicazioni di elaborazione d'immagine e, soprattutto, ad applicazioni di grafica in tempo reale
come, per esempio, gli algoritmi di rendering.


Ti avverto...stai facendo una figuraccia incredibile dando dell'ignorante a gente che ne sa più di te come Fx..

Sei un programmatore e ti vanti di lavorare su .net con vb? Complimenti.


Per esigenze di lavoro, mio padre (laureato in informatica quando la maggior parte di chi scrive qui doveva ancora nascere) continua ancora a programmare in COBOL, come lo definisci? Non è anche lui un programmatore?

:D quello è vero è una rottura.
So che nn è un vanto il tuo, scusa mi sono espresso male.
Nessun problema :D
Ti faccio una confidenza io speravo di poter lavorare il C o Java, ma nelle mie zone richiedevano vb.net e quindi mi sono immerso in questo mare tortuoso.
Pensa che l'ultimo porting è stato una parte di codice in C e un'altra in Java tutte da portare su vb.net, mi volevo ammazzare :rolleyes:

Per questo non invidio i programmatori che portano giochi dalla Ps2 al nostro amato PC.
Poi ci sono anche da mettere in mezzo gli ostruzionisti, vedi come è stato programmato Halo per PC o giochi come GTA che sono arrivati in ritardo agevolando le console.

Originariamente inviato da siliconbrain
>Inferno per i programmatori???!!
Altra cazzata... I programmatori avranno degli strumenti così potenti che non avranno bisogno di scerverlarsi più di tanto (pensa a tutto il compilatore e i vari strumenti di profiling).
Per non parlare che il 90% dei programmatori lavoreranno con framework di engine già esistenti (es. Unreal Engine, Havok, Novodex quindi Ageia con Phisix ecc.)

Seeeeee... magari :)

Benissimo vengano le estensioni al C++ per programmare le SPE. Ottime le librerire. Ma far andare veloce questo chip sara' un incubo, la maggior parte degli argomenti vanno ripensati per il suo modello di programmazione a stream (che non e' banale).

Ha ragione Carmack su tutta la linea sul Cell. Dal punto di vista delle prestazioni, sarebbe stato forse meglio darci una sola CPU out-of-order molto piu' semplice da programmare, ma forse sarebbe costato troppo a loro.


>Processore che non va bene per il general purpouse
3.2 GHZ, 64 Bit, banda memoria Cpu di oltre 20 Gbit/s... be allora stiamo scrivendo proprio p*******e.

Non proprio :)

è meno efficiente semplicemente perchè è uno stadio evolutivo più basso, erano così anche gli x86...


...'anta anni fa però :D


no ma lo sarà sempre..non si può pretendere una pipeline sempre piena e dei salti efficienti..una delle due cose va scelta..e se vuoi la prima ti accatti ujn DSP,se vuoi la seconda vai di processore classico..insomma lo sai anche tu che funziona cosi..

poi è probabile che con i circuiti asincroni si troverà lo stato dell'arte per entrambe le funzioni ma col clock è per forza cosi..

Per esigenze di lavoro, mio padre (laureato in informatica quando la maggior parte di chi scrive qui doveva ancora nascere) continua ancora a programmare in COBOL, come lo definisci? Non è anche lui un programmatore?

Scusa ma mica ho detto che uno che programma in vb o cobol o altro nn è un programmatore...

Ma se tuo padre conosce il c++ (o C#, o java), prova a chiedergli in cosa preferirebbe programmare.

Per siliconbrain

Mi spiace contraddirti ma esistono versioni di sistemi Unix-Like che girano sia su 286 e minori.

Per c'è o il progetto di Tanebanum (mi pare si scriva così) chiamato Minix (potrei avre scritto una troiata... in questo momento non mi viene in mente il nome) oppur ei lprogetto Linux per 16 Bit (basta una rapida ricerca su google)

Su motorola seria 68xx mi pare sia disponibile un progetto anche se non ricordo il nome.....adesso mi metto a sfogliare i preferiti e se lo trovo lo posto!

ti aggiungo anche: per microcontrollori c'è uclinux ( http://www.uclinux.org/ ) il quale funziona ovviamente senza MMU e non è basato sul kernel 2.6, ma sul 2.0... tanto per sottolineare ulteriormente - anche se non ce n'è proprio bisogno - chi parla a sproposito e chi invece no =)

Ti faccio una confidenza io speravo di poter lavorare il C o Java, ma nelle mie zone richiedevano vb.net e quindi mi sono immerso in questo mare tortuoso.
Pensa che l'ultimo porting è stato una parte di codice in C e un'altra in Java tutte da portare su vb.net, mi volevo ammazzare :rolleyes:


Comprendo benissimo.

Per questo non invidio i programmatori che portano giochi dalla Ps2 al nostro amato PC.
Poi ci sono anche da mettere in mezzo gli ostruzionisti, vedi come è stato programmato Halo per PC o giochi come GTA che sono arrivati in ritardo agevolando le console.

Sì un bel casino. Infatti i giochi nati per più piattaforme finiscono per non sfruttarle mai bene.

Però credo che sony abbia imparato dall'ultima volta e che questo processore sia un po' + orientato al facile utilizzo. Mettendo a disposizione librerie ad alto livello, grazie alle quali non bisogna scendere nel gestire lo stesso come probabilmente avveniva su ps2.

per fx: mi fai un esempio di microcontrollori?
cmq sono d'accordo con riuzasan faresti meglio ad informarti un po' meglio.

per la questione in-order o out-of-order il problema non sussiste in quanto come forse o detto già prima il codice sara fortemente ottimizzato dal compilatore stesso.

E leggendo i vostri commenti dove paragonate il cell a poco più di un pentium 3 700 per il general purpose mi domando come mai l' IBM stia progettando un intera linea di server su processori Cell, (se non sbaglio il processore in un server non è l'ultimo dei componenti).

Seeeeee... magari :)

Benissimo vengano le estensioni al C++ per programmare le SPE. Ottime le librerire. Ma far andare veloce questo chip sara' un incubo, la maggior parte degli argomenti vanno ripensati per il suo modello di programmazione a stream (che non e' banale).

Ha ragione Carmack su tutta la linea sul Cell. Dal punto di vista delle prestazioni, sarebbe stato forse meglio darci una sola CPU out-of-order molto piu' semplice da programmare, ma forse sarebbe costato troppo a loro.



Non proprio :)

ehi ci mancavi :D

Sai che ti volevo chiamare. Ho pensato "qui ci vorrebbe fek, se non ne capisce lui..." :D

. tanto per sottolineare ulteriormente - anche se non ce n'è proprio bisogno - chi parla a sproposito e chi invece no =)


non ce n'è veramente bisogno... :D

per fx: mi fai un esempio di microcontrollori?
cmq sono d'accordo con riuzasan faresti meglio ad informarti un po' meglio.


stai toppando alla grande dandogli torto perchè ha ragione lui...mentre tu e riuzasan sbagliate.
Non perchè lo dica io ovviamente ma perchè sono i fondamenti della microelettronica..(e non mi fate scrivere posts filippica come quello precedente).

Se IBM fa servers con il cell è perchè risparmia...ha un processore GP che gestisce perfettamente il server da solo e una manica di DSP con cui può fargli eseguire dei calcoli in applicazioni mirate trasformandolo in workstation.Tra l'altro è proprio cosi che da anni vengono usati i DSP,insieme ai processori GP.
Il tutto ad un costo minore rispetto ad una macchina specificatamente orientata.

Per la definizione di microcontrollore,anche se l'hai chiesta a Fx,te ne do una anch'io:
I microcontrollori sono sistemi embedded usati per applicazioni di basso consumo.Si distinguono diverse caratteristiche:
- ridotte dimensioni ;
- basso costo ;
- gestione degli interrupt molto sofisticata ed integrata nel processore (le ruotines sono indirizzate
secondo delle tabelle complicate: deve saper distinguere quali eventi hanno priorità) ;
- core computazionale semplice ;
- contatori integrati sul chip (un tipo particolare di contatore è il Watch-dog-timer: ogni N cicli di
CK invia un interrupt al processore;
- presenza convertitori A/D a basse prestazioni;
- presenza di numerose periferiche;

per la questione in-order o out-of-order il problema non sussiste in quanto come forse o detto già prima il codice sara fortemente ottimizzato dal compilatore stesso.



questo è difficilissimo da fare..in ambito GP tutti i sistemi di ottimizzazione come il loop unrolling o i metodi di pieplining per il codice vanno a farsi friggere se usi un DSP la cui caratteristica principale sono i modi di indirizzamento e la capacità di effettuare moltiplicazione e somma in una unica istruzione.
Infatti queste proprietà non ti servono per il funzionamento normale del processore e quindi ti ritrovi a buttare le caratteristiche principlai del DSP dalla finestra meentre allo stesso tempo ti ritrovi a gestire salti ogni 5 istruzioni e,se ne toppi uno,viste le lunghe pipeline del DSP,perdi una media di 20 istruzioni a botta,se ti va bene.
In questo modo le'fficienza è bassissima.

x narmo
Scusa narmo ma stavo parlando di linux (proprio per il general-purpose), minix, uclinux lo so che girano su piattaforme preistoriche, ma non possiamo dire che linux gira anche su una lavatrice :)

Ragazzi andate su
http://www.research.ibm.com/cellcompiler/
Qui c'è tutto sull'ottimizzazione del compilatore Cell anche per l'SPU

per la questione in-order o out-of-order il problema non sussiste in quanto come forse o detto già prima il codice sara fortemente ottimizzato dal compilatore stesso.

Supponiamo che il compilatore sia lo stato dell'arte e produca codice super ottimizzato, tralasciando il fatto che scrivere un tale compilatore richieda anni.

Domanda. Come tratterebbe un tale compilatore un algoritmo di questo tipo:

1) Estrai un numero a caso da 1 a 10
2) Se il numero e' minore di 5
2a) Esegui queste istruzioni
oppure...
2b) Esegui queste altre istruzioni

Quale dei due percorsi il compilatore super ottimizzato in assenza di un'analisi dinamica del codice sceglierebbe?
E se dopo questo codice ci fossero degli accessi alla memoria perche' magari uno dei due path ha fatto uso intensivo della cache e l'altro no? Come potrebbe sapero il compilatore?

In altre parole, il compilatore per quanto evoluto puo' solo fare un'analisi statica del codice e da li' ricavare qualche informazione per produrre codice, ma non puo' assolutamente analizzare la situazione dinamicamente durante l'esecuzione per poi scegliere quali istruzioni emettere. Ovvero, non si puo' fare quello che l'hardware fa con un motore di esecuzione out-of-order in software in maniera altrettanto efficiente.

Il Cell aiuta il compilatore in questo modo eliminando la cache dalle SPE e fornendogli un ambiente nel quale le latenze sono fisse e prevedibili, proprio per facilitare la generazione di codice ottimizzato. Questa e' un'idea interessantissima che pero' pesa ulteriormente sul modello di programmazione ed infine sul programmatore che prima puo' ignorare il problema, perche' la cache e' traspranente, ora deve strutturare l'algoritmo di modo da lavorare con una memoria privata, introducendo ulteriori complicazioni.


E leggendo i vostri commenti dove paragonate il cell a poco più di un pentium 3 700 per il general purpose mi domando come mai l' IBM stia progettando un intera linea di server su processori Cell, (se non sbaglio il processore in un server non è l'ultimo dei componenti).

Perche' li produce lei e non li deve comprare? :)

mmx 2? Sei sicuro di parlare seriamente? Non esistono le MMX 2. :D (ho un manuale originale intel e parla di MMX, SSE, SSE2, SSE3 ma delle MMX 2 mai viste. xD)

Ehm.... penso che si tratti di una seconda revisione delle mmx base fatta su
cpu piu' recenti dei vecchi pentium-mmx (166 Mhz e 200 Mhz). Sui manuali
saranno probabilmente inglobate nelle mmx.

Perche' li produce lei e non li deve comprare? :)

O forse perche' il programma general-purpose piu' impegnativo dal punto di vista
dei calcoli e' quello per leggere le e-mail? (e ne avevo uno su pentium 166...)

Lo richiedo, per favore ditemi quale tipo di applicazioni oggi oltre
-Multimedia
-Giochi
-vettoriale
abbia bisogno di piu' potenza..... lo screensaver animato? -> Multimedia.
database? per l'utilizzo che un utente normale ne fa, una cpu a 1,4 Ghz
stra-avanza (e dubito che ci siano molte aziende col pentium EE per fare
database....).
Mi posso sbagliare, smentitemi.

Perche' li produce lei e non li deve comprare? :)

E' uno dei motivi, ma non penso che sia solo per questo. ;)

>piu leggo su cell e apple meno capisco l'esistenza di apple e mondo mac, contro ogni regola di mercato isolarsi per mantenere un monopolio in un settore di nicchia.
l'unica cosa buona che ha fatto apple è stato il music store.<

Complimentoni. Probabilmente stai ancora usando il DOS e gli ambienti di sviluppo Borland dell'epoca. Non cambiare, come ha detto Gates qualche anno orsono, l'interfaccia grafica e' una cosa inutile e non avra' successo.

La fortuna di Apple e' stata ed e' la sua nicchia, come dicono anche tutti gli analisti. Nel periodo di crisi della Silicon Valley (2000-2001 se non sbaglio) mentre tutti licenziavano era l'unica che assumeva e dava il via a nuovi progetti (infatti c'e' OS X ma non Longhorn).

Benvenuto nel 2005!

abbia bisogno di piu' potenza..... lo screensaver animato? -> Multimedia.
database? per l'utilizzo che un utente normale ne fa, una cpu a 1,4 Ghz
stra-avanza (e dubito che ci siano molte aziende col pentium EE per fare
database....).
Mi posso sbagliare, smentitemi.

Algoritmi di Intelligenza Artificiale, che non sono altro che grandi ricerche in grafi (per ora), ovvero la tipica applicazione general purpose e praticamente impossibile da eseguire in streaming.

Non so se qualcuno l'ha gia' postato:

http://www.realworldtech.com/page.cfm?ArticleID=RWT072405191325&p=4

>Algoritmi di Intelligenza Artificiale, che non sono altro che grandi ricerche in grafi (per ora), ovvero la tipica applicazione general purpose e praticamente impossibile da eseguire in streaming.<

Quindi anche gli Engine 3D basati su BSP tipo Quake & co.
A come dici tu la vedo nera su tutto.

Per SiliconBrain

per microcontrollore si intende un processore che integra al suo interno ROM RAM Linee di I/O (AD-DA converter etc)....

Philips come tutti i grandi produttori di Chip ne hanno in catalogo decine.. si tratta di CPU vere e proprie che lavorano a 8/16/32 Bit e vengono impiegati in qualsiasi aggeggio elettronico dalle TV alle lavatrici!.

>Algoritmi di Intelligenza Artificiale, che non sono altro che grandi ricerche in grafi (per ora), ovvero la tipica applicazione general purpose e praticamente impossibile da eseguire in streaming.<

Quindi anche gli Engine 3D basati su BSP tipo Quake & co.
A come dici tu la vedo nera su tutto.

Ok, gli engine ormai non usano piu' BSP, ma sono ci comunque dei grafi di oggetti da attraversare, per poi decidere oggetto per oggetto (nodo per nodo) se e' visibile o meno. Anche in questo caso non e' un algoritmo naturalmente adatto ad uno stream processor. Ma puo' essere un po' modificato con qualche complicazione.

O forse perche' il programma general-purpose piu' impegnativo dal punto di vista
dei calcoli e' quello per leggere le e-mail? (e ne avevo uno su pentium 166...)

Lo richiedo, per favore ditemi quale tipo di applicazioni oggi oltre
-Multimedia
-Giochi
-vettoriale
abbia bisogno di piu' potenza..... lo screensaver animato? -> Multimedia.
database? per l'utilizzo che un utente normale ne fa, una cpu a 1,4 Ghz
stra-avanza (e dubito che ci siano molte aziende col pentium EE per fare
database....).
Mi posso sbagliare, smentitemi.
:rotfl: chiedi a edivad se il database di hwupgrade gira tranquillamente su un celeron a 1,4 ghz :asd:

:rotfl: chiedi a edivad se il database di hwupgrade gira tranquillamente su un celeron a 1,4 ghz :asd:

si ma devi considerare che si può overclockare :sofico:

La fortuna di Apple e' stata ed e' la sua nicchia, come dicono anche tutti gli analisti. Nel periodo di crisi della Silicon Valley (2000-2001 se non sbaglio) mentre tutti licenziavano era l'unica che assumeva e dava il via a nuovi progetti (infatti c'e' OS X ma non Longhorn).

assolutamente si, infatti il rischio del passaggio agli x86 è proprio quello di uscire da una nicchia (se vuoi ho scritto una cosa in proposito, se vuoi il link te lo passo in pm)

x fek

>Ok, gli engine ormai non usano piu' BSP

Unreal Engine li usa ancora. ;)
E se non sbagli anche il Source (HL2) li usa per ambientazioni statiche indoor.

x fek

>Ok, gli engine ormai non usano piu' BSP

Unreal Engine li usa ancora. ;)
E se non sbagli anche il Source (HL2) li usa per ambientazioni statiche indoor.

Sono entrambi dei portal system :)

Basta andare sul sito della SONY - Sezione research e ci sono delle belle presentazioni riguardanti il CELL da settimane, le specifiche di programmazione e SDK si possono reperire sul sito della nvidia (cg) o dal sito opengl|ES ...
Innanzitutto il core ha già un automatismo eccelso: quello di gestire autonomamente le 8 pipeline senza che il programmatore se ne occupi.

http://research.scea.com/research/html/CellGDC05/index.html

x FX

>assolutamente si, infatti il rischio del passaggio agli x86 è proprio quello di uscire da una nicchia (se vuoi ho scritto una cosa in proposito, se vuoi il link te lo passo in pm)<

sono pronto. passamelo. thanks.

Basta andare sul sito della SONY - Sezione research e ci sono delle belle presentazioni riguardanti il CELL da settimane, le specifiche di programmazione e SDK si possono reperire sul sito della nvidia (cg) o dal sito opengl|ES ...
Innanzitutto il core ha già un automatismo eccelso: quello di gestire autonomamente le 8 pipeline senza che il programmatore se ne occupi.

http://research.scea.com/research/html/CellGDC05/index.html
e ovviamente io dovrei dare ragione a te che kiami le 8 SPE semplicemente 8 pipeline.......
e visto ke ci sei...spiegami come fare a gestire automaticamente le 8 SPE (e non piepline :rolleyes: ) in un universo che NON sia inerentemente NON causale...........:rolleyes:

:rotfl: chiedi a edivad se il database di hwupgrade gira tranquillamente su un celeron a 1,4 ghz :asd:

Ho detto "utente normale". Questo esula dai server con gestione di database
non ordinati....

Il Cell è un'architettura stupenda che mi ricorda la stessa rivoluzione che l'Amiga portò nel settore home nel 1985.
A me no, anche perché il Cell è soltanto un "processore", mentre l'Amiga è una macchina completa, sia per l'hardware sia per il software.
Bollarla come "difficile da programmare" è assurdo! In 2 mesi il team di Unreal ha portato il suo motore sulla PS3 che farà parte del kit di sviluppo ufficiale, stessa cosa vale per l'Havok e per un motore super usato e collaudatissimo come quello NetImmerse di NDL.
Non è difficile da programmare, perché alla fine si lavora in C/C++, come traspare dalla notizia, e al più in assembly (per i masochisti :asd: ), ma il problema è quello di riuscire a sfruttare le risorse che mette a disposizione.
Tutto sta nella mentalità e nelle capacità dei programamtori che ormai (soprattutto in Italia) sono troppo abituati ad accontentarsi di VisualBasic per fare qualcosa se non peggio.
Non vedo cosa ci sia di male ad usare il VisualBasic... :rolleyes:

Comunque anche i programmatori più esperti dovranno fare i salti mortali per cercare di sfruttarla come meglio possono. Già, come meglio possono perché l'architettura è quella che è, e miracoli non ne possono fare di certo.
Cmq per una vera veduta d'insieme dell'architettura Cell consiglio questo sito

http://www.blachford.info/computer/Cell/Cell0_v2.html

E' abbastanza indicativo di ciò che questo nuovo processore può offrire se non verrà sminuito da chi continua a smerciare per ignoranza o per interesse commenti inutili e lesivi.
No, viene sminuito dal fatto che è un "articolo" vecchio, che risale a quando ancora si sapeva poco dell'architettura di Cell, e che è scritto da uno che ha lasciato galoppare anche troppo la fantasia, sparando bordate che si commentano da sé.

Vedi, ad esempio, le incredibili cazzate che è riuscito ad affermare quando, facendo paragoni e traendo conclusioni molto fantasiose, delineava un futuro brillante per il Cell, che avrebbe scalzato il PC e l'architettura x86, aprendo addirittura le porte a Apple per il dominio dell'home computing.

Pura follia. E c'è gente che continua a crederci... :rotfl: :rotfl: :rotfl:

Non si tratta di "difficile da programmare" o no.. si tratta di capire se effettivamente le sue potenzialità sono nell'architettura o nella super ottimizzazione del software...
Itanium: ottima architettura SULLA CARTA, che avrebbe dovuto rappresentare il futuro in qualunque settore, dal desktop ai supercomputer.

Intel puntava molto sullo sviluppo dei compilatori per spremerlo al meglio.
Ha fallito, perché:
- i compilatori non posso fare miracoli e "super ottimizzare" il codice;
- il codice per sua stessa natura si scontra con l'architettura in-order di Itanium.

Intel non è certo l'ultima arrivata nel campo dei processori e dei compilatori: cosa ti fa pensare che per Cell e IBM/Sony sarà diverso?
Giustamente avere a disposizione un set di istruzioni "completo" semplifica di molto la vita del programmatore in quanto quest'ultimo non deve fare assurdi giri con il codice per, faccio un esempio, eseguire una moltiplicazione a 128Bit su un sistema a 32.
Potevi cercare un esempio migliore: è un'operazione più unica che rara nel campo della programmazione... :p

Comunque non è certo il set di istruzioni (ISA) che fa la differenza in questo caso: i programmatori lavoreranno per lo più in C/C++.
Se poi si parla di portabilità del codice mi pare che le specifiche ANSI C/C++ esistano da parecchi anni. Aggiungere istruzioni a queste specifiche singnifica uscire dagli standard e creare uno dei tantissimi dialetti del C/C++... la domanda è ne vale veramente la pena?
Due volte sì.
Il primo perché semplifica la vita ai programmatori, vista l'architettura.
Il secondo perché si tratta di sviluppare software per una ben precisa architettura, per cui il problema della portabilità è relativo.
In fondo stiamo parlando di una console.. non certo di un super cluster.
E' totalmente inutile poi pubblicizzare un elevatissimo numero di core (8 mi pare... è esatto?) se poi 7 di questi altro non sono che processori dedicati alla decodifica dei flussi audio/video e quindi totalmente inutilizzabili da parte dei programmatori.
Direi di no, altrimenti IBM non avrebbe mai realizzato dei supercomputer col Cell.
Insomma Cell a me pare un'integrazione di tutti i vari DSP che ci sono nelle console e similare più che una rivoluzione!
Pienamente d'accordo, ma i DSP non li usano mica solo le console... ;)
(Anche perchè allo stato attuale dei processori la vera rivoluzione la fa il software se scritto come si deve!! Molti dicono di saper programmare... pochi sanno veramente farlo)
Già. E pochi sanno che non tutti i tipi di codice possono trarre beneficio da un'architettura come quella di Cell e Xenon, per quanto bravi possano essere i programmatori...

Cioè FX ... ti pagano per scrivere queste panzanate?
Strano: è la prima cosa che ho pensato quanto ho letto i tuoi messaggi... :p
Cioè secondo te, un processore con un core base che è un PPC G5
Ah, questa è nuova: mi fai vedere un documento ufficiale che lo afferma?

Perché a giudicare dai diagrammi di funzionamento di Cell e PPC970/G5, direi che si tratta di architetture alquanto diverse... ;)

Non è che per caso confondi l'ISA di un processore (in parole povere: il fatto che entrambi siano di "derivazione" PowerPC) con la sua implementazione?
non è adatto a far girare un programmino Office?
Beh, questo sì: non è che serva la potenza di calcolo di un Cray... :p
Un processore con 7 Coprocessori programambili non potrà gestire egregiamente anche grossi DB n un confronto diretto con qualunque processore della classe X86?
No, perché non è stato pensato per questo tipo di operazioni. Questo non vuol dire che non è in grado di farlo, ma semplicemente che prenderà delle sonore legnate da un processore x86 da quattro soldi...
Guarda che oggi la vera sida tra processori si gioca in campo Multimediale e di calcolo vettoriale, l'unico in cui si chiede TANTA, TANTA potenza di calcolo.
Mi sai che hai una visione un po' troppo limitata...
Per rimanere nello stesso ambito in cui il Cell vuole emergere, Un P4 EE o un Athlon 64 FX non sono progettati e spinti attualmente per Word o Access, ma per macinare calcoli in virgola mobile e vettoriali, gli unici che attualmente servono DAVVERO in ambito home perchè, se si escludono progs Multimediali e Giochi, basta anche un semplice Celeron 500 in casa o in ufficio.
Avrei i miei dubbi, visto il numero di funzionalità che vengono aggiunte alle applicazioni, e all'evoluzione che subiscono...
Questa fantasiosa idea che il Cell serve solo a giocarei è simile all'affermare che un P4 o un Athlon64 serve solo a giocare
Infatti non è così, ma è evidente che Cell e P4/Athlon sono altamente specializzati, e che quindi eccellono in campi diversi.
e continua a farmi ricordare di quello che si diceva dell'Amiga e del suo OS "Serve solo a giocare" ... poi si è visto sia dal punto di vista software che hardware.
L'amiga OS era un OS con multitask preempitive nel 1985 (allora giudicata cosa "inutile per ambiti home"). L'Amiga 3000 aveva una architettura IDENTICA a quella dei PC attuali con chipset, bus dma, bus esterni accessibili direttamente dal chipset etc ...
Beh, identica... Insomma... Una parola grossa... A grandi linee, magari sì, ma il bus Zorro, tanto per fare un esempio, non trova certo equivalenti: era asincrono (quasi tutti i bus realizzati finora sono, invece, sincroni).
allora giudicati inutili per sistemi home.
Veramente Amiga era stato progettato per essere principalmente una macchina da gioco, ma con l'obiettivo di servire anche ad altro.

... A che servono?
Inosmma, non mi pare certo il caso: se non resvono già ora che di DSP è pieno il mondo, a che serviranno domani? Perchè ce ne sono 8 o 9?
A me sembra più una bella notizia: talmente potente che il c/c++ necessita di istruzioni .. ed eccoti un'altra bufala tipo new economy!
Perché, i DSP come pensi di programmarli? In C/C++ puro? E mi spieghi poi come fai a utilizzare pienamente certe loro caratteristiche?
Per svilupparla in pieno mi aspetto semmai delle LIBRERIE che la sfruttino, scritte da team CAPACI e informati (vedi SONY). NOn certo da un poveraccio come me o altri "piccoli" sviluppatori.
Ci sono, ci sono, ma Sony non può mica farti anche l'engine del tuo gioco... :p
.. Chissà perchè 'sto cell mi ricorda tanto Amiga. E la povera fine che ha fatto!
Perché, che fine ha fatto? Esiste ancora... ;)

inoltre i PPC della xbox possono utilizzare 2 thread per core
Esattamente come la PPE del Cell.
quindi mentre 1 fa calcoli sugli interi il secondo puo utilizzare l'unita in virgola modile cosi da sfruttare meglio l'hardware.
Mah, insomma: sono molto scettico da questo punto di vista... Mica tutto il codice si può scrivere in moda utilizzare sempre un'istruzione intera e una FP. Anzi, è decisamente difficile ciò che accada...

La cosa "strana" della PPE del Cell è che abbia un'estesa componente vettoriale, cioè il "vecchio" Altivec in un implementazione (a quanto pare) potenziata.
Non mi sembra: le estensioni VMX di PPE utilizzano fino a 3 registri, mentre Altivec fino a 4.
Di questo ne abbiamo già parlato in passato: IMHO non è affatto compatibile con Altivec.

mmx 2? Sei sicuro di parlare seriamente? Non esistono le MMX 2. :D (ho un manuale originale intel e parla di MMX, SSE, SSE2, SSE3 ma delle MMX 2 mai viste. xD)
Alcune volte ho sentito parlare di MMX2 riguardo alle estensioni delle MMX che Intel ha introdotto con le SSE.

Perchè no?
E' vero che le SPE sono prettamente vettoriali, ma sono anche processori a tutti gli effetti con unità intera a 64bit e FP a doppia precisione (volendo) e possono essere utilizzate in modalità scalare. E sono TANTE.
I principali database sono multithreading, quindi potrebbero sfruttarle tranquillamente come 'normali' processori. Beh, quasi.
Non è questione di multithreading: è il codice dei database che è molto difficile da adattare alle SPE.

Prova a pensare di realizzare server database usando le MMX o le SSE: non è impossibile, ma risulterà ESTREMAMENTE LENTO E INEFFICIENTE.
Hanno memoria locale e tutto il resto, gli algoritmi andranno sicuramente riscritti e ottimizzati per l'hardware, ma è pensabile che possa essere fatto, e se viene fatto le prestazioni saranno sicuramente notevoli! 8 core da 3.2 (o 4+ più per server che non badano troppo ai W) Ghz sono sono uno scherzo!
Vedi sopra: per quanto tu possa ottimizzare, le prestazioni saranno sempre MOLTO SCARSE. C'è poco da fare: le architetture SIMD-like non sono state pensate per database, compilazione del codice, emulazione, ecc., ma per tutt'altra cosa: calcolo massicciamente parallelo.

Poi c'è da dire che le SPE sono pure architetture in-order, che soffrono pure moltissimo dei branch misprediciton, e il quadro diventa ancora più desolante.

Meglio un Duron a 1,6Ghz che 8 SPE a 3,2Ghz... :D

Questo dove l'hai letto?
Si riferiva al calcolo intero "classico": le SPE possono operare sugli interi ovviamente, ma sempre come architettura SIMD.
A parte il fatto che, se non ricordo male, anche le SPE hanno uno stadio di 'branch prediction' benchè semplificato. Poi è proprio l'architettura particolare con memoria locale (e con numero di pipeline ridotto) che limita le penalizzazioni in caso di branch mis-prediction.
Al contrario, le SPE soffrono parecchio a causa di eventuali branch misprediction e non è certo la presenza della memoria locale che li "salva".
D'altra parte le SPE sono state pensate per eseguire codice in cui i salti sono molto rati.
Per confronto, la PPE risente molto meno delle SPE in caso di branch misprediction, prioprio perché è stata pensate per compiti diversi (codice "più general purpose").
Se un P4 sbaglia un salto deve svuotare la pipeline e andare a prendere dati nella RAM che ha latenze estremamente alte, prima di ricominciare a macinare numeri. Il Cell può accedere molto più velocemente alla sua memoria locale.
Certo, perché secondo te il P4 non ha una sua memoria locale? E le cache L1 e L2 dove le mettiamo? :rolleyes:

Inoltre l'accesso alla memoria da parte del P4 ha una latenza nettamente inferiore rispetto a PPE e SPE...
Certo, poi bisogna vedere se davvero le cose funzionano davvero meglio con questo nuovo approccio oppure no, e in quali casi... ma è un po' presto per dirlo.
Non è presto: ne abbiamo già parlato quando ancora di Cell si sapeva poco, e le testimonianze dei programmatori che adesso ci stanno lavorando non fanno che confermare le ipotesi che avevamo formulato. ;)
L'unica cosa certa è che per sfruttare al meglio il Cell bisognerà programmarlo con un livello di astrazione molto più basso rispetto al trend attuale. Cioè pensando all'hardware che c'è sotto e a come è implementato. Un passo indietro sicuramente...
Che richiede tempo, e soprattutto che non può portare comunque benefici se non nell'ambito per cui Cell è stato progettato...

Fx le tue panzanate continuano, sei pregato di informarti meglio se non vuoi fare la figura dell'ignorante falso saccente.
Ma tu guarda: più leggo i tuoi messaggi, più sono d'accordo con queste tue frasi... :p
Questa è fantastica, dovremmo girarla a chi ha visto un INTERO IBM Blade server basato su 2 "DSP" CELL
Bisogna vedere per quale settore verrà venduto. 100 a 1 che si guarderà bene dall'impiegarlo nel campo dei database. Si accettano scommesse... :p
con tanto di Linux in running ...
Questo non significa nulla: Linux puoi trovare usato dal supercomputer come pure dalla lavatrice ultratecnologica.
o a chi ha visto una MB di Toshiba con un solo CELL on Board come main "DSP" (sto per rotolare dal ridere) runanre vari demo tra i quali il famoso con 42 stream mpeg2 in contemporanea.
Appunto. Compiti altamente specifici e per cui Cell "eccelle"... ;)

A me ha fatto rotolare dalle risate il tuo "runnare"... Laurea a Oxford, per caso? :asd:
Fx la tua giunzione delle parole DSP e Cell chiarifica bene cosa sai tu del Cell e del concetto di CPU in generale.
Mi trovo sempre più d'accordo: quand'è che comincerai a studiare seriamente come funzionano le architetture dei processori? :p
Sarebeb meglio che almeno sul Cell leggessi un pò
Idem come sopra: possibile un po' di roba buona... :asd:
questa guida, scritta da qualcuno che di processori ne capisce e non da chi ha visto in tutta la sua vita sui desktop solo X86
http://www.blachford.info/computer/Cell/Cell0_v2.html
Questa guida, come ho già detto, è scritta da uno che avrà leccato qualche francobollo prima di mettersi davanti alla tastiera...

Meglio Topolino: è più istruttivo... :p

Altra cazzata... I programmatori avranno degli strumenti così potenti che non avranno bisogno di scerverlarsi più di tanto (pensa a tutto il compilatore e i vari strumenti di profiling).
Toh, ma guarda: più o meno è quello che pensava Intel con Itanium... :p
Per non parlare che il 90% dei programmatori lavoreranno con framework di engine già esistenti (es. Unreal Engine, Havok, Novodex quindi Ageia con Phisix ecc.)
Non puoi mica riciclarli così come sono stati fatti per PC, ad esempio, a meno di veder sfruttare il Cell ancora peggio...
3.2 GHZ, 64 Bit, banda memoria Cpu di oltre 20 Gbit/s... be allora stiamo scrivendo proprio p*******e.
E' quel che penso io: sparare delle caratteristiche "ad muzzum" quando si parla di applicazioni general purpose dimostra di non aver capito una mazza né dell'uno né dell'altro...

Oggi m'invento un processore a 10Ghz, 128 bit, con 100Gbit/s e sono già sicuro che andrà benissimo nelle applicazioni general purpose.

Oggi mi sono fatto una pera...

Solo che per me è inconcepibile amare la programmazione e dire "fortuna che lavoro con vb". Per me sarebbe una disgrazia e non perchè ho un linguaggio preferito. Perchè ne preferisco 10 al vb.
Hai detto bene: per te. E' una questione di gusti. Ampiamente discutibili...

Ma se tuo padre conosce il c++ (o C#, o java), prova a chiedergli in cosa preferirebbe programmare.
Data l'età, probabilmente in Fortran, Pascal, LISP o addirittura in SmallTalk... ;)

Io conosco il C++ (e una marea di altri linguaggi), ma preferisco lavorare in Pascal/Delphi e Python. De gustibus... :sofico:

per la questione in-order o out-of-order il problema non sussiste in quanto come forse o detto già prima il codice sara fortemente ottimizzato dal compilatore stesso.
:rotfl: :rotfl: :rotfl:

A quando la moltiplicazione dei pani e dei pesci? :p
E leggendo i vostri commenti dove paragonate il cell a poco più di un pentium 3 700 per il general purpose mi domando come mai l' IBM stia progettando un intera linea di server su processori Cell, (se non sbaglio il processore in un server non è l'ultimo dei componenti).
Mi domando se tu conosci veramente il settore dei server... :rolleyes:

100 a 1 che IBM non venderà le sue macchinette Cell-based come database server (ma è solo un esempio). Si accettano scommesse... :p

Ragazzi andate su
http://www.research.ibm.com/cellcompiler/
Qui c'è tutto sull'ottimizzazione del compilatore Cell anche per l'SPU
Interessante. Tu l'hai letto? Se sì, continui a sostenere le tue precedenti affermazioni, oppure finalmente hai trovato l'illuminazione e ti cospargi il capo di cenere per i peccati che hai commesso? :D

O forse perche' il programma general-purpose piu' impegnativo dal punto di vista
dei calcoli e' quello per leggere le e-mail? (e ne avevo uno su pentium 166...)

Lo richiedo, per favore ditemi quale tipo di applicazioni oggi oltre
-Multimedia
-Giochi
-vettoriale
abbia bisogno di piu' potenza..... lo screensaver animato? -> Multimedia.
database? per l'utilizzo che un utente normale ne fa, una cpu a 1,4 Ghz
stra-avanza (e dubito che ci siano molte aziende col pentium EE per fare
database....).
Mi posso sbagliare, smentitemi.
http://www.mame.net/screenshots/gng.png

http://www.mess.org/screens/zx81.png

:cool:

Innanzitutto il core ha già un automatismo eccelso: quello di gestire autonomamente le 8 pipeline senza che il programmatore se ne occupi.

http://research.scea.com/research/html/CellGDC05/index.html
Proprio il core automaticamente non gestisce niente, e poi si parla di 8 SPE e non di 8 pipeline...

Data l'età, probabilmente in Fortran, Pascal, LISP o addirittura in SmallTalk... ;)

Io conosco il C++ (e una marea di altri linguaggi), ma preferisco lavorare in Pascal/Delphi e Python. De gustibus... :sofico:


A dire il vero continuerebbe in Cobol o addirittura in Assembly (ci ha scritto la tesi...)

Assembly? Buon sangue non mente... :p

dopo la codifica mp3 , l'editing video rappresenta l'utilizzo piu'
stressante per gli attuali proc athlon e intel , quindi benvenga questo cell !!!!!!!!!!!!!!!!!

ma i supercomputer paralleli non ci sono gia' da cinquant'anni
quindi qualche idea sul codice e come si gestiscono piu' cpu ci dovrebbe gia' essere......

Come già si temeva, sarà un inferno per i programmatori...
Nuove estensioni al C e al C++, nuovi tipi di dati, più la necessità di un multi-threading estremo per sfruttare al meglio questa bestiola.
Il porting da/verso altre piattaforme sarà un macello :(

Le potenzialità devono essere enormi, bisogna vedere se saranno sfruttabili...

Guarda che non è questo che rende un inferno programmarla. Non è nulla di piu' complicato che dover far fronte a delle nuove API. Anzi, se queste estensioni rendono di piu' alto livello C e C++, potrebbe essere ancora piu' facile programmarci.

P.S.: Qualcuno ne sa qualcosa? E' stata rilasciata della documentazione su queste estensioni? Vorrei dargli uno sguardo. Grazie.

Ancora con questa stronzata del calcolo distribuito?
Ma scrivessero features serie anzichè un mare di sciocchezze ....

Il calcolo distribuito è una stronzata... :doh: Uno dei settori piu' fertili dell'informatica definito una stronzata :doh:

P.S.: Qualcuno ne sa qualcosa? E' stata rilasciata della documentazione su queste estensioni? Vorrei dargli uno sguardo. Grazie.

Tutta la documentazione rilasciata ieri (sul sito IBM ci sono gli stessi files).
http://cell.scei.co.jp/e_download.html

Assembly? Buon sangue non mente... :p

Che ci vuoi fare, quando si è laureato nel 74 andavano avanti a schede perforate, 1KB di Ram e ovviamente assembly

Solo che per me è inconcepibile amare la programmazione e dire "fortuna che lavoro con vb". Per me sarebbe una disgrazia e non perchè ho un linguaggio preferito. Perchè ne preferisco 10 al vb.

Non posso fare altro che quotarti.
Rispondo anche a chi diceva che il 60% dei programmatori Windows usa VB. FORTUNATAMENTE non è vero. O per lo meno, è software interno, non disponibile alle masse. :asd: :asd: :asd:

Tutta la documentazione rilasciata ieri (sul sito IBM ci sono gli stessi files).
http://cell.scei.co.jp/e_download.html

Grazie, gli do uno sguardo. Spero di trovare qualcosa su queste estensioni.

Ehm... nessuno sta dicendo che questa cpu sia anche solo paragonabile ad un
dual-opteron in campo database (e del resto e' nell'interesse di Sony che
nessuno usi la sua console come server 24h su 24).

Mi sto (ci stiamo?) domandando se il semplice utente desktop, che difficilmente
usa database con piu' di 300 campi e puo' tranquillamente usare databases
ordinati, non trovera' "conveniente" decidere di passare a simili soluzioni.
Rinunciando alle prestazioni database, alle future applicazioni di IA ed alla
"vecchia" implementazione di BSP, per avere in cambio potenza bruta nel
campo multimedia, rendering 3d e giochi (e scusate se e' poco, ma ultimamente
quasi tutti i benchmark riguardano questi ambiti...).

Il tutto (SE -e ripeto SE- la PS3 sara' davvero "aperta" quanto lo e' la PSP) allo
stesso prezzo con cui attualmente si compra un entry level (600 Euro o meno).

Si tratta di speculazioni teoriche soprattutto per un dato di fatto: l'inerzia
del mercato (e l'inerzia di utenti/programmatori a cambiare piattaforma).

Fatto sta che SE le prestazioni sono vicine a quelle preannunciate (encoding
H264 in tempo reale..... scusate se e' poco ma con un PC anche dual core ce
lo scordiamo) e SE il "malus" e' veramente di far girare databases come
un pentium 1,4Ghz, questa piattaforma meriterebbe davvero di soppiantare
l'ormai stra-aggiornata x86 (IN AMBITO DESKTOP).

Il calcolo distribuito è una stronzata... :doh: Uno dei settori piu' fertili dell'informatica definito una stronzata :doh:

Lo e' per un utente desktop, al quale questa piattaforma si rivolge (desktop,
grafica e conversione audio/video). Il fatto che, SE le prestazioni di rendering
saranno simili a quelle multimedia, ci si possa costruire una render farm a prezzi
molto modici e' secondario (nel senso che e' cmq un mercato di nicchia).

Fatto sta che SE le prestazioni sono vicine a quelle preannunciate (encoding
H264 in tempo reale..... scusate se e' poco ma con un PC anche dual core ce
lo scordiamo) e SE il "malus" e' veramente di far girare databases come
un pentium 1,4Ghz, questa piattaforma meriterebbe davvero di soppiantare
l'ormai stra-aggiornata x86 (IN AMBITO DESKTOP).

Sarei curioso di sapere un utente domestico che cosa se ne fa di codificare 48 flussi video contemporaneamente: compra 48 monitor?

Ancora con la storia della PS3 aperta dopo che questa ipotesi e' stata smontata in lungo e in largo...

(Non so che codec h264 hai visto, ma un P4 3.6 e' perfettamente in grado di fare l'encoding in tempo reale ad un bitrate decente)

P.S.: Qualcuno ne sa qualcosa? E' stata rilasciata della documentazione su queste estensioni? Vorrei dargli uno sguardo. Grazie.

Si', sono molto simili alle estensioni C/C++ per l'SSE di Intel.
Il problema non sono le estensioni in se', ma e' l'adattare algoritmi non facilmente parallelizzabili ad un modello di programmazione che se non implementato correttamente rende il Cell estremamente lento.

Se una donna fa un bambino in 9 mesi, 9 donne non fanno un bambino in 1 mese solo.

Mi sto (ci stiamo?) domandando se il semplice utente desktop, che difficilmente usa database con piu' di 300 campi e puo' tranquillamente usare databases ordinati, non trovera' "conveniente" decidere di passare a simili soluzioni.
Rinunciando alle prestazioni database, alle future applicazioni di IA ed alla "vecchia" implementazione di BSP, per avere in cambio potenza bruta nel campo multimedia, rendering 3d e giochi (e scusate se e' poco, ma ultimamente quasi tutti i benchmark riguardano questi ambiti...).

Fatto sta che SE le prestazioni sono vicine a quelle preannunciate (encoding
H264 in tempo reale..... scusate se e' poco ma con un PC anche dual core ce
lo scordiamo) e SE il "malus" e' veramente di far girare databases come
un pentium 1,4Ghz, questa piattaforma meriterebbe davvero di soppiantare
l'ormai stra-aggiornata x86 (IN AMBITO DESKTOP).
Scusami, ma un P4 (Northwood) a 3,2Ghz o un Athlon64 3000+ che hanno circa 55 milioni di transistor (1 / 5 rispetto al Cell) fanno benissimo il loro lavoro anche nel multimedia e non presentano colli di bottiglia per la maggior parte delle applicazioni "desktop": mi spieghi per quale motivo dovremmo buttare tutto?
Si tratta di speculazioni teoriche soprattutto per un dato di fatto: l'inerzia del mercato (e l'inerzia di utenti/programmatori a cambiare piattaforma).

Vorrei vedere te a sbatterti la testa per cercare di far funzionare al meglio il Cell. Ma chi me lo fa fare, quando con un'architettura classica non ho problemi di questo tipo? Sto benissimo così e vado avanti lo stesso (anzi)...

Secondo me, uno dei motivi per cui Sony e Microsoft puntano su architetture molto diverse dalle CPU per pc è per rendere la vita difficile a chi vuole svilupparne un emulatore per PC: si stanno ancora arabattando con l'emulatore della PS2, figurarsi quello della PS3...
Ovviamente non dico che non si possa fare un emulatore del Cell o dello Xenon, ma i programmi ottimizzati per queste console andranno lentissimi sui pc...

x cdimauro

>Interessante. Tu l'hai letto? Se sì, continui a sostenere le tue precedenti affermazioni, oppure finalmente hai trovato l'illuminazione e ti cospargi il capo di cenere per i peccati che hai commesso?

In effetti l'ho letto e a te bastava solo guardare le figure per notare che il compilatore fa guadagnare con le ottimizzazioni fino al 2600%.
Prima di sparare commenti a raffica fossi in te ci penserei almeno un paio di volte per evitare certe figure.

x cdimauro

>Interessante. Tu l'hai letto? Se sì, continui a sostenere le tue precedenti affermazioni, oppure finalmente hai trovato l'illuminazione e ti cospargi il capo di cenere per i peccati che hai commesso?

In effetti l'ho letto e a te bastava solo guardare le figure per notare che il compilatore fa guadagnare con le ottimizzazioni fino al 2600%.
Prima di sparare commenti a raffica fossi in te ci penserei almeno un paio di volte per evitare certe figure.

Fino al 2600% rispetto a che cosa?
Ha ragione cidimauro qui: pensare che un compilatore in grado di analizzare il codice solo staticamente sia in grado di sopperire ad un motore di esecuzione non out-of-order e' pura fantascienza. Chi ci ha provato in passato, non ci e' riuscito.

Secondo me, uno dei motivi per cui Sony e Microsoft puntano su architetture molto diverse dalle CPU per pc è per rendere la vita difficile a chi vuole svilupparne un emulatore per PC: si stanno ancora arabattando con l'emulatore della PS2, figurarsi quello della PS3...
Ovviamente non dico che non si possa fare un emulatore del Cell o dello Xenon, ma i programmi ottimizzati per queste console andranno lentissimi sui pc...
Io penso che questo sia l'ultimo dei loro problemi.
Le console utilizzano processori differenti da quelli per computer perché devono fare cose differenti ;).
Anche perché l'emulazione di console così complesse è alquanto difficoltosa, ed è praticamente impossibile che riesca ad essere fatta durante la vita commerciale di una console, vista la scarsa organizzazione e l'assenza di una qualche società che abbia interessi commerciali a compierla.
Inoltre le nuove console sono dei veri e propri mostri... quando uscì xbox essa aveva un celeron 733Mhz, che all'epoca era tutt'altro che un processore all'avanguardia, c'erano già processori di frequenza più che doppia. Ora, questo novembre avremo xbox 360, una console con tre core, ciascuno da 3,2 Ghz, roba che non si vede su nessun computer. Certo, saranno anche "in order" (ma anche il celeron dell'xbox lo è, no?) al contrario di quelli per pc "out of order", ma tre core da 3,2 Ghz sono sempre tre core da 3,2Ghz.

Il problema dell'emulazione non esiste assolutamente :).

Io parlo da profano, comunque, sono tutt'altro che un esperto in materia, se ho detto qualche castroneria fatemelo notare ;).

Io penso che questo sia l'ultimo dei loro problemi.
Le console utilizzano processori differenti da quelli per computer perché devono fare cose differenti ;).
Anche perché l'emulazione di console così complesse è alquanto difficoltosa, ed è praticamente impossibile che riesca ad essere fatta durante la vita commerciale di una console, vista la scarsa organizzazione e l'assenza di una qualche società che abbia interessi commerciali a compierla.
Inoltre le nuove console sono dei veri e propri mostri... quando uscì xbox essa aveva un celeron 733Mhz, che all'epoca era tutt'altro che un processore all'avanguardia, c'erano già processori di frequenza più che doppia. Ora, questo novembre avremo xbox 360, una console con tre core, ciascuno da 3,2 Ghz, roba che non si vede su nessun computer. Certo, saranno anche "in order" (ma anche il celeron dell'xbox lo è, no?) al contrario di quelli per pc "out of order", ma tre core da 3,2 Ghz sono sempre tre core da 3,2Ghz.

Il problema dell'emulazione non esiste assolutamente :).

Io parlo da profano, comunque, sono tutt'altro che un esperto in materia, se ho detto qualche castroneria fatemelo notare ;).
Il processore della Xbox1 (che è un Pentium3 con meno cache AFAIK) (e mi pare anche l'emotion engine della ps2) sono CPU OOOE.

Comunque, guarda che ho detto uno dei motivi, non il principale. Io ho provato ad avanzare questa ipotesi, ne avete altre? Qual'è, secondo voi, il motivo per cui MS e STI hanno puntato su processori in-order, propensione spinta per il calcolo SIMD (soprattutto per Cell) e per il multithreading ?

Si riferiva al calcolo intero "classico": le SPE possono operare sugli interi ovviamente, ma sempre come architettura SIMD.

Non è obbligatorio, possono usate anche in modo scalare. Quindi in pratica ci sono altre (oltre a quella della PPE) 8 unità intere a 64 bit. Che possono operare contemporameamente sulla memoria (la loro) senza intasare il bus. Non sarà un scherzo usarle tutte insieme, ma se ci si riesce sicuramente il programma VOLA.

Al contrario, le SPE soffrono parecchio a causa di eventuali branch misprediction e non è certo la presenza della memoria locale che li "salva".
D'altra parte le SPE sono state pensate per eseguire codice in cui i salti sono molto rati.

Il problema è un po' diverso rispetto ad un processore classico, perchè la SPE non vede tutta la memoria quando lavora sui dati, ma solo quella locale (limitata a 256K). Quindi l'algoritmo deve sempre lavorare in quest'ambito, e in quest'ambito le penalizzazioni di una branch mis-prediction sono molto limitate rispetta ad un processore classico.
Certo, se i dati su cui deve lavorare sono fuori da questa memoria, allora il programma deve caricare la memoria necessaria e sicurmente questa è un'operazione lenta.
L'IBM si è fatta le sue statistiche e ha deciso che è più conveniente questo approccio rispetto a quello classico. Almeno nell'ambito nel quale vuole utilizzare il Cell (giochi e supercomputer? Mah!). E' la scelta filosofica del Cell spiegata molto bene nel documento introduttivo postato pochi giorni fà.

Ma sicuramente comporta una certa difficoltà nello scrivere algoritmi che non trattano stream di dati. E in molti casi probabilmente non è pratico farlo.

Certo, perché secondo te il P4 non ha una sua memoria locale? E le cache L1 e L2 dove le mettiamo? :rolleyes:

La differenza è che la cache è fuori del controllo del programmatore, che non sa che penalizzazioni ha il suo algoritmo perchè non sa e non può sapere quanti dei suoi dati in un dato momento sono nella memoria veloce (cache) o in quella lenta (Ram).
Sul Cell il caricamento della "cache" (memoria locale) è esplicito, quindi può ottimizzare sicuramente meglio l'accesso ai dati dei suoi algoritmi. Però anche vero che su Cell è COSTRETTO a farlo, quindi comporta un lavoro maggiore.

Non è presto: ne abbiamo già parlato quando ancora di Cell si sapeva poco, e le testimonianze dei programmatori che adesso ci stanno lavorando non fanno che confermare le ipotesi che avevamo formulato. ;)

L'unica "testimonianza" che ho letto finora è quella di Carmak, che dice che il processore dell'Xbox360 (quindi apparentemente anche la PPE del Cell) ha prestazioni pari al 50% di quelle di un x86 moderno.
Quindi direi ben più di un G4 attuale. Per molti qui, che sostengono la superiorità degli x86, più o meno come un G5 di fascia media o più.

Tremendamente scarso? Assolutamente inutilizzabile nel general-pourpose? Non direi proprio...

Comunque, guarda che ho detto uno dei motivi, non il principale. Io ho provato ad avanzare questa ipotesi, ne avete altre? Qual'è, secondo voi, il motivo per cui MS e STI hanno puntato su processori in-order, propensione spinta per il calcolo SIMD (soprattutto per Cell) e per il multithreading ?

Perchè per Sony/IBM è quello che permette di avere più velocità per transistors. Il loro razionale è che è meglio rinunciare ad un po' di velocità sul singolo thread (semplificando notevolmente l'architettura, e quindi riducendo sia il numero di transistor per core che gli stadi di decodifica) per averne molti in esecuzione contemporanamente e a frequenza più elevata.

Perchè per Sony/IBM è quello che permette di avere più velocità per transistors. Il loro razionale è che è meglio rinunciare ad un po' di velocità sul singolo thread (semplificando notevolmente l'architettura, e quindi riducendo sia il numero di transistor per core che gli stadi di decodifica) per averne molti in esecuzione contemporanamente e a frequenza più elevata.
Questo è evidente! :)
Mi chiedevo perché hanno scelto di potenziare le prestazioni in multithreading quando i game developers chiedono più prestazioni nel single threading...

Questo è evidente! :)
Mi chiedevo perché hanno scelto di potenziare le prestazioni in multithreading quando i game developers chiedono più prestazioni nel single threading...

Ah, boh! Forse perchè non erano i giochi il loro unico target?
Il Cell è stato pensato anche come processore multimediale (vedi Toshiba che vuole metterlo nei televisori) e per ambiti scientifici (IBM e i suoi supercomputer). Così avranno fatto un compromesso.
Quanto alla Xbox hanno semplicemente preso 3 PPE del Cell e fatto un processore per Microsoft.

Ah, boh! Forse perchè non erano i giochi il loro unico target?
Dovrebbe essere quello principale, però... Mi associo al boh!
Ho visto che, per quanto riguarda le applicazioni extra-gaming ha risposto Dan Greenberg:

Da http://www-128.ibm.com/developerworks/power/library/pa-cellinterview.html
dW: What type of products could potentially use Cell?
DG: Sony's PlayStation 3 is an obvious example. High-performance consumer electronics like digital television (DTV) and home media servers, some of which have already been announced by Sony and Toshiba, will use Cell.

Such demanding applications as Magnetic Resonance Imaging [for] medical scanners, CT scanners, ultrasound, radar and sonar, where having the rapid manipulation of data into 3D images is really differentiating, could be uniquely suited to Cell.

And there are many opportunities to greatly improve security and surveillance. Imagine, for instance, being able to compress dozens of video streams simultaneously and having the capability to recognize people in real time.

Ha anche risposto ad un quesito che molti ci siamo posti: "a cosa serve poter comprimere decine di flussi video contemporaneamente?". Elementare Waston: "per sistemi di videosorveglianza!". :)

Il processore della Xbox1 (che è un Pentium3 con meno cache AFAIK) (e mi pare anche l'emotion engine della ps2) sono CPU OOOE.

Comunque, guarda che ho detto uno dei motivi, non il principale.

Io penso che non sia neanche uno dei motivi, quando emuleranno xbox 360 decentemente sarà uscito già il successore, se non il successore del successore...

Non è come con Nintendo 64 ove l'emulazione avvenne dopo due anni dalla messa sul mercato (con relativi danni economici) ;).

Io penso che non sia neanche uno dei motivi, quando emuleranno xbox 360 decentemente sarà uscito già il successore, se non il successore del successore...

...Questo anche per la diversità di architettura rispetto a quella dei PC, non pensi?

In effetti l'ho letto e a te bastava solo guardare le figure per notare che il compilatore fa guadagnare con le ottimizzazioni fino al 2600%.
Come ho già detto, la moltiplicazione dei pani e dei pesci riusciva soltanto a qualcuno... :asd:
Prima di sparare commenti a raffica fossi in te ci penserei almeno un paio di volte per evitare certe figure.
Non ti preoccupare, è un rischio che non corro: peso sempre bene le parole prima di scrivere qualcosa. Inoltre evito di scrivere su campi che non conosco: una regoletta che molta gente del forum dovrebbe imparare.

Tornando al discorso di prima, il tuo caro Cell lo puoi anche programmare in assembly ottimizzando a manina il codice: non cambierebbe di una virgola la sostanza di ciò che ho scritto.
Cell non è stato pensato per applicazioni general purpose / classiche Cell, ma per ben altro: capisco che l'affezione morbosa verso un oggetto sia una brutta besta e che faccia vedere la realtà in maniera completamente distorta, ma è bene farsene una ragione, per quanto difficile sia accettarla.

Certo, mi posso anche sbagliare, e in tal caso sarei curioso di veder una SPE emulare (perfettamente) un Commodore 64: che vuoi che sia una macchinetta a 8 bit che lavora a 1Mhz, con 1MB/s di banda, in confronto a un mostro a 64 bit, che gira a 3,2Ghz e con ben 10Gb/s di banda? Una bazzecola.
Fammi un fischio quando qualcuno ci riuscirà... :asd: Non è certo impossibile, sia chiaro... ;)

Io penso che questo sia l'ultimo dei loro problemi.
Le console utilizzano processori differenti da quelli per computer perché devono fare cose differenti ;).
Anche perché l'emulazione di console così complesse è alquanto difficoltosa, ed è praticamente impossibile che riesca ad essere fatta durante la vita commerciale di una console, vista la scarsa organizzazione e l'assenza di una qualche società che abbia interessi commerciali a compierla.
Inoltre le nuove console sono dei veri e propri mostri... quando uscì xbox essa aveva un celeron 733Mhz, che all'epoca era tutt'altro che un processore all'avanguardia, c'erano già processori di frequenza più che doppia. Ora, questo novembre avremo xbox 360, una console con tre core, ciascuno da 3,2 Ghz, roba che non si vede su nessun computer. Certo, saranno anche "in order" (ma anche il celeron dell'xbox lo è, no?) al contrario di quelli per pc "out of order", ma tre core da 3,2 Ghz sono sempre tre core da 3,2Ghz.

Il problema dell'emulazione non esiste assolutamente :).

Io parlo da profano, comunque, sono tutt'altro che un esperto in materia, se ho detto qualche castroneria fatemelo notare ;).
Completamente d'accordo: l'emulazione è l'ultimo dei pensieri per chi sviluppa una console.

P.S. La X-Box non aveva un Celeron, ma un P3 con la cache L2 dimezzata, ed era un processore out-of-order... ;)

Non è obbligatorio, possono usate anche in modo scalare. Quindi in pratica ci sono altre (oltre a quella della PPE) 8 unità intere a 64 bit.
Sì, ma le usi sempre come SIMD. Puoi fare roba come (mi sono inventato un'ISA soltanto per esporre il mio pensiero)
loadbyte r0,[r1, #offset]
coi suoi registri usati come "scalari"? Non mi pare.
Che possono operare contemporameamente sulla memoria (la loro) senza intasare il bus. Non sarà un scherzo usarle tutte insieme, ma se ci si riesce sicuramente il programma VOLA.
Mi ricorda molto le GPU, e i limiti di quest'approccio li conosciamo già. ;)
Il problema è un po' diverso rispetto ad un processore classico, perchè la SPE non vede tutta la memoria quando lavora sui dati, ma solo quella locale (limitata a 256K). Quindi l'algoritmo deve sempre lavorare in quest'ambito, e in quest'ambito le penalizzazioni di una branch mis-prediction sono molto limitate rispetta ad un processore classico.
No no: se guardi bene, una misprediction è piuttosto pesante per una SPE, pur lavorando con la sua memoria locale. Non c'è niente da fare: una SPE non è fatta per star dietro ai salti, ma per eseguire quanto più possibile codice "ordinato".
Certo, se i dati su cui deve lavorare sono fuori da questa memoria, allora il programma deve caricare la memoria necessaria e sicurmente questa è un'operazione lenta.
Questo è un altro discorso: è un problema che hanno anche i processori, quando non trovano un dato nella cache. Qui è più pesante perché c'è da programmare il DMA, e inoltre la latenza è molto più elevata, per cui la penalizzazione è molto più grande.
L'IBM si è fatta le sue statistiche e ha deciso che è più conveniente questo approccio rispetto a quello classico. Almeno nell'ambito nel quale vuole utilizzare il Cell (giochi e supercomputer? Mah!). E' la scelta filosofica del Cell spiegata molto bene nel documento introduttivo postato pochi giorni fà.

Ma sicuramente comporta una certa difficoltà nello scrivere algoritmi che non trattano stream di dati. E in molti casi probabilmente non è pratico farlo.
Pienamente d'accordo, ma è da quando sono iniziate a trapelare informazioni su Cell che ne parliamo: il Cell è stato progettato per andare fortissimo in particolari ambiti. Non in tutti. Ed è in quest'ottica che dev'essere accettata la sua architettura, con tutti i suoi limiti.
La differenza è che la cache è fuori del controllo del programmatore, che non sa che penalizzazioni ha il suo algoritmo perchè non sa e non può sapere quanti dei suoi dati in un dato momento sono nella memoria veloce (cache) o in quella lenta (Ram).
Non è così. Se vuoi, puoi avere un pieno controllo della cache, perché gli x86 (e tanti altri processori, PowerPC inclusi) hanno gli strumenti per farlo: istruzioni di gestione delle linee di cache, istruzioni di prefetch, speciali istruzioni di caricamento di dati (per indicare che tipo di utilizzo si farà della cache).
Da questo punto di vista, sono messi molto meglio di Cell. Oltre al fatto che spesso non si usano le istruzioni di prefetch, perché la logica di prefetch integrata nei processori più moderni fa un ottimo lavoro.
Sul Cell il caricamento della "cache" (memoria locale) è esplicito, quindi può ottimizzare sicuramente meglio l'accesso ai dati dei suoi algoritmi. Però anche vero che su Cell è COSTRETTO a farlo, quindi comporta un lavoro maggiore.
Hai detto bene: Cell ha solo questo modello, per cui non può che fare così.
Con Altivec, ad esempio, posso dire al processore di gestirmi il caricamento di dati fino a 4 stream (se non ricordo male).
L'unica "testimonianza" che ho letto finora è quella di Carmak, che dice che il processore dell'Xbox360 (quindi apparentemente anche la PPE del Cell) ha prestazioni pari al 50% di quelle di un x86 moderno.
Mi sembra che fek sia della stessa opinione...
Quindi direi ben più di un G4 attuale. Per molti qui, che sostengono la superiorità degli x86, più o meno come un G5 di fascia media o più.

Tremendamente scarso? Assolutamente inutilizzabile nel general-pourpose? Non direi proprio...
Posso anche sbagliarmi, ma Carmack si riferiva al suo codice: quello di un videogioco, quindi, e non quello di una generica applicazione x86. Se questo fosse confermato, direi che la situazione sarebbe tutt'altro che rosea...

Non è come con Nintendo 64 ove l'emulazione avvenne dopo due anni dalla messa sul mercato (con relativi danni economici) ;).
Pochi a dire il vero: il problema di Nintendo con l'N64 non è stato quello dell'emulazione, ma la concorrenza spietata della PlayStation che l'ha fatto fuori (cartucce e cd hanno costi di produzione LEGGERMENTE diversi... :p).

Sì, ma le usi sempre come SIMD. Puoi fare roba come (mi sono inventato un'ISA soltanto per esporre il mio pensiero)
loadbyte r0,[r1, #offset]
coi suoi registri usati come "scalari"? Non mi pare.

http://www.hwupgrade.it/forum/showpost.php?p=9285093&postcount=2191

Mi ricorda molto le GPU, e i limiti di quest'approccio li conosciamo già. ;)

Non conosco le GPU. Hanno anche gli interi?

Mi sembra che fek sia della stessa opinione...
Posso anche sbagliarmi, ma Carmack si riferiva al suo codice: quello di un videogioco, quindi, e non quello di una generica applicazione x86.

Perchè Fek l'ha provato?
Certo che Carmack si riferiva al suo codice, ma a codice non parallelizzabile o, almeno, codice che fino a oggi non non è stato necessario parallelizzare ed è difficile farlo.

Non è obbligatorio, possono usate anche in modo scalare. Quindi in pratica ci sono altre (oltre a quella della PPE) 8 unità intere a 64 bit. Che possono operare contemporameamente sulla memoria (la loro) senza intasare il bus. Non sarà un scherzo usarle tutte insieme, ma se ci si riesce sicuramente il programma VOLA.


Vola pero' solo per una classe di problemi molto ridotta, quelli perfettamente parallelizzabili. Faccio spesso questo esempio: una donna fa un bambino in 9 mesi, 9 donne non fanno un bambino in un mese solo. La stragrande maggioranza degli algoritmi non e' perfettamente parallelizzabile, o, se lo e', a costo di molto lavoro e di prestazioni inferiori. Nei calcoli general purpose, avere 8 SPE (7 nella PS3) non e' un vantaggio, ma uno svantaggio.
La legge di Ahmdal descrive questo problema:

http://parallel.vub.ac.be/documentation/pvm/Example/Marc_Ramaekers/node6.html

For over a decade prophets have voiced the contention that the organization of a single computer has reached its limits and that truly significant advances can be made only by interconnection of a multiplicity of computers in such a manner as to permit co-operative solution...The nature of this overhead (in parallelism) appears to be sequential so that it is unlikely to be amenable to parallel processing techniques. Overhead alone would then place an upper limit on throughput of five to seven times the sequential processing rate, even if the housekeeping were done in a separate processor...At any point in time it is difficult to foresee how the previous bottlenecks in a sequential computer will be effectively overcome.

Perchè Fek l'ha provato?
Certo che Carmack si riferiva al suo codice, ma a codice non parallelizzabile o, almeno, codice che fino a oggi non non è stato necessario parallelizzare ed è difficile farlo.

E tu l'hai provato per affermare il contrario? :)

Carmack fa un discorso estremamente diverso da quello che hai riportato. Lui afferma che per il codice di un gioco, non per il suo codice in particolare perche' non parallelizzabile, una CPU single core con esecuzione out-of-order fosse piu' indicata per il raggiungimento delle massime prestazioni in questo ambito, rispetto ad un processore come il Cell (ha sottointeso anche l'XCPU).
Carmack afferma questo perche' lui sa che la maggior parte del codice non e' parallelizzabile o nella maggior parte dei casi richiede enormi costi, che non valgono il risultato ottenuto.

Io non sono totalmente d'accordo con cio' che ha affermato, ma capisco che lui ha molta piu' esperienza di me (e sicuramente molta piu' di te) in questo campo, e la sua opinione va ascoltata con molta attenzione e non stravolta nei contenuti.

E tu l'hai provato per affermare il contrario? :)

Carmack fa un discorso estremamente diverso da quello che hai riportato. Lui afferma che per il codice di un gioco, non per il suo codice in particolare perche' non parallelizzabile, una CPU single core con esecuzione out-of-order fosse piu' indicata per il raggiungimento delle massime prestazioni in questo ambito, rispetto ad un processore come il Cell (ha sottointeso anche l'XCPU).
Carmack afferma questo perche' lui sa che la maggior parte del codice non e' parallelizzabile o nella maggior parte dei casi richiede enormi costi, che non valgono il risultato ottenuto.

Io non sono totalmente d'accordo con cio' che ha affermato, ma capisco che lui ha molta piu' esperienza di me (e sicuramente molta piu' di te) in questo campo, e la sua opinione va ascoltata con molta attenzione e non stravolta nei contenuti.

c'è anche da dire che produrre e progettare un solo enorme processore sarebbe molto più costoso che progettare un processore multicore. Il cell si propone anche come scelta economica. Così come l'xcpu

D'altro canto produrre giochi per architetture di questo tipo può costare parecchio, per questo sarebbe necessario un framework veramente fatto bene

c'è anche da dire che produrre e progettare un solo enorme processore sarebbe molto più costoso che progettare un processore multicore. Il cell si propone anche come scelta economica. Così come l'xcpu

D'altro canto produrre giochi per architetture di questo tipo può costare parecchio, per questo sarebbe necessario un framework veramente fatto bene

Esatto.
L'errore che si commette spesso e' considerare il Cell come una scelta di carattere prestazionale: lo progettiamo cosi' perche' sara' piu' veloce delle soluzioni attuali. Non lo e'. E' una scelta di carattere economico: date le premesse XYZ, nelle classi di problemi xyz, questa architettura sara' prestazionalmente adeguata e costa meno da progettare e produrre.

E tu l'hai provato per affermare il contrario? :)

Carmack fa un discorso estremamente diverso da quello che hai riportato. Lui afferma che per il codice di un gioco, non per il suo codice in particolare perche' non parallelizzabile, una CPU single core con esecuzione out-of-order fosse piu' indicata per il raggiungimento delle massime prestazioni in questo ambito, rispetto ad un processore come il Cell (ha sottointeso anche l'XCPU).
Carmack afferma questo perche' lui sa che la maggior parte del codice non e' parallelizzabile o nella maggior parte dei casi richiede enormi costi, che non valgono il risultato ottenuto.

Io non sono totalmente d'accordo con cio' che ha affermato, ma capisco che lui ha molta piu' esperienza di me (e sicuramente molta piu' di te) in questo campo, e la sua opinione va ascoltata con molta attenzione e non stravolta nei contenuti.

No, io non l'ho provato, appunto ho riportato l'unica fonte al mondo che pare l'abbia fatto. Beh se io (non solo io, ma molti come quelli di Microprocessor Report) stimavo che un Cell 4.6 Ghz (quello presentato all'inizio, poi per la PS3 gli hanno ridotto la frequenza) sarebbe potuto andare come un G5 odierno (2.5-2.7 Ghz), non mi sembra che l'affermazione di Carmack sia poi lontana. Anzi.

Poi non ho capito cosa ho riportato di diverso dall'affermazione di Carmack rispetto a quello che hai riportato tu... Semplicemente prima i multi-core per i giochi non esistevano e quindi era inutile sbattersi per trovare algoritmi multicore/multiprocessore. Oggi invece la strada per ottenere le migliori prestazioni è quella e quindi, volenti o nolenti, i programmatori che vogliono ottenere il massimo delle prestazioni si dovranno adeguare. Certo sicuramente è più difficile e quindi a Carmack e a molti altri da' fastidio.

Però a spremere più velocità da un singolo thread ormai erano arrivati quasi al limite e i multi-core hanno più possibilità di sviluppo. Inoltre dubito che si sarebbe potuto mettere un processore tradizionale dalla potenza superiore ad un SINGOLO core del Cell (o dell'Xbox) su una consolle. E' vero che gli x86 moderni vanno il doppio, ma consumano pure 100W e gli serve un casermone rumoroso per raffreddarli. Non il massimo per un salotto...

Vola pero' solo per una classe di problemi molto ridotta, quelli perfettamente parallelizzabili. Faccio spesso questo esempio: una donna fa un bambino in 9 mesi, 9 donne non fanno un bambino in un mese solo. La stragrande maggioranza degli algoritmi non e' perfettamente parallelizzabile, o, se lo e', a costo di molto lavoro e di prestazioni inferiori. Nei calcoli general purpose, avere 8 SPE (7 nella PS3) non e' un vantaggio, ma uno svantaggio.
La legge di Ahmdal descrive questo problema:

Però è anche vero che molte classi di problemi che sostenevi non fossero adatte al Cell, come i database server e la compilazione, con un certo sbattimento senza dubbio, invece potrebbero trarre enorme beneficio dagli 8 core del Cell. Sono infatti problemi che sono sicuramente parallelizzabili, anche se non vettorializzabili.

Però è anche vero che molte classi di problemi che sostenevi non fossero adatte al Cell, come i database server e la compilazione, con un certo sbattimento senza dubbio, invece potrebbero trarre enorme beneficio dagli 8 core del Cell. Sono infatti problemi che sono sicuramente parallelizzabili, anche se non vettorializzabili.

E' vero invece che quei problemi continuano a non essere adatti. Guarda che i documenti pubblicati hanno solo confermato ancora piu' chiaramente i limiti del Cell in questi ambiti esattamente come affermai a suo tempo.

Ora ad esempio e' chiaro che le SPE non hanno accesso diretto alla memoria (prima era in dubbio), ma devono sempre passare attraverso il DMA. Non vedo il motivo per implementare un compilatore sul Cell con enorme fatica e vederlo andare 10 volte piu' lento.

Hai letto la legge di Ahmdal che ho riportato?

E' vero invece che quei problemi continuano a non essere adatti. Guarda che i documenti pubblicati hanno solo confermato ancora piu' chiaramente i limiti del Cell in questi ambiti esattamente come affermai a suo tempo.

Ora ad esempio e' chiaro che le SPE non hanno accesso diretto alla memoria (prima era in dubbio), ma devono sempre passare attraverso il DMA. Non vedo il motivo per implementare un compilatore sul Cell con enorme fatica e vederlo andare 10 volte piu' lento.

Hai letto la legge di Ahmdal che ho riportato?

Ma, scusa, un compilatore può benissimo compilare un file del programma per core. Non è poi così difficile questo approccio al "multiprocesso". Al limite potrebbe spezzare un file di codice in più parti e parallelizzare ulteriormente. Ma non so se ci sono dipendenze, ed è comunque più macchinoso, ma il primo approccio è facile.

Così come un server database. Basta utilizzare una SPE per transazione. Non andrà più veloce per gli utilizzi singoli, ma può supportare 8 volte il numero degli utenti contemporanei...

Ma, scusa, un compilatore può benissimo compilare un file del programma per core. Non è poi così difficile questo approccio al "multiprocesso". Al limite potrebbe spezzare un file di codice in più parti e parallelizzare ulteriormente. Ma non so se ci sono dipendenze, ed è comunque più macchinoso, ma il primo approccio è facile.

Così come un server database. Basta utilizzare una SPE per transazione. Non andrà più veloce per gli utilizzi singoli, ma può supportare 8 volte il numero degli utenti contemporanei...

Se ti interessa il funzionamento di GCC su linux versione Cell, c'è un articolo qui:
http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf
"Porting the GNU tool chain to the Cell architecture." Pagina 185

Ma, scusa, un compilatore può benissimo compilare un file del programma per core. Non è poi così difficile questo approccio al "multiprocesso". Al limite potrebbe spezzare un file di codice in più parti e parallelizzare ulteriormente. Ma non so se ci sono dipendenze, ed è comunque più macchinoso, ma il primo approccio è facile.


Ci sono un po' di dipendenze fra file e file :)
E la compilazione di un singolo file e' un algoritmo inerentemente non adatto ad uno streaming processor. Tanto e' vero che per i DSP, ad esempio, i compilatori di solito vengono eseguiti su PC e poi il file oggetto e' trasferito alla macchina per essere eseguito.

Rispondi a questa domanda: perche' sbattersi per parallelizzare un algoritmo su un'architettura che non e' adatta a tale scopo per vedere ogni istanza andare venti volte piu' lenta per i limiti stessi dell'architettura in quell'ambito? Abbiamo gia' fatto questo discorso decine di volte: teoricamente puoi implementare qualunque algoritmo sul Cell, ma solo su una ristretta classe di algoritmi va veloce, sugl'altri sara' estremamente lento e inefficiente. Perche' e' stato progettato con questo scopo.

http://www.hwupgrade.it/forum/showpost.php?p=9285093&postcount=2191
Interessante. Ti riporto il pezzo che riguarda il discorso del caricamento dei dati di cui ti parlavo:
PDPC Memory Access Architecture

1) Data memory interface optimized for quadword access
- Simplified alignment network
- Always access 128b data

2) Processing scalar data
- Extracted using rotate
- Stored with read-modify-write sequence

3) Four address formats
- register + displacement, register-indexed
- PC-relative, absolute address

4) Local Store Limit Register (LSLR)
- Address mask register to define maximum address range
- Addresses wrap at LSLR range
Le cose che vengono fuori sono che l'accesso è sempre allineato (a 128 bit) e vengono prelevati 128 bit alla volta. Quindi un'istruzione come quella che ho scritto non esiste, ma è necessario "emularla" tramite ALMENO 3 istruzioni:
- una che calcola l'indirizzo di memoria (allineato a 128 bit);
- una che preleva il dato (128 bit);
- un'altra che, tramite rotate, posiziona il byte interessato nel posto giusto.

Inoltre qui stiamo parlando di memoria locale, mentre per le CPU "canoniche" l'istruzione che ho riportato prima può indirizzare un qualunque byte della memoria.

Quindi puoi già immaginare cosa succederebbe se la SPE non dovesse conoscere a priori che i dati si trovano nella sua memoria locale: dovrebbe ricorrere al DMA, e già questo risulterebbe estremamente penalizzante, per poi procedere come ho descritto sopra.

Con un "classico" processore tutto ciò non succede e il programmatore è tranquillo perché non deve pensare a nulla: fa tutto la CPU.

Ti faccio un altro esempio: un C64 ha circa 64KB di ram più altri 12KB di rom, quindi tutti i dati potrebbero stare tranquillamente nella memoria locale di una SPE. Quindi, magari sforzandosi parecchio (e dopo non so quanto tempo e sofferenze :D), un programmatore potrebbe anche riuscire a tirare fuori un emulatore C64.

Ma mettiamo il caso che voglia emulare un SEGA Megadrive (Motorola 68000) o un Super Nintendo (Western Digital 68516, "evoluzione" a 16 bit del 6502) o un altro sistema capace di indirizzare più di 256KB di ram: la SPE risulterà assolutamente inadeguata. Per un semplice motivo: non potrà far uso della sua memoria locale per accedere ai dati. Già, perché non può prevedere quali dati verranno letti: magari prendo un byte qui, una word a 16 bit da un'altra parte, una a 32 bit da tutt'altra parte, ecc. ecc. Un 386 se la caverebbe molto meglio... :p
Non conosco le GPU. Hanno anche gli interi?
Sì, ma particolarmente orientati ai calcoli tipici delle GPU (le SPE del Cell sono orientate al trattamenteo di 4 interi a 32 bit o 4 valori in virgola mobile a singola precisione).

Comunque si parlava di memoria locale e intasamento del bus: per questo ho parlato di analogie con la GPU... ;)
Perchè Fek l'ha provato?
Certo che Carmack si riferiva al suo codice, ma a codice non parallelizzabile o, almeno, codice che fino a oggi non non è stato necessario parallelizzare ed è difficile farlo.
Diciamo che è molto difficile farlo, come ti ha detto fek.

E stiamo parlando del codice di un videogioco, appunto, che sebbene attualmente non "parallelizzato", non ha certo un'esecuzione "frastagliata" come potrebbe essere quella di un emulatore (vabbé, questo forse è il caso peggiore :D), un database (pensa a una query, al fatto che deve subire un processo di parsing, e poi l'engine deve recuperare i dati che gli servono: un vero macello), un compilatore (non ti fermare alla sola lettura del sorgente: un parser dal punto di vista computazionale è molto complicato, con parecchi cambi di stato, accesso ad apposite strutture per recuperare dati e simboli, ecc. ecc.: ce n'è abbastanza per ammazzare non una, ma tutte e 8 le SPE) ecc.

No, io non l'ho provato, appunto ho riportato l'unica fonte al mondo che pare l'abbia fatto. Beh se io (non solo io, ma molti come quelli di Microprocessor Report) stimavo che un Cell 4.6 Ghz (quello presentato all'inizio, poi per la PS3 gli hanno ridotto la frequenza) sarebbe potuto andare come un G5 odierno (2.5-2.7 Ghz), non mi sembra che l'affermazione di Carmack sia poi lontana. Anzi.
L'hai detto: erano stime. Stime basati sui pochi dati conosciuti (ai tempi). Stime TROPPO ottimistiche, perché se Carmack si lamenta, avendo il prodotto IN MANO, ha le sue buone ragioni.

E stiamo sempre parlando del codice di un videogioco, per cui l'odierno G5 di cui parli letteralmente strapazza un Cell: immagina con tutto il resto del codice "general purpose". Una Waterloo preannunciata...

Lasciamo che il Cell faccia (molto bene) ciò per cui è stato concepito, ma non tiriamolo in ballo per altro...
Poi non ho capito cosa ho riportato di diverso dall'affermazione di Carmack rispetto a quello che hai riportato tu... Semplicemente prima i multi-core per i giochi non esistevano e quindi era inutile sbattersi per trovare algoritmi multicore/multiprocessore. Oggi invece la strada per ottenere le migliori prestazioni è quella e quindi, volenti o nolenti, i programmatori che vogliono ottenere il massimo delle prestazioni si dovranno adeguare. Certo sicuramente è più difficile e quindi a Carmack e a molti altri da' fastidio.
E' molto difficile, perché sono tanti gli algoritmi non "parallelizzabili": puoi metterci dentro tutti i core che vuoi, ma quella dell'emulazione di un singolo processore è un processo intrinsecamente sequenziale, ad esempio...

Ecco perché io, per quel che faccio, prediligo singole CPU molto veloci a CPU con core singolarmente più lente.
Però a spremere più velocità da un singolo thread ormai erano arrivati quasi al limite e i multi-core hanno più possibilità di sviluppo. Inoltre dubito che si sarebbe potuto mettere un processore tradizionale dalla potenza superiore ad un SINGOLO core del Cell (o dell'Xbox) su una consolle. E' vero che gli x86 moderni vanno il doppio, ma consumano pure 100W e gli serve un casermone rumoroso per raffreddarli. Non il massimo per un salotto...
Gli Athlon64 dual core mi sembrano consumino di meno e non richiedono particolari dissipatori per essere raffreddati... ;)

gli ultimi post sono interessanti... aggiungo solo due cose in modo estremamente sintetico per Criceto:
1) il problema del calcolo parallelo non è un tema nuovo, nelle architetture multiprocessore è un problema annoso: non a caso le architetture multiprocessore sono stare relegate all'uso server o workstation, dove effettivamente per via del tipo di applicazioni usate si faceva un uso intensivo della parallelizzazione (traduco: in ambito server il web server che splitta le richieste sui processori disponibili, o in ambito workstation ad esempio photoshop che fa processare pixel diversi a processori diversi - valido per mac e non per pc perchè nella versione pc si sono dimenticati i thread :D )... oggi, per via dei problemi a salire di frequenza che tutti conosciamo, con i dual core viene fuori quanto sia drammatica la questione nell'ambito desktop: solo alcune applicazioni si prestano e solo una parte di queste poi sono effettivamente concepite per lavorare in parallelo... di fatto, oggi per l'uso desktop va di più un single core a frequenza più elevata di un dual core con frequenza più bassa, non a caso AMD vende gli x2 4800+ ma anche l'fx-57. non solo: nei bench "tradizionali" il 4800+ viene battuto dal 4000+ a core singolo. per di più stiamo parlando di core con generose capacità nel general purpose, tu immaginati solo lontanamente cosa significherebbe usare le SPE del cell per qualcosa all'infuori del loro compito (che non è di certo il general purpose)... un suicidio da parte del programmatore e performance assolutamente non all'altezza. prima di usare così le SPE del cell a me viene da pensare di sfruttare la GPU, la quale dispone di numeri di picco ancora più elevati: tuttavia è sempre una forzatura. ogni parte è concepita per svolgere un compito, il general purpose lo fa la cpu, la grafica la gpu, il motore fisico e la gestione degli stream le SPE del cell. puoi anche far fare compiti diversi ai vari elementi, ma con grandi sbattimenti e pessimi risultati. pensare di far eseguire istruzioni general purpose alle spe del cell è un po' come far muovere un motore 3d alla cpu: si fa, ma con molti sbattimenti e risultati pietosi
2) non so se tu programmi, ma ti invito ad approfondire la questione nella pratica: non c'è modo migliore di rendersi conto degli ambiti in cui effettivamente puoi lavorare in parallelo e dei casini che ci sono nel farlo =)

Cosa ne pensate delle capacità di PS3 di trattare la fisica?
Io ho visto i filmati dell'acceleratore fisico della Ageia (su ageia.com) e mi sembrano molto realistici (come fisica). Non so esattamente che architettura abbia il processore della PhisX, ma mi pare sia votato al calcolo parallelo e quindi dovrebbe integrarsi bene con Cell...
Sony ha stretto un'accordo con l'Ageia per integrare il loro SDK in quello della PS3: http://ps3.ign.com/articles/635/635492p1.html

prima di usare così le SPE del cell a me viene da pensare di sfruttare la GPU, la quale dispone di numeri di picco ancora più elevati: tuttavia è sempre una forzatura.

La GPU per avere valori di picco ancora superiori e' costretta a imporre anche maggiori limitazioni al tipo di calcoli che puo' svolgere rispetto ad una SPE.

Ad esempio, per questa generazione, le GPU non sono in grado di trattare numeri interi, oppure non sono in grado di effettuare operazione di gather e scatter, oppure non sono in grado di fare una sommatoria dei valori in ingresso nello stream di dati.

La GPU per avere valori di picco ancora superiori e' costretta a imporre anche maggiori limitazioni al tipo di calcoli che puo' svolgere rispetto ad una SPE.

Ad esempio, per questa generazione, le GPU non sono in grado di trattare numeri interi, oppure non sono in grado di effettuare operazione di gather e scatter, oppure non sono in grado di fare una sommatoria dei valori in ingresso nello stream di dati.

scusami fek ma da ignorante io sapevo che i tipi di calcoli dei pixel shader erano molto diversi da quelli dei vertex shader... roba tipo interi contro virgola mobile. Qual'è la verità?

scusami fek ma da ignorante io sapevo che i tipi di calcoli dei pixel shader erano molto diversi da quelli dei vertex shader... roba tipo interi contro virgola mobile. Qual'è la verità?

Che pixel e vertex shader eseguono operazioni su vettori di floating point :)
Il modello di programmazione dei due sta convergendo fino al punto di poter oggi progettare architetture con pipeline unificate che svolgono entrambi i tipi i calcoli.

Cosa ne pensate delle capacità di PS3 di trattare la fisica?
Io ho visto i filmati dell'acceleratore fisico della Ageia (su ageia.com) e mi sembrano molto realistici (come fisica). Non so esattamente che architettura abbia il processore della PhisX, ma mi pare sia votato al calcolo parallelo e quindi dovrebbe integrarsi bene con Cell...
Sony ha stretto un'accordo con l'Ageia per integrare il loro SDK in quello della PS3: http://ps3.ign.com/articles/635/635492p1.html

di fatto le grosse potenzialità sono lì: ci possiamo infatti aspettare giochi con una migliore intelligenza artificiale (perchè comunque le nuove console sul general purpose rispetto a quelle vecchie sono ovviamente migliori, pur non essendo paragonabili a un computer), ma soprattutto con una straordinaria fisica, e sinceramente la cosa mi interessa assai =) ho scaricato il rocket dell'ageia, che contiene una serie di demo del loro motore fisico, e c'ho perso le ore affascinato... considerato poi che usavo un pc normalissimo posso dire solamente che non vedo l'ora di vedere (scusate la ripetizione) cosa può fare una console di nuova generazione o un pc con PPU =)

nota: mi sa che purtroppo rocket non si trova più sul sito dell'ageia...


fek: mi passi la tua email in pm?

Infatti tutta questa potenza di calcolo dovranno sfruttarla in qualche modo, visto che la GPU è stata inserita nella PS3 per caricarsi di un bel po' di lavoro... :p

Dimenticavo: un altro tipo di applicazione estremamente comune per cui le SPE risulterebbero inadeguate è quello della classica compressione dei dati... ;)