IBM annuncia il nuovo processore POWER6 [Archivio]

22-05-2007, 18:34

G5 faceva tutto fuorchè pena, considerando che è uscì mesi prima del A64 e per parecchio tempo fu il proprio G5 il processore più potente sul mercato.
Certo, volerlo paragonare ai recenti X2 o peggio ai Conroe ha poco senso, così come poco senso ha paragonare G4 e Centrino.
Se avesse voluto Apple avrebbe da tempo potuto passare a Cell, ma evidentemente il richiamo di Mamma Intel è stato impossibile da ignorare.
Non dimentichiamo che un Mac su Cell sarebbe dovuto essere riprogettato integralmente mentre gli attuali Mac non sono che PC uguali ad ogni altro Intel sul mercato.
Consideriamo anche che con gli attuali Core2 Apple si è liberata completamente del reparto progettazione hardware perchè Tutto l'hardware desktop viene da Cupertino (intell) e tutto quello notebook da Taiwan (Asustek)

Facendo due più due e considerando che il Software si paga a parte, pensate, ai prezzi degli attuali Mac quanto di più intascano Jobs e soci ripsetto all'epoca dei G5 :read:

queste sono le classiche considerazioni dell'utente mac appassionato che trae il suo sapere dai vari siti di rumors e dai vari blog tematici

già si coglie la vena quando si viene a vantare gli ipotetici primati del g5, che guarda caso venivano dichiarati solo su apple.com (e conseguentemente su tutti i siti orientati apple)

poi si arriva al paradosso quando si parla di un mac con sopra il cell, l'evidenza che si hanno poche idee ma confuse (non mi riferisco a te, ma alle fonti da cui hai attinto)

permettimi di fare chiarezza con l'invito a verificare quanto dico:
1) il g5 era un processore interessante se consideriamo le performance in relazione al numero di transistor, ovvero era interessante dal punto di vista del produttore (meno transitor, più processori per wafer, costi inferiori di produzione), ma paragonato agli athlon 64 (che sono usciti contestualmente, dato che i g5 annunciati a giugno sono stati effettivamente commercializzati solo mesi e mesi dopo) o anche ai pentium 4 a mille mila mhz del tempo ovviamente non era particolarmente competitivo... o meglio, il g5 era più orientato al calcolo vettoriale, e in questo eccelleva (e dava la paglia, e non poca, ai due processori x86 appena citati); gli x86 invece eccellono nel general purpose: per questo sono le cpu per eccellenza per i desktop... diciamo che i g5 erano particolarmente bravi a fare una cosa (in pratica trattare flussi video/audio, qualcosa di calcolo scientifico) e così così nel resto, mentre gli x86 non erano particolarmente bravi a fare qualcosa ma semplicemente bravi a fare tutto
2) il cell da questo punto di vista è un disastro: va incredibilmente bene laddove eccelleva il g5 ma per il general purpose è un chiodo, sarebbe come avere un pentium 3 che va 20 volte più veloce del più potente core 2 quando devi fare l'encoding/decoding di un flusso video o audio... serve solo se fai solo encoding/decoding di flussi dati (o ripeto alcuni tipi di calcolo scientifico)...
3) per il g5 ci aggiungo oltre al discorso performance (tra l'altro apple ha vantato primati inesistenti per lungo tempo, riusciva a dire che i risultati SPEC erano i migliori in assoluto quando in realtà bastava andare su spec.org per vedere che gli x86 ottenevano valori superiori del 50%) la questione performance per watt, dato che scaldava come una puttana (non a caso apple fu costretta ad impiegare il raffreddamento a liquido per tenere a bada due soli core a 2.5 ghz; non a caso non uscì mai una versione per laptop)...
4) infine aggiungo anche che se apple avesse voluto rimanere sul versante powerpc avrebbe potuto infilare nei mac dei POWER4 o dei POWER5, ma apple fa l'alternativa fintanto le fa comodo sul piano economico (e negatemi pure questa evidenza, ma con delle argomentazioni)...

insomma, il g5 è vittima del solito hype che gira intorno ad apple, sopravvalutato come tutti i prodotti attorno ai quali si crea questa sorta di alone... un buon processore, in particolar modo per il produttore, ma niente più

ShinjiIkari

22-05-2007, 18:35

Non volevo entrare nel dettaglio della questione Apple+Intel che è OT, quello che ho scritto era una risposta secca a chi ha subito detto che Apple è passata a Intel per chissa' quali complessi e segreti motivi... la verita' è che sia i G4 che i G5 erano indietro ai concorrenti x86, non davano alcuna garanzia di miglioramenti per il futuro etc... Ora che sia un'arch alternativa e bella quanto volete, ma i processori fanno abbastanza schifo; i G5 per arrivare a 2.5GHz venivano raffreddati a acqua, e vi assicuro che sul rapporto prestazioni/frequenza erano ai livelli del Pentium 4/D, non certo dell'Athlon64/x2 (ad eccezione dei benchmark Apple in cui facevano *miracoli*). Per di piu' non sarebbero mai andati sui notebook, dove c'erano ancora i G4 (tanto per ricordare di cosa parlo quando dico "G4", un processore che in codifica video prende paga da un Pentium 3 di 8 anni prima e meta' frequenza). Gli altri motivi sono ovviamente il vantaggio che c'è a farsi produrre le schede logiche da qualcun'altro e la possibilita' di far girare Windows, oltre naturalmente a godere di tutte le agevolazioni che Intel gli ha garantito in cambio di un buon ritorno di immagine e pubblicita'.

22-05-2007, 18:38

aggiungo: ibm non entra nel segmento x86 perchè non ha motivi per farlo. si dovrebbe fare un culo così e tenere dei margini di ricavo bassi perchè c'è una forte concorrenza... è molto più redditizio concentrare gli sforzi nel settore in cui opera con successo, ovvero quelle delle cpu cattive per server cattivi: non ha praticamente concorrenza e può tenere i margini di ricavo che preferisce... a questo punto, perchè sbattersi?

Lud von Pipper

22-05-2007, 18:39

noi avremmo+ concorrenza(nnfa mai male)
ecosiiprezzi deiproci si abbasserebbero ulteriormente...
purtroppo mi sa che c'è un bipolio....
amd &intel....nvidia&amd....

Perchè IBM produce il proprio hardware da sempre e pur facendo un eccellente lavoro (pensa all'epoca del PS2, (non la Pleistescion :)) ) si è resa conto che è impossibile fare concorrenza ai Taiwanesi con i prezzi che quelli tirano fuori.
Nel mercato dei grandi server, dei Mainframe e delle workstation invece il prezzo è una componente relativa se paragonata all qualità, all'assistenza e alla affidabilità e i concorrenti sono tutti made in USA (SGI, HP, Sun) con i suoi stessi problemi di personale.

diabolik1981

22-05-2007, 18:39

Lud von Pipper

22-05-2007, 19:01

queste sono le classiche considerazioni dell'utente mac appassionato che trae il suo sapere dai vari siti di rumors e dai vari blog tematici
già si coglie la vena quando si viene a vantare gli ipotetici primati del g5, che guarda caso venivano dichiarati solo su apple.com (e conseguentemente su tutti i siti orientati apple).
Guarda, puoi dirmi tutto fuorchè dell'appassionato Apple, che personalmente non reggo (soprattutto non reggo Steve Jobs e le sue sparate allucinanti) ma..
Come hai detto tu, il G5 eccelleva nel calcolo puro e magari meno in quello general purpose, il che era esattamente quello di cui apple aveva bisogno.
Il Mac G5 (quello desktop per intenderci) fu un computer High end, nato per calcolo scientifico, come workstation grafica e come encoder per video e audio.
Quando il software era ben ottimizzato i risultati si vedevano, e proprio la dove il G5 serviva, cioè con Photoshop, archicad e programmi similari tipici dell'ambiente Mac, per non parlare di Mathematica et similia.
Non ti serviva allora un G5 per fare girare Excell e i giochi non esistevano su OSX, quindi tutti contenti.
Oggi le esigenze sono diverse e sappiamo tutti che, giochi a parte, gli A64 non sono serviti a gran che negli ultimi tempi, per via della pessima implementazioni del software. I programmi erano ottimizzati per P4 e A64 non brillava al di fuori del gioco.

insomma, il g5 è vittima del solito hype che gira intorno ad apple, sopravvalutato come tutti i prodotti attorno ai quali si crea questa sorta di alone... un buon processore, in particolar modo per il produttore, ma niente più Faceva bene quello che gli era richiesto e lo stesso avrebbe fatto Cell, una volta dotato di software appropriato. Devi tener presente che il mondo Mac era molto più chiuso del mondo PC, con programmi paralleli e spesso non confrontabili, sviluppati per rendere al meglio con quel genere di hardware.

Certo, G5 scaldava, ma che mi dici di Prescott?!? :mbe:

Apple ha solo voluto ridurre il lavoro passando all'X86 in modo tale che il portingdel software fosse agevolato e in modo da ampliare il parco dello stesso per attrarre anche il Casual user, cioè quello che entra in un negozio e vuole navigare su internet.
Power4 e Power5 lasciamoli da parte che hanno costi inproponibili per desktop

Il fatto è che con la potenza di calcolo attualmente disponibile non si noterebbe gran che il vantaggio di un Cell tranne in ambiti ristrettissimi, quindi resterebbero gli svantaggi di un processore difficile da programmare.
Cell resta quindi un processore da Server, ma è utilizzato anche su PS3, che non mi sembra andare così male ora che ha preso il via, a dimostrazioni che in ambienti chiusi e proprietari fa molto bene il proprio lavoro.

Marclenders

22-05-2007, 19:09

io un'idea c'è l'avrei IBM acquisisce AMD-ATI (con cui ha molto in comune per quanto riguarda la tecnologia implementata nelle CPU vedi processo SOI) e si rimette nel settore consumer

Criceto

22-05-2007, 19:21

4) infine aggiungo anche che se apple avesse voluto rimanere sul versante powerpc avrebbe potuto infilare nei mac dei POWER4 o dei POWER5, ma apple fa l'alternativa fintanto le fa comodo sul piano economico (e negatemi pure questa evidenza, ma con delle argomentazioni)...

Bisogna vedere se IBM glieli dava... Non mi sembra sia mai successo.

I processore Power sono sempre stati strettamente IBM, i POWERPC sono nati da una joint-venture Apple-IBM-Motorola. E comunque sono processori troppo costosi da mettere in un desktop e impossibili da mettere i un notebook (il 60% del mercato Apple).

Comunque, peccato che IBM si sia messa a fare processori per giochetti e non si sia più impegnata per i processori desktop.

L'architettura Power dimostra ancora di essere tecnicamente la migliore.
E questi hanno addirittura l'Altivec!

ShinjiIkari

22-05-2007, 19:26

I Power6 hanno Altivec? Dove l'hai letto?

Lud von Pipper

22-05-2007, 19:34

I Power6 hanno Altivec? Dove l'hai letto?
non mi sembra che ce l'abbiano, anche perchè in ambito server che te ne fai oltre a sprecare energia e calore? :mbe:

22-05-2007, 19:48

L'architettura Power dimostra ancora di essere tecnicamente la migliore.

confondete braciole con patatine, come al solito; chiudiamo con un "il g5 ce l'aveva più lungo solo che non gli si slacciavano i pantaloni" prima che per l'ennesima volta ci si stracci i marroni

crespo80

22-05-2007, 20:13

io un'idea c'è l'avrei IBM acquisisce AMD-ATI (con cui ha molto in comune per quanto riguarda la tecnologia implementata nelle CPU vedi processo SOI) e si rimette nel settore consumer

Azzo, sparata lì quasi per scherzo, ma non sarebbe nemmeno troppo campato in aria...
AMD, che già di per sè è una piccola realtà se paragonata al suo diretto concorrente, e per di più in un momento delicatissimo in cui è in forte flessione per via dei nuovi Core2 di Intel, acquisisce ATI nel momento in cui anche questa è in difficoltà contro le nuove proposte Directx10 di Nvidia...
Mettiamoci che magari i nuovi K10 non saranno ancora all'altezza dei Core2 (cosa neanche troppo improbabile) e che bisognerà aspettare almeno 6 mesi per una nuova architettura ATI, ed ecco la mazzata finale e l'orlo del fallimento.

Arriva IBM e compra tutto :D

Criceto

22-05-2007, 21:03

non mi sembra che ce l'abbiano, anche perchè in ambito server che te ne fai oltre a sprecare energia e calore? :mbe:

Ce l'hanno, ce l'hanno. E' una novità dei Power6.
Evidentemente si è convinta anche IBM che Altivec è potente, ormai l'ha messo in tutti i suoi processori (Cell, Xenon, ecc). Forse all'inizio nicchiava perchè era una cosa nata da Apple/Motorola, se non ricordo male (al tempo della joint venture per i PowerPC).

Gerardo Emanuele Giorgio

22-05-2007, 21:18

come... IBM cede il settore consumer a lenovo e poi ci si rimette dentro? Un po improbabile. Non impossibile per carità, però improbabile.
Oltretutto AMD/ATI non falliranno... certamente contano piu gli accordi commerciali che la soddisfazione degli enthusiast (il 5% del mercato mondiale?) certamente è in flessione ma di li a dire che non vendono niente ce ne passa di acqua sotto i ponti.
In mia opinione IBM trae piu profitto a sviluppare tecnologie e a concederle dietro lauto compenso.
Un terzo polo sarebbe poi destinato a fallire, cioè ragioniamoci: IBM presenta un superdesktop erede del PS/2 basato su architettura POWER. Ok sulla carta da paglia e fieno a core2 e K10 ma windows non ci gira e una volta detto questo hai scoraggiato almeno l'80% degli acquirenti. Punto due: il costo. Gli IBM non sono mai andati a gratis, di solito ci devi mettere almeno il 50% in piu di un assemblato a parità di configurazione. Punto tre: che pur trovino un sistema operativo (linux? unix?) per la macchina, come si fa a convincere i programmatori ad imparare una nuova architettura oggigiorno? Ormai le cose diverse sono "difficili" (vedi CELL), i 64bit avanzano seppur lentamente solo perche nella maggior parte dei casi basta solo prendere i sorgenti e ricompilare.
Mi fermo qui perche penso che la mancanza di windows, il costo aggiuntivo iniziale e la mancanza di programmatori disposti a sviluppare software per la macchina siano piu che sufficienti a decretare la morte del fantomatico super desktop POWER6.
In realtà basterebbe solo il primo punto...

Criceto

22-05-2007, 21:30

confondete braciole con patatine, come al solito; chiudiamo con un "il g5 ce l'aveva più lungo solo che non gli si slacciavano i pantaloni" prima che per l'ennesima volta ci si stracci i marroni

A parità di sforzo progettuale, l'architettura PowerPC è sempre stata vincente, e gli attuali Power6 non fanno eccezione.

Quando escono nuovi modelli con architettura Power sono sempre molto migliori dei corrispettivi Intel. Poi però quest'ultima recupera piano piano perchè da una parte ha spesso dei processi produttivi più moderni, dall'altro aggiorna i suoi processori con una frequenza molto superiore.

L'hai notato anche tu che i G5 avevano potenza simile (dove più dove meno) ai corrispettivi Intel/AMD dell'epoca con la metà dei transistor.

Solo gli attuali CoreDuo 2, ad esempio, hanno un'unità vettoriale con una potenza paragonabile a quella dei G5 di 5 anni fà.

ArtX

22-05-2007, 23:26

anche a me i processori power mi hanno sempre affascinato, solo che al giorno d'oggi o dai un x86 o 64, cioè che ci giri windows o non si fa più niente. come prendere i soldi spesi per il progetto e buttarli via.
proci power ok, ma non ditemi che il cell andrebbe bene dai, ha soloun procio powerpc e il rest sono unità SPE per il calcolo in virgola mobile e quel processore serve per la maggior parte a gestire il traffico alle varie spe, per cui è una caccola per un desktop anche se paragonato ad un g5, ma andrebbe bene come unità di calcolo esterna magaria via bus hypertransport3.0 di amd o quella tecn di intel simile.

poi ormai secondo me windwos vista lo dovevano fare solo a 64-bit così chi aveva i 32 si teneva XP e amen, chi aveva i 64 aveva un os migliore di quello che è adesso visto che si sarebbero aumentati gli sforzi solo per i 64, e noi utenti linux stiamo bene da entrambe le parti.
azz e poi però quei piccoli ma indispensabili programmi closed source come flash ....

Lud von Pipper

22-05-2007, 23:41

Azzo, sparata lì quasi per scherzo, ma non sarebbe nemmeno troppo campato in aria...

Ma io mi chiedo che cosa aspettino a comprarsi 3DLabs e a rimetterla in sesto.

Guadavo l'altro giorno le caratterisitche delle Wildcat VP e ho imporvvisamente avuto un Dejavue (http://www.pluginz.com/news/54) rispetto alle HD2900XT di cinque anni dopo :read:

E dire che non ricevettero il bollino DX9 perchè troppo "programmabili" e poco strutturate :muro:

Crux_MM

23-05-2007, 00:12

Ma è stupendo..innovazione IBM Style..magari scendesse nella competizione desktop..ma credo che preferisca la nicchia!

OddHead88

23-05-2007, 00:21

L'architettura POWER è superiore all'x86, ecco tutto. Solo che a noi, utenti consumergeneralpurpose non interessa nulla, non è roba per ambito domenstico.
Non a caso il 970 (o G5, derivato dalla POWER4) era usato da Apple per Xserve e PowerMac, tanto costosi quanto diffusi in campo lavorativo, ma non certo domestico. Anche perchè inadeguati e scomodi, ho un iMac G5 vecchio stampo e posso dire che scalda davvero troppo. Ma perfetti per il professionale, dove non devi fare "di tutto un po'" ma poche operazioni, pesanti, ripetitive: calcoli, flussi audio, flussi video, vettoriale, eccetera eccetera eccetera...

^TiGeRShArK^

23-05-2007, 00:29

mah..
ke stupidi alla IBM..
buttare 5 anni in R&D quando avevano già il cell ke, a detta di molti qui sul forum, fa miracoli :O

:asd:

fgpx78

23-05-2007, 00:41

Bene, quindi con un piccolo investimento di un 50K€ potrò far girare Crisys? :D Ho letto che ha una cache di secondo livello di 36Gb...presumo l'articolo intendesse 36Mb vero???

myrdrwin

23-05-2007, 01:58

Dando una letta alle specifiche della AltiVec devo dire che erano un bel po avanti rispetto ad Intel e soci.
http://it.wikipedia.org/wiki/AltiVec

xeal

23-05-2007, 02:39

Cell non è solo un processore difficile da programmare, è più che altro uno stream processor, un "grosso dsp", e basta. E' buono per quel tipo di lavoro, lo svolge egregiamente, macina grandi moli di dati organizzati in flussi continui, ma non va bene in ambito desktop/general purpose, perchè non è progettato per quello. E non c'è ottimizzazione che tenga (a meno di voler impiegare mille mila millenni per rilasciare un software e fare profiling a manetta e ottimizzazioni/riscritture direttamente in assembly, con tutte le conseguenze del caso). Perchè? perchè gli x86 sono processori out-of-order, cell invece è in-order, e questo vuol dire che ogni qual volta si presenti un "problema" di salti/dipendenze/accessi alla ram cell se ne sta fermo a rigirarsi i pollici, sprecando cicli di clock, gli x86 invece, per quanto possibile (perchè miracoli divini come la creazione dell'universo non se ne possono fare), vanno avanti, colmando ogni gap prestazionale fino a ribaltarlo. Oltre tutto, storicamente gli x86 (o meglio, i CISC), rispetto ai RISC (ma qui rischiamo a entrare in empasse impelagandoci in una diatriba infinita), tendono ad essere più facili da programmare e ottimizzare, ottenendo da subito dei risultati molto validi (magari non eccelsi, ma comunque con un ottimo rapporto tra risultati e tempi di ottimizzazione del software, perchè non richiedono grandissime ottimizzazioni per andar bene - in un certo senso, l'unità out-of-order ha proprio il compito di ottimizzare al volo il codice per le esigenze del momento, oltre all'ottimizzazione generica fatta dal compilatore - mentre i risc - che poi non sono più risc puri da una vita, così come non esistono più i cisc puri - li superano sulla lunga distanza e prevalentemente in ambiti specifici, che necessitano di grande ottimizzazione).

Per quanto riguarda il discorso degli A64/cpu AMD in generale, diciamo che non brillavano troppo (anzi, ai tempi degli xp stavano anche dietro, ma tutto sommato si difendevano) con quegli applicativi fortemente ottimizzati per le istruzioni SSE, ma ho il vago presentimento che la situazione si ribalterà decisamente con i k10: le SSE sembrano essere sempre state pesantemente influenzate dal clock del processore, e qui i pentium si ritrovavano avvantaggiati rispetto agli athlon, che dal canto loro avevano un'implementazione a 64 bit (il che vuol dire che dovevano spezzare un'istruzione vettoriale da 128bit in due da 64 ed eventualmente comporre il risultato), eppure si difendevano (specialmente se non si scontravano con HT, perchè comunque i compilatori non producevano codice vettoriale "troppo" ben ottimizzato, sfruttando appieno le istruzioni su dati a 128 bit - poi ci sarebbe il discorso dei compilatori Intel che castravano il codice non destinato alle proprie cpu); ora il clock è simile, e la nuova architettura, tra le varie migliorie, ha portato l'esecuzione delle SSE da single-64bit a dual-128 bit, il che vuol dire, in teoria (nella pratica poi intervengono le contingenze dell'esecuzione, l'ottimizzazione del codice ecc.), prestazioni in virgola mobile vettoriali da 2 a 4 volte superiori alle attuali (le altre migliorie aumenteranno ulteriormente le prestazioni complessive).

xeal

23-05-2007, 03:07

@diabolik1981

la collaborazione tra amd e ibm, oltre al soi, riguarda anche la litografia a immersione che verrà usata per i 45 nm, e un materiale particolare che useranno sempre a partire dai 45nm. Non mi stupirebbe se condividessero anche il progetto di ibm per "infilare" i nanotubi di carbonio nei transistor (mi pare che si otterrebbe un cambio di stato con un solo elettrone), chiamato "distruzione costruttiva), di poco differente dalla litografia attuale (anzi, sfrutterebbe la litografia per eliminare alcuni difetti) e, quindi, con costi simili (il costo maggiore attualmente è proprio la produzione di nanotubi). Non mi stupirebbe nemmeno se un domani delle unità come le spe del cell finissero dentro alle cpu amd, accanto ai core gpu, per completare il progetto di cpu multicore con un "cuore" costituito dagli x86 di amd, le gpu ati come coprocessori gpgpu (e gpu proprie) e i coprocessori più generici che potrebbero essere di derivazione power (ma anche dei core gpu particolarmente ottimizzati come coprogessori "general purpose", se amd vorrà produrre tutto in casa).

@fgpx 78

Mi sa che hai fatto un po' di confusione... sono 8MB di cache e 300GB/s di picco come banda.

@myrdrwin

Si, ma quella descrizione si ferma alle SSE2 (siamo arrivati alle sse4), non tiene conto dell'architettura a 64 bit (i registri "ufficiali" sono raddoppiati), ed è comunque un po' imprecisa (ad esempio non dice che, comunque, si possono eseguire un'operazione sse ed una mmx contemporaneamente, con altri registri dedicati alle mmx, che comunque le cpu x86 hanno degli altri registri interni, oltre a quelli "accessibili" dal software, cioè indirizzabili attraverso le istruzioni, che servono per far girare i dati e ridurre ulteriormente gli accessi alla memoria, e che le unità vettoriali degli x86 in genere sono più di una).

Criceto

23-05-2007, 03:15

Perchè? perchè gli x86 sono processori out-of-order, cell invece è in-order, e questo vuol dire che ogni qual volta si presenti un "problema" di salti/dipendenze/accessi alla ram cell se ne sta fermo a rigirarsi i pollici, sprecando cicli di clock, gli x86 invece, per quanto possibile (perchè miracoli divini come la creazione dell'universo non se ne possono fare), vanno avanti, colmando ogni gap prestazionale fino a ribaltarlo.

Ancora con 'sta storia che il Cell è un DSP perchè è solo "in-order"?! :muro:

Sai qual'è una delle più interessanti novità del Power6 in oggetto?
E' che pare GLI ABBIANO TOLTO LA LOGICA OUT-OF-ORDER per snellirlo e farlo andare più veloce!! E nonostante questo SPACCA il :ciapet: anche all'Itanium sui calcoli interi!!! (sugli FP glie l'ha sempre spaccato, e la logica ooo pare l'abbiano mantenuta).

E' un DSP anche il Power6, ora?

xeal

23-05-2007, 08:32

Ancora con 'sta storia che il Cell è un DSP perchè è solo "in-order"?!

SI, visto che è vero... o meglio, il cell funziona meglio come dsp che come cpu general purpose, tutto qui.

Sai qual'è una delle più interessanti novità del Power6 in oggetto?
E' che pare GLI ABBIANO TOLTO LA LOGICA OUT-OF-ORDER per snellirlo e farlo andare più veloce!!

Cioè, mi stai dicendo che, non essendo un processore general purpose-desktop, ma un processore destinato a calcoli scientifici intensivi e specifici (ad esempio, calcoli matriciali, che come ben saprai, suppongo, come "tipologia" di accesso ai dati e loro elaborazione sono molto simili ai flussi audio/video nei quali il Cell SPACCA, essendo tipologie di calcolo che calzano a pennello ad un dsp, cui il cell è molto simile - per elaborare matrici, ad esempio per moltiplicarle, devi accedere ad una mole di dati notevole, che però non sono sparsi in memoria, ma contigui, formando, appunto, una matrice, ossia una specie di "grosso array", per poi effettuare un bel po' di calcoli pesanti, ma su un flusso continuo di dati, e la codifica di dati audio/video non fa altro che processare un flusso continuo di dati), non ha bisogno di una delle caratteristiche principali del calcolo general purpose-desktop, cioè dell'esecuzione fuori ordine, che però non ti serve a niente se devi eseguire dei compiti molto specifici e superottimizzati, e quindi se la togli, in tutti quei casi in cui non ti serve, guadagni anche qualche ciclo di clock? :D ;)

Forse però ti sfugge un po' il significato "vero" di dsp, e la potenza che serve ad un dsp, visto che ne parli quasi come se fosse un' "offesa", uno spregiativo che ti fa incavolare se lo si "affibia" a un processore che ti piace... un dsp non è altro che un processore progettato ed ottimizzato per elaborare molto efficientemente grosse moli di dati continui, "vettorializzati", tipicamente in realtime - come fa il cell con le sue notevoli capacità nel decoding di più streaming audio/video in alta definizione contemporaneamente, che talvolta può avere un'architettura particolare (detta di Harvard), diversa dallo schema della macchina von Neumann, ovvero può usare due memorie separate, una per i dati e una per le istruzioni, e vi accede separatamente, ma non è una caratteristica "vincolante" di un dsp; in questo senso (è una piccola curiosità), le unità vettoriali (o SIMD che dir si voglia - Single Instruction Multiple Data, una singola istruzione elabora un vettore di dati), come AltiVec, MMX, SSE, PowerNow (l'equivalente - e concorrente, prima delle sse - delle MMX di AMD), non fanno altro che aggiungere delle caratteristiche diciamo "simil dsp" a processori che dsp, per natura, non sono (un esempio di dsp "puro" è l'enligth 256, progettato da una società israeliana di cui non ricordo il nome con una tecnologia futuristica - è un processore "ottico", usa dei laser e delle lenti per effettuare i calcoli, e ha una potenza di calcolo notevole - ed è praticamente in grado di svolgere solo calcoli vettoriali - tipo una moltiplicazione righe per colonne di due matrici "al volo", anzi, operando su dati di 8bit, moltiplica una matrice 256x256 per un vettore con 256 elementi 125 milioni di volte al secondo... se dici ai progettisti che l'essere un dsp è una brutta cosa ti scorticano vivo :D). Ora, l'estrema ottimizzazione per compiti specifici di un dsp, porta inevitabilmente al "sacrificio" di altre caratteristiche che lo renderebbero adatto ad altri ambiti (così come un x86, essendo fortemente orientato al general purpose e non essendo specializzato per gli stessi compiti, cioè avendo unità meno efficienti per quelle elaborazioni, non può competere con il cell nella decodifica di 48 flussi video in alta definizione); questo non significa che il cell non possa eseguire bene una applicazione general purpose, o che diventi di colpo "lento", vuol dire semplicemente che, non avendo un'unità out-of-order, in tutta una serie di situazioni, non può sfruttare appieno la sua potenza di calcolo. Semplicemente, sono processori progettati per compiti diversi; in un certo senso, è come confrontare un tir e una ferrari monoposto: il tir non andrà mai come la ferrari in pista, ma la ferrari non può trainare quattro rimorchi ;)

E nonostante questo SPACCA il :ciapet: anche all'Itanium sui calcoli interi!!!

Occhio che hai preso un'altro processore RIGOROSAMENTE IN-ORDER!!! E che vorrebbe sopperire alla mancanza dell'unità per il riordino delle istruzioni con dei compilatori eccellenti (che però non possono fare miracoli), con un numero enorme di registri (che però aumentano le latenze, e danno anche un po' fastidio, come numero, a chi i compilatori li scrive, cercando di spremere al massimo un'architettura) e con una parallelizzazione estrema (addirittura, per evitare problemi con i salti condizionati, puoi eseguire due "varianti" di un calcolo per poi validare la condizione e scartare il risultato sbagliato - ad esempio, hai la condizione "se x > 0 fai questo altrimenti fai quest'altro", il processore fa contemporaneamente "questo" e "quest'altro" e alla fine decide qual'è il risultato giusto). In ogni caso, Itanium è una belva con i calcoli in virgola mobile, mentre negli interi non ha mai eccelso, perchè 2 delle 4 alu vengono usate anche per le operazioni di load/store (cioè per prelevare dati dalla ram e scriverci i risultati - a titolo di confronto, un opteron, al pari degli athlon, ha 3 alu che fanno solo cacloli interi, più 3 agu che calcolano gli indirizzi per l'accesso in memoria), e alla fine i programmatori preferiscono usarle prevalentemente per le operazioni logiche, trasformando le operazioni aritmetiche su interi in operazioni a virgola mobile per sfruttare la velocità dell'FPU (la quale è si molto veloce, ma non quanto un'alu dedicata, anche perchè va a svolgere delle operazioni complesse, ad esempio un'addizione e una moltiplicazione contemporaneamente, e quindi impiega più tempo di un'alu nel compiere solo un'addizione intera).

E poi, cosa c'entra l'essere in-order oppure out-of-order con la velocità "pura" nel calcolo intero, o in virgola mobile, che poi è quello che misuri con benchmark come SPEC (cioè la potenza bruta, "pura" )? Mica l'essere out-of-order può aumentare la velocità del processore! Semplicemente, e scusa se è poco, lo aiuta a sfruttarla meglio. Ti faccio un esempio semplice: supponi di dover fare una certa operazione, e di non avere a disposizione i dati da elaborare nè nei registri, nè nella cache, dovrai accedere alla ram, che però è molto più lenta del processore. Ecco: un processore IN-ORDER, che, come dice il nome, esegue le istruzioni nello stesso ordine in cui si presentano, smetterà di eseguire i calcoli per attendere i dati dalla memoria, e finchè non arrivano non farà nient'altro, perdendo dei cicli preziosi (per la decodifica video e molti calcoli scientifici pesanti, che fanno uso abbondandte di matrici/vettori, è diverso, perchè prelevi dalla memoria un cospicuo blocco di dati, lo elabori, e poi torni in memoria per copiare i risultati e prelevare il blocco successivo da elaborare, ma difficilmente dovrai tornarci nel bel mezzo dell'elaborazione, cosa che invece molto probabilmente accadrà con un'applicazione "generica" ); un processore OUT-OF-ORDER, invece, non ha bisogno di aspettare, perchè, come dice il nome, esegue le istruzioni fuori ordine, le riorganizza ed esegue quelle che non dipendono dall'operazione "bloccata" in attesa che arrivino i dati dalla memoria e anche quell'istruzione possa andare avanti, recuperando tempo prezioso. E poichè i processori x86 attuali hanno una logica out-of-order, sono di conseguenza più indicati dei processori in-order per il general purpose, nel senso che una generica applicazione che accede alla memoria in modo "sparso" e può avere molti salti difficilmente provocherà dei grossi rallentamenti (mentre un processore in-order, anche quando dotato di una maggiore potenza bruta, verrebbe rallentato, e quindi non sfrutterebbe a dovere la sua potenza).

(sugli FP glie l'ha sempre spaccato, e la logica ooo pare l'abbiano mantenuta).

Cosa? come? quando? dove? perchè? :confused:

Ma di che stiamo parlando adesso? Del Power6? ma non dicevi che gliel'hanno tolta? Di Itanium? ma guarda che non l'ha mai avuta... neanche nella primissima versione, che effettuava una specie di riordino, ma ben diverso (la rotazione dei registri... a rotazione, appunto, e la effettuava perdendo dei cicli di calcolo - in realtà c'è ancora, essendo una delle caratteristiche principali della sua architettura, ma in Itanium 2 il problema è stato risolto, ottimizzando il tutto, però è qualcosa che nulla ha a che spartire con la logica ooo). A meno che non mi sia perso qualcosa e l'abbiano aggiunta di recente (in Itanium), ma non mi risulta :boh:

E' un DSP anche il Power6, ora?

E' un processore per usi molto specifici, per calcoli scientifici particolari e mooolto pesanti (per capirci un po' meglio, certi calcoli sulla statica degli edifici, o certe simulazioni di fisica, possono richiedere l'elaborazione di matrici di ordine 1000 o superiore... - e ripeto che le unità SIMD aggiungono agli x86 di oggi delle funzionalità da dsp, quindi non è sbagliato dire che gli x86 siano diventati "un po' dsp"; oltretutto, se consideriamo la gestione della memoria cache di primo livello, divisa in una parte dati e una istruzioni, non seguono neanche più perfettamente lo schema di von Neumann, ma questa è una sottigliezza). Forse IBM l'ha presentato dicendo che serve per navigare meglio su Internet?? ;)

NOTA a margine: ribadisco, dire che Cell, o in generale un processore privo di logica out-of-order, e di altri accorgimenti per "mascherare" frequenti accessi alla memoria (come i "trucchi" implementati in una gpu), ha prevalentemente un comportamento da dsp non vuol dire sminuirne la potenza, ma rendersi conto che si tratta di un processore molto specifico, che andrà da dio nei campi (limitati) per i quali è stato progettato, ma sarà meno efficiente nel general purpose (a parte il fatto che stiamo parlando di processori la cui potenza sarebbe ampiamente sottosfruttata in ambito desktop anche con una logica ooo, comunque, non avendola, verrebbero sfruttati ancora peggio; magari, data la potenza bruta non te ne accorgeresti, però resta il fatto che, a livello di architettura interna, non sono adatti allo scopo, e non vale la pena usarli, tutto qui). Poi, guarda che non basta togliere la logica ooo per trasformare una cpu in un (buon) dsp :p

23-05-2007, 10:11

ho come l'impressione che tu stia dando perle ai porci, non solo non danno retta, ma per di più leggono quello che vogliono

23-05-2007, 10:39

Tanto per farsi un'idea di cosa si sta parlando...

http://tweakers.net/ext/i.dsp/1066381706.jpg

http://www.hardware.info/images/news/ibm_power_6_550.jpg

linuxianoxcaso

23-05-2007, 10:42

che cosuccia sfiziosa :flower:

23-05-2007, 11:45

in realtà quelle due foto dovrebbero riferirsi al power5 con 4 die dual core e 36 mb di cache

Sp4rr0W

23-05-2007, 11:58

Se non ci fosse IBM ad innovare... CPU e HD sono da sempre gioielli!

guarda che la divisione HD è di HITACHI da un bel po'di tempo :D

Criceto

23-05-2007, 12:30

Cioè, mi stai dicendo che, non essendo un processore general purpose-desktop, ma un processore destinato a calcoli scientifici intensivi e specifici (ad esempio, calcoli matriciali, che come ben saprai, suppongo, come "tipologia" di accesso ai dati e loro elaborazione sono molto simili ai flussi audio/video nei quali il Cell SPACCA, essendo tipologie di calcolo che calzano a pennello ad un dsp, cui il cell è molto simile - per elaborare matrici, ad esempio per moltiplicarle, devi accedere ad una mole di dati notevole, che però non sono sparsi in memoria, ma contigui, formando, appunto, una matrice, ossia una specie di "grosso array", per poi effettuare un bel po' di calcoli pesanti, ma su un flusso continuo di dati, e la codifica di dati audio/video non fa altro che processare un flusso continuo di dati), non ha bisogno di una delle caratteristiche principali del calcolo general purpose-desktop, cioè dell'esecuzione fuori ordine, che però non ti serve a niente se devi eseguire dei compiti molto specifici e superottimizzati, e quindi se la togli, in tutti quei casi in cui non ti serve, guadagni anche qualche ciclo di clock? :D ;)

Guarda che i Power sono utilizzati in server e mainframe. Utilizzo opposto dei Cell. Non esistono supercomputer scientifici con processori Power per calcolo scientifico, pur avendo sempre avuto le unità FP più potenti in assoluto.

Sono stati utilizzati invece processori con Core PowerPC più semplici (i PPC 970 o addirittura, per il supercomputer più potente del mondo, dei processori derivati dai processori embedded, sempre con core PowerPC).

Quindi, i Power vengono utilizzati proprio per quello che secondo il tuo modo di pensare OBBLIGHEREBBE il processore ad essere OOO. Tecnologia, tra l'altro, introdotta nei processori proprio da IBM con la il primo processore della serie Power.

Semplicemente l'OOO non è la panacea. Può essere vantaggioso oppure no. Una volta per IBM lo era, ora non più visto i suoi ultimi core, Power6 INCLUSO.

Questo dimostra che il fatto che il Core PPC del Cell non abbia l'OOO è stata una scelta progettuale ben precisa, perchè escludendolo evidentemente portava ad altri vantaggi (semplicità -> maggiore frequenza). Bada che i Cell dall PS3 sono a 90 nm, e girano più piano di quanto potrebbero per motivi di consumo. Pare che i Cell a 65nm possano tranquillamente superare i 5Ghz!!

Quindi DSP una cippa!
Il Cell è un processore general pourpose ottimizzato per flussi digitali. Per il "digital entertainment". Ma sempre GENERAL POURPOSE rimane.

Scommetto che presto o tardi faranno un "SuperCell" con un Core Power6 e 4-8 SPU ottimizzate per il calcolo FP a doppia precisione. Allora sì ne vedremo delle belle!!!

Occhio che hai preso un'altro processore RIGOROSAMENTE IN-ORDER!!!

Avevo preso l'Itanium perchè era quello che una volta era il più potente sui calcoli interi. Anche se adesso in effetti i processori Core credo siano più potenti. Ma con in processori Core il discorso non cambia. Il Power6 rimane sempre signifiticamente più potente sugli interi (e quindi sul "general pourpose") quando storicamente non sempre è stato così. E questo, sembra, SENZA UNITA' OOO, e senza approcci "esotici" come l'VLIW dell'Itanium.

E poi, cosa c'entra l'essere in-order oppure out-of-order con la velocità "pura" nel calcolo intero, o in virgola mobile, che poi è quello che misuri con benchmark come SPEC (cioè la potenza bruta, "pura" )? Mica l'essere out-of-order può aumentare la velocità del processore! Semplicemente, e scusa se è poco, lo aiuta a sfruttarla meglio.

Gli SPEC non misurano la "potenza bruta". O di picco, se preferisci.
Sono benchmark abbastanza vari per includere tutti gli utilizzi. E tra l'altro, mi sembra, mono-thread. Gli Intel sono sempre stati particolarmente forti sugli "Spec-Int" e quindi sul general pourpose.

... E poichè i processori x86 attuali hanno una logica out-of-order, sono di conseguenza più indicati dei processori in-order per il general purpose, nel senso che una generica applicazione che accede alla memoria in modo "sparso" e può avere molti salti difficilmente provocherà dei grossi rallentamenti (mentre un processore in-order, anche quando dotato di una maggiore potenza bruta, verrebbe rallentato, e quindi non sfrutterebbe a dovere la sua potenza).

Ecco, appunto, rivedi la tua logica. I Power6 senza OOO distruggono gli Intel ANCHE sul general pourpose!!!

^TiGeRShArK^

23-05-2007, 23:40

Scommetto che presto o tardi faranno un "SuperCell" con un Core Power6 e 4-8 SPU ottimizzate per il calcolo FP a doppia precisione. Allora sì ne vedremo delle belle!!!
Ecco bravo..
e allora perchè hanno buttato 5 anni in R&D anzikè fare uscire subito il "super cell" ke a tuo dire avrebbe dato la pappa anke al power 6? :p
forse perchè cell e power 6 sono 2 processori incomparabili e il cell non potrà mai avere le prestazioni che ha il power 6 nei suoi ambiti di utilizzo? :p
mah..
a leggere certi commenti sembra che gli ingegneri IBM siano tutti idioti :asd:
ma mandategli un curriculum anzikè sprecare energie a postare sul forum dato ke da quello ke scrivete sembra quasi ke voi ne sappiate + di loro :p

xeal

24-05-2007, 10:25

Chiariamo un paio di punti:

1) general purpose NON è un sinonimo stretto di calcoli interi, benchè molte delle applicazioni che vengono considerate "general purpose", come ad esempio le suite da ufficio, facciano prevalentemente o esclusivamente uso di calcoli interi. Ad esempio, nel benchmark SPEC CPUInt2006 uno dei test effettuati sul calcolo intero riguarda la codifica video in h.264, e l'encoding video, lo ripeto di nuovo così forse ce lo ricordiamo meglio, è un tipico campo di utilizzo dei dsp, ma non è certo l'unico in cui si hanno elaborazioni "da dsp" che si effettuano su interi: molti calcoli complessi (compresa la trasformata di fourier) si risolvono con metodi numerici, ovvero trasformando le formule complicate (o meglio, pesanti da calcolare in virgola mobile) con cui si ha a che fare in serie numeriche, riconducendosi ad un insieme di somme e moltiplicazioni possibilmente su valori discreti (interi), con pochi salti e operando su dati "sequenziali" (fondamentalmente stiamo parlando di elaborazione numerica di segnali, ma non solo). Ripetiamo, così forse ci entra in testa: intero non vuol dire necessariamente general purpose, amen! (anzi, adesso aggiungo qualcosa che forse ti sconvolgerà: la maggior parte dei dsp tratta SOLO interi...).

2) Che Itanium sia mai stato il processore più veloce in assoluto sugli interi, forse l'hai sognato: purtroppo i risultati con spec2000 sono stati ritirati dal sito, ma mi bastano quelli con spec 2006 (che oltretutto sono più complicati) per mostrarti come, ad esempio, nei test sulla pura velocità (speed test), le migliori configurazioni con gli Opteron se la giochino con le migliori configurazioni di Itanium 2, e a volte stanno davanti, specialmente nella versione "base" dei test (senza le ottimizzazioni di compilazione concesse nella variante che misura i valori di picco) e con molta meno ram (sul sito dei test si dichiara che i test sono volutamente dipendenti dalla ram, per valutare le prestazioni complessive del sistema, anche se non si tiene conto del sottosistema di IO), e se la giocano ancora, ma stavolta stanno praticamente sempre davanti, anche nel picco, a parità di numero di core nel sistema, anche nella variante del test sugli interi che misura il throughput di sistema, e ancora con meno ram (piccola nota: i test spec non sono di per sè multithreaded, non producono cioè thread, ma nemmeno li vietano, perchè alcuni/molti degli algoritmi impiegati si prestano ad una buona parallelizzazione automatica ad opera di compilatori speciali, pertanto, se per il tuo sistema possiedi un simile compilatore, puoi sfruttare più di un core e ottenere ancora un risultato valido per lo speed test; per il throughput di sistema si fanno girare più copie (task) dei test, in un numero arbitrario che va indicato, tipicamente una per ogni processore). Ma forse tu ti riferivi a quanto affermato all'inizio della press release di ibm, cioè alla superiore velocità (fino a 3 volte o più) rispetto al Superdrome HP, che è un sistema con 128 core di Itanium 2; tuttavia quel risultato è ottenuto dividendo per il numero di core presenti nel sistema il risultato di un altro test (nel quale, comunqu, il risultato più alto raggiunto rimane quello di Itanium, e vorrei vedere con 64 cpu dual core contro 16 dual core...), il TPC-C, che però io prenderei un po' con le molle nell'interpretarlo: misura i risultati ottenuti da sistemi eterogenei (quanto a tipologia e numero di processori, ram, ecc. ma lo fa anche spec, e in entrambi i test vengono indicate le configurazioni) messi sotto stress da pesanti transazioni su database, usando però database diversi (che vengono indicati, ma bisogna anche tenere conto della diversità degli algoritmi per valutare i risultati), e ho visto solo Itanium e power a confronto (in verità c'erano un paio di xeon, ma non ho visto nessun opteron, ed è un peccato, perchè macinano bene i database e il confronto sarebbe più completo, ma dipenderà dalla "buona volontà" di qualcuno nel testare anche sistemi con opteron, come acade con spec). Poi, non capisco perchè insisti nel vantare l'assenza della logica ooo come fosse importante nell'aver ottenuto un risultato migliore rispetto a quello di un'altra architettura senza logica ooo: non stai dimostrando che la logica ooo non sia importante nel "general purpose" (che ripeto ancora, non si riduce al calcolo intero, così come calcolo intero non equivale strettamente a general purpose), ma solo che un'architettura senza ooo può essere migliore di un'altra architettura senza ooo nei calcoli interi, e questo a patto di assumere per vera la tua affermazione sull'assenza di logica ooo nel power6...

3) Assenza che attualmente è sospetta ma non ancora nota per quanto riguarda gli interi (mancano i dettagli tecnici sull'architettura del power6), mentre si sa già (da tempo) che per quanto riguarda l'fpu la logica ooo è stata mantenuta... Quindi il tuo "SuperCell" con un cuore Power6 non sarebbe più un processore totalmente privo di logica out-of-order. Comunque, mi sapresti dare un link (ma mi va bene anche il titolo di un libro) ad una descrizione tecnica dettagliata del perchè e del come la logica ooo aggiunga una complessità tale da impedire od ostacolare l'aumento della frequenza di una cpu? La logica ooo opera principalmente sullo scheduler delle istruzioni da dare in pasto all'alu (o all'fpu), e prima di eseguire i calcoli. Il problema principale nell'aumentare il clock è la profondità delle pipeline: poichè ogni stadio dura un ciclo di clock, se voglio aumentare il clock devo rendere le operazioni in ogni stadio più veloci, e in genere il modo più semplice di farlo consiste nell'aumentare il numero di stadi; tuttavia, nel Power6 la profondità delle pipeline non è stata variata, mentre la frequenza è stata notevolmente incrementata, quindi è possibile che sia stata toccata anche, però questo non mi convince molto (ma naturalmente posso sbagliare), sia perchè la presentazione parla di un miglior parallelismo delle istruzioni nelle pipeline, e questo implica la necessità di un certo grado di riordino delle operazioni, per portare avanti (e quindi eseguire senza tener conto dell'ordine originario) le istruzioni che non presentano dipendenze (altrimenti rischi di bloccare una pipeline con delle istruzioni che non possono raggiungere lo stadio successivo perchè non possono accedere alle risorse necessarie), sia anche perchè un'architettura di derivazione Power ad elevata frequenza e in-order in casa IBM c'è già: si chiama Cell e ha delle pipeline più profonde del Power6, quindi ho il sospetto che il vero salto di qualità lo facciano altre migliorie, e la "complessità" della logica ooo potrebbe essere stata mantenuta, almeno in parte.

4) Quando affermi che:
Quindi, i Power vengono utilizzati proprio per quello che secondo il tuo modo di pensare OBBLIGHEREBBE il processore ad essere OOO.

ti contraddici affermando subito dopo che:
Tecnologia, tra l'altro, introdotta nei processori proprio da IBM con la il primo processore della serie Power.

Se IBM ha introdotto la logica ooo per i campi nei quali io sostengo che sia necessaria, allora forse in quei campi è utile. Poi, non ho mai detto che sia OBBLIGATORIO avere la logica ooo, che non è la panacea perchè non esistono panacee, ma è qualcosa in più, che aggiunge un ulteriore livello di ottimizzazione (limitatamente all'ordine di esecuzione) a del codice generato da un compilatore già con un buon livello di ottimizzazione (sempre per l'ordine di esecuzione); un processore privo di logica ooo può avere altre caratteristiche che sopperiscano alla sua mancanza e andare bene anche nel "general purpose" (dove per general purpose intendo l'esecuzione di applicazioni "generiche" con un comportamento "generico", ossia non particolarmente "specializzate", con algoritmi non particolarmente ottimizzati, con molti salti, e con una gestione dei dati in memoria non particolarmente efficiente - dal punto di vista della fluidità di esecuzione da parte della cpu); però io sono (e resto) dell'idea che la presenza della logica ooo sia estremamente utile per sfruttare fino in fondo la potenza di un processore con applicazioni "medie", ottenendo da subito, senza il bisogno di grosse ottimizzazioni nel software, delle prestazioni "mediamente buone", anche senza eccellere in casi specifici (a meno che il processore non sia progettato anche per scopi particolari). In questo senso, NON esiste un processore che sia general purpose in contrapposizione a un dsp non general purpose, così come NON esiste un dsp che, entro certi limiti, non sia general purpose (ad eccezione di alcuni dsp che sono in grado di svolgere solo delle particolari e limitatissime funzioni; ma stai tranquillo che anche su EnLight 256, che è un dsp PURO, il modo di farci girare un word processor lo trovi...); però esistono processori prevalentemente inclini all'uno o all'altro scopo, e quindi le prestazioni sono diverse. E la logica ooo è una caratteristica che ti aiuta molto nel general purpose. Aggiungo un'altra cosa: un ipotetico processore che possa accedere alla ram ad una velocità e con delle latenze paragonabili ai registri interni (o almeno alla cache) non avrebbe bisogno nè di cache, nè di ooo execution (entro certi limiti, perchè comunque devi riordinare le istruzioni se vuoi sfruttare pienamente più di una pipeline, e devi reagire in fretta in caso di salti non previsti); guardacaso il Power6 ha una cache L2 da 8MB più una L3 fino a 32MB, ben 2 controller per la memoria e una banda a dir poco SPAVENTOSA, però ha mantenuto la logica ooo nell'fpu (e non è certo che sia stata rimossa nelle pipeline delle alu).

5) VLIW è tutto fuorchè un approccio "esotico": è semplicemente una delle tante architetture RISC, e neanche recentissima, con un formato istruzione a lunghezza fissa (caratteristica rigorosamente RISC) e istruzioni di lunghezza "notevole", che consentono un maggior numero di istruzioni (caratteristica un po' meno risc, per definizione) e, soprattutto, di gestire un numero elevato di registri interni (caratteristica peculiare di Itanium).

6) Un processore ottimizzato per i flussi digitali è, per definizione, un DSP! Le SPE di Cell sono dei veri e propri "floating point dsp ", che eseguono operazioni vettoriali prevalentemente su interi (ricordi le elaborazioni numeriche di cui parlavo al punto 1? ecco, è il campo di applicazione più tipico dei dsp) e su dati in virgola mobile in singola precisione (a 32 bit, altra esigenza tipo di un dsp per usi "particolari" ) e sono in order; sono capaci anche di calcoli in doppia precisione (i dati double, per capirci), ma con delle limitazioni notevoli e un notevole calo prestazionale (diventano fino a 4 volte più lente; del resto, il ricorso ai double è già raro in software (molto) ottimizzato, se non è strettamente necessario, e praticamente inesistente negli algoritmi da dsp); non possono funzionare da sole ma devono essere pilotate dall'unità PPE. Questa è l'unica parte veramente general purpose di un Cell, anche se è in-order, ma non potrebbe essere altrimenti, perchè è moooooolto castrata: ha due alu, ma è multithreaded, quindi ciascun thread in esecuzione può sfruttare solo un'alu, ad esso dedicata; ha un'unità altivec, ma anche questa è "striminzita", e, al pari delle SPE, è lenta con i double; in pratica è buono solo perchè ha caratteristiche tali da far girare un sistema operativo tradizionale (le spe non potrebbero), e per smistare il lavoro alle SPE; per il resto, sarebbe probabilmente surclassata anche da un G4, che ha più unità elaborative, più potenti e le gestisce al meglio perchè out-of-order (ma la ppe di un Cell non ha unità di calcolo "sufficienti" a giustificarne una gestione ooo; comunque, le prestazioni complessive risentono inevitabilmente dalla bontà del compilatore). In una serie di test, IBM ha mostrato come si riesca a sfruttare a fondo la potenza di calcolo parallelo di un Cell con delle moltiplicazioni matriciali ottimizzate (devo ripetere che anche questo è un campo di applicazione di un dsp? ); inoltre, ha intenzione di utilizzarlo come coprocessore matematico abbinandolo ad altre cpu veramente general purpose, della famiglia power ma non solo: probabilmente impiegherà anche degli intel e degli amd (presumibilmente in base alle esigenze/richieste del cliente), quindi tanto general purpose non lo definirei... Ti suggerirei di approfondire l'argomento con questi articoli da arstechnica: 1 (http://arstechnica.com/articles/paedia/cpu/cell-1.ars) e 2 (http://arstechnica.com/articles/paedia/cpu/cell-2.ars), più questa news (http://arstechnica.com/news.ars/post/20070427-ibm-announces-cell-based-gameframe-system-for-hosting-virtual-worlds.html), e di leggere l'articolo su wikipedia (http://en.wikipedia.org/wiki/Cell_microprocessor).

In ogni caso, avevo anche detto che le unità SIMD aggiungono funzionalità da dsp anche agli x86, personalmente non considero un'offesa pensare che un pezzo del processore che sta dentro al mio case è un dsp, non capisco perchè ti dia tanto fastidio chiamare cell dsp (che è una definizione riduttiva per certi versi, ma più calzante rispetto a general purpose, fosse solo perchè un "general purpose" qualsiasi non è capace delle prestazioni di un Cell come dsp, ma il rovescio della medaglia è che un Cell non può mantenere le stesse ottime prestazioni nel "general purpose" ). Forse nutrivi qualche speranza che Apple cambiasse idea, facesse marcia indietro e tornasse ad usare qualcosa di "different" e più potente (nei sogni dei suoi aficionados)? Be', mi dispiace deluderti, ma ti devi rassegnare... E comunque, che Cell si comporti prevalentemente come un dsp è un dato di fatto, le caratteristiche tecniche e i test condotti sull'encoding audio/video e sul calcolo matriciale "pesante" lo dimostrano e confermano oltre ogni ragionevole dubbio. Amen.

Comunque, ho come l'impressione che tu abbia le idee un po' confuse sull'architettura di un calcolatore e su certe definizioni, quindi, prima di suggerire a qualcun altro di cambiare il proprio modo di pensare (e dirti le cose come stanno) solo perchè non si conforma al tuo (e non coincide con le tue conclusioni, lasciatelo dire, per lo più campate in aria), ti pregherei vivamente di approfondire gli argomenti a te sconosciuti o poco noti, magari studiando un buon libro, anche elementare (ci sono dei testi universitari molto molto semplici che trattano architetture di cpu "inventate" allo scopo, di tipo risc-like e molto semplificate, che forse ti chiariranno qualche dubbio, e ti daranno le basi per approfondire il concetto di pipelining, di cpu superscalare, di branch prediction e amenità simili, trovi molto materiale anche su internet, a patto di voler approfondire con nozioni tecniche serie e senza fermarti a qualche informazione superficiale e parziale, se non di parte, che potresti trovare, ad esempio, in qualche discussione di Apple fanboy o similare, e che magari potrebbe piacerti, ma non essere vera).

Criceto

24-05-2007, 12:27

Comunque, mi sapresti dare un link (ma mi va bene anche il titolo di un libro) ad una descrizione tecnica dettagliata del perchè e del come la logica ooo aggiunga una complessità tale da impedire od ostacolare l'aumento della frequenza di una cpu?

Risposta troppo lunga! ;)
La leggerò tutta quando avrò un po' di tempo.
Per quanto rigurda il punto quotato, era stato esplicitamente menzionato da uno dei progettisti del Cell, quando ne spiegava le scelte progettuali. Puoi trovare l'articolo sul sito IBM. Sorry non ho il link, ma ti ho detto dove cercare.

Criceto

24-05-2007, 13:02

6) Un processore ottimizzato per i flussi digitali è, per definizione, un DSP! Le SPE di Cell sono dei veri e propri "floating point dsp ", che eseguono operazioni vettoriali prevalentemente su interi

E comuqnue quello che sembra avere le idee molto ma MOOOOLTO confuse sulle architetture dei processori e del Cell in particolare sembri essere tu. A parte le castronerie, ti sei anche riuscito a contraddire in mezza frase!!!

xeal

24-05-2007, 19:53

No, guarda, hanno ragione gli altri a sostenere che leggi e capisci quello che ti fa comodo :rolleyes:

Forse ho espresso il concetto con una frase un po' complessa, però mi rifiuto di credere che tu non sia in grado di cogliere il significato di quello che ho scritto, andando oltre le parti tra parentesi, che volevano essere dei chiarimenti, e capendo che la frase non finiva li, quindi la parte che hai citato l'hai troncata apposta dove ti faceva comodo...

Posto che un dsp senza troppe pretese, o dimensionato per calcolare elaborazioni numeriche mooolto ottimizzate per essere veloci e al tempo stesso precise, è progettato per lavorare SOLO su interi, mi pare evidente che un "floating point" dsp sia un dsp capace ANCHE di calcoli in virgola mobile, e di fatti le SPE di Cell sono in grado di elaborare sia interi, sia floating point, con i registri vettoriali a 128 bit che possono contenere indifferentemente interi e float. E comunque, a parte questo dettaglio che ho dato per scontato nel definire le SPE come "floating point dsp", il concetto della frase che hai castrato era questo:

"Le SPE sono dei DSP capaci di operare in virgola mobile ed eseguire calcoli vettoriali, che operano prevalentemente su vettori di interi, con varia lunghezza per gli elementi, E numeri in virgola mobile a singola precisione, ricoprendo praticamente le esigenze di qualsiasi dsp; sono anche capaci di calcoli in doppia precisione, ma in tal caso le prestazioni si riducono notevolmente, perchè evidentemente non sono ottimizzati per gli ambiti in cui la precisione di un double è importante, e guardacaso questi ambiti escono fuori dalla portata di un dsp che elabori dati in virgola mobile"

Adesso è più chiaro?

Mi rendo conto che il termine dsp proprio non lo digerisci... Scriverai le tue lamentele anche ai redattori di arstechnica, visto che anche loro definiscono esplicitamente le SPE (o SPU se preferisci chiamarle così) come dei DSP? Hanno le idee confuse anche loro?

Ma parliamo un po' di un dsp, così ci togliamo un po' di dubbi.

DSP = Digital Signal Processor, processore di "segnali digitali". La più elementare, ma anche più tipica, per certi versi, configurazione d'uso di un dsp, prevede un convertitore analogico/digitale che fornisce un flusso di dati digitali (era questa la castroneria?) continuo al dsp, che li elabora e li restituisce come output per essere riconvertiti in segnali analogici, anche se non è sempre necessario. Un esempio di questo tipo di uso, per rimanere nei campi di applicazione di un Cell, tanto per cambiare, è un set top box per sintonizzare canali digitali in alta definizione (in questo caso non serve neanche la conversione analogico-digitale in input, visto che i segnali in alta definizione vengono trattati solo come digitali, ma in generale, lo schema d'uso di un dsp ha sia l'adc in input, sia il dac in output; un'altro esempio simile può essere un decoder satellitare, che ha in ingresso un segnale digitale, quindi non serve l'adc, ma in output può avere il dac per inviare l'output su una tv analogica, per il resto il tipo di elaborazione è lo stesso). Si tratta di elaborare flussi di dati digitali (o digitalizzati), che ben si prestano ad essere trattati in memoria come array o matrici (cioè vettori a una o più dimensioni), ed è piùttosto semplice individuare blocchi che siano indipendenti tra di loro, quindi si prestano bene anche per una elaborazione vettoriale in unità di calcolo tipo SIMD o MIMD (le SPE effettuano proprio dei calcoli di questo tipo - era anche questa una castroneria?).

Ma questa visione dell'uso di un dsp, limitata a "segnali" così come li possiamo immaginare nell'esperienza quotidiana, è riduttiva, e potrebbe non far capire quanto un dsp possa essere utile in calcoli scientifici di una certa caratura, ad esempio. Un "segnale digitale" non è altro che un funzione (del tempo, o della frequenza, o dello spazio, o di quel che si vuole, tanto si trova una trasformata adatta a passare da un dominio all'altro, quindi la chiameremo semplicemente funzione) che descrive una "grandezza fisica" (nel senso più lato che si possa immaginare, quindi la chiameremo semplicemente grandezza) quantizzata, ossia presa per campioni, a intervalli interi (diventa una f(i), dove i è una variabile intera), e approssimata a valori interi (diventando, alla fine, una E(i), dove E rappresenta il codominio intero della funzione); però un sistema digitale può anche trattare numeri reali, che tuttavia dovranno inevitabilmente essere approssimati, perchè esprimibili, comunque, con un numero limitato di bit.

Quindi, in definitiva, un DSP è un processore capace di elaborare delle funzioni su delle grandezze espresse come quantità digitali: in questo senso, un dsp può elaborare qualsiasi cosa, ma darà il meglio di sè solo con dati strutturati in modo da costituire un flusso continuo, ovvero organizzati in grossi blocchi, da elaborare blocco per blocco, senza dover saltare da un blocco all'altro, meglio ancora se trattabili in parallelo per mezzo di unità di calcolo vettoriale. Ed è uno sporco lavoro che richiede tanta potenza: cosa ci sia di offensivo nel definire un processore DSP (=belva feroce nel macinare dati, ma con un certo livello di specializzazione), ancora non riesco a capirlo... si vede che sono tarato...

Forse il tono che ho usato nella parte finale del mio post ti sarà sembrato aggressivo, ma non era mia intenzione, e sono prontissimo a scusarmene, però al tempo stesso mi permetto di invitarti ad avere l'umiltà, che tutti dobbiamo avere, nell'accettare critiche da chi, forse (e dico forse), sa qualcosina in più di te, e ad avere la buona volontà di distinguere le critiche fini a se stesse, gli attacchi, da critiche fatte in buona fede, con l'intento di stimolarti ad approfondire questioni che già ti appassionano, per avere un dialogo più costruttivo.

Criceto

25-05-2007, 01:55

Forse ho espresso il concetto con una frase un po' complessa, però mi rifiuto di credere che tu non sia in grado di cogliere il significato di quello che ho scritto, andando oltre le parti tra parentesi, che volevano essere dei chiarimenti, e capendo che la frase non finiva li, quindi la parte che hai citato l'hai troncata apposta dove ti faceva comodo...

Se mettessi anche un PUNTO ogni tanto evitarei di dover troncare le tue frasi. Ma ti prego di rileggere la parte quotata! :p

Mi sembra di capire che per te tutti i processori che hanno unità vettoriali siano DSP. Per me un processore "general pourpose" che ha anche unità vettoriali (TUTTI i processori moderni!) sono semplicemente ANCORA più general pourpose perchè, tra le varie cose, gestiscono meglio i flussi digitali (diciamo così).

Questo, naturalmente, include il Cell le cui SPU NON SONO semplici unità vettoriali ma processori veri e propri, A LORO VOLTA GENERAL POURPOSE, anche se particolarmente ottimizzate al trattamento vettoriali dei dati sia floating, che int (tanto per riprendere la tua contradditoria definizione) senza alcuna particolare preferenza se non il minor supporto alla doppia precisione. Se poi ci metti l'ulteriore unità PowerPC (che a sua volta include Altivec!), vedrai che il Cell è un CASINO ma tutto tranne che un DSP.

Mi rendo conto che il termine dsp proprio non lo digerisci... Scriverai le tue lamentele anche ai redattori di arstechnica, visto che anche loro definiscono esplicitamente le SPE (o SPU se preferisci chiamarle così) come dei DSP? Hanno le idee confuse anche loro?

Quota dove lo scrivono!!!

Lo sai che con le SPE del Cell hanno implementato algoritmi per la gestione di alberi (roba per database, tutti salti condizionati) con prestazioni di 1 ordine di grandezza superiore ai moderni processori Intel?
Cioè proprio il campo più lontanamente immaginabile dai tuoi cari DSP.

Saranno tosti da programmare, saranno ottimizzati per i flussi digitali, ma sono sufficientemente general pourpose fare tutto e meglio dei processori tradizionali con OOO o meno.
Giusto qualche carenza sulla doppia precisione (ma se cerchi sul sito IBM già ci stanno lavorando su questa cosa).

Semplicemente sono una nuovo approccio all'architettura dei calcolatori. Non è che devi per forza inquadrarli in una categoria che era scritta sul libro di architettura che hai letto tu...

xeal

25-05-2007, 08:53

Il discorso sulle SPE come unità "complete" e non solo vettoriali è complesso, ed è valido più sulla carta che nella realtà, nel senso che se vai a guardare i brevetti (data la foglia, brevettare l'albero) e alcuni progetti, di cui però non si sa se verranno mai realizzati, allora vedi che effettivamente una SPE può contenere di tutto. Però, nell'implementazione attuale contiene SOLO 2 unità vettoriali che operano su registri a 128 bit, più la parte relativa al caricamento e alla decodifica delle istruzioni, in questo senso sono complete, ma non general purpose perchè "castrate": sono come le cpu amd o intel a cui togli tutto, ma proprio tutto, anche la cache - comunicano con il local storage con un piccolo controller dma esterno all'unità di calcolo - e lasci, come unità di calcolo, solo la parte per le SSE, oppure come un g4/5 che ha solo (2 unità) altivec. In teoria potrebbero lavorare autonomamente, ma non sono in grado di far girare, ad esempio, il codice di un sistema operativo, quindi devono essere pilotate dalla PPE general purpose. E siccome sono in-order, se capitano due istruzioni dipendenti (ad esempio, A+B e B+C) può usare solo una delle due unità vettoriali (il vantaggio della ooo consiste principalmente in questo: semplificando, anche se posso eseguire solo 2 operazioni alla volta mi preparo ad eseguirne 4-5, così se per caso nelle prime 2 trovo una dipendenza, allora vado a guardare nelle altre se ce n'è qualcuna che posso eseguire indipendentemente, così ho le pipeline sempre piene).

Ma veniamo ad arstechnica: parto dal primo articolo che avevo linkato, che comunque non parla male dell'architettura del Cell, anzi la descrive semplicemente come un approccio alternativo ed interessante, di cui valutare i risultati.

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.

Ancora:

The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.[/qoute]

Qui si potrebbe fare una piccola osservazione: in realtà, il PowerPC 601 è forse il primo processore della famiglia ad aver introdotto una forma moooolto embrionale di logica ooo: visto che possiede/possedeva 2 alu, non aveva senso eseguire le istruzioni strettamente in-order, una dopo l'altra, quindi si effettuava un controllo sulla loro dipendenza, e, se non erano dipendenti, venivano eseguite in parallelo. Le SPU fanno la stessa cosa (ma la logica ooo del 601 dovrebbe essere più complessa di quella dei una spu); ma vediamole più in dettaglio, nella descrizione di arstechnica:

[quote]Cell SPE is geared for single-precision SIMD computation. Most of its arithmetic instructions operate on 128-bit vectors of four 32-bit elements.
[salto una parte relativa al local storage, perchè vorrei evitare di impelagarmi anche in quel tipo di discorso]
The SPEs also move the burden of branch prediction and code scheduling into software, much like a VLIW design.

The SPE's very simple front end can take in two instructions at a time, check to see if they can operate in parallel, and then issue them either in parallel or in program order. These two instructions then travel down one of two pipes, "even" or "odd," to be executed. After execution, they're put back in sequence (if necessary) by the very simple commit unit and their results are written back to local memory. The individual SPUs can throw a lot overboard, because they rely on a regular, general-purpose POWERPC processor core to do all the normal kinds of computation that it takes to run regular code. The Cell system features eight of these SPUs all hanging off a central bus, with one 64-bit POWERPC core handling all of the regular computational chores. Thus all of the Cell 's "smarts" can reside either on the PPC core, while the SPUs just do the work that's assigned to them.

Un piccolo appunto: questo articolo è vecchio, è stato scritto subito dopo la presentazione delle spe e prima di conoscere (il giorno dopo) le caratteristiche del core powerpc (che viene enfatizzato molto meno nel secondo articolo, ma ne parliamo dopo).

To sum up, IBM has sort of reapplied the RISC approach of throwing control logic overboard in exchange for a wider execution core and a larger storage area that's situated closer to the execution core. The difference is that instead of the compiler taking up the slack (as in RISC), a combination of the compiler, the programmer, some very smart scheduling software, and a general-purpose CPU do the kind of scheduling and resource allocation work that the control logic used to do

Cioè, la logica ooo viene eliminata per togliere complessità, ecc. ecc., ma questo non vuol dire che un opportuno scheduling non sia necessario: esso viene semplicemente demandato al compilatore (che però può "ragionare" solo in modo generico, non essendo nota la situazione interna al processore nel momento in cui il codice viene eseguito: per questo è nata la logica ooo), al programmatore (ancora peggio), ad un eventuale software di scheduling e al core ppc: cioè, quello che un x86 fa in hardware, il cell lo deve fare (in parte) via software. Da questo punto di vista, anche se più sofisticato, l'approccio del Cell al general purpose (rilevate le debite differenze) è simile a quello dei Crusoe di trasmeta, che non sono certo il massimo della vita quanto a prestazioni (c'è da dire che i crusoe emulano l'architettura x86 con una macchina virtuale, quindi le prestazioni sono basse anche per questo, ma fino a un certo punto: funziona come una specie di jit, quindi alla fine vai ad eseguire del codice nativo). Per chiarezza, il paragone con trasmeta lo trovi anche in quell'articolo.

Once the instructions are in the SPE, the SPE's control unit can issue up to two instructions per cycle, in-order. The SPE has a 128-entry register file (128-bits per entry) that stores both floating-point and integer vectors. As stated above, there are no rename registers. All loop unrolling is done by the programmer/compiler using this very large register file.

Ma veniamo al core "general purpose", che però in quella presentazione non era stato descritto molto in dettaglio:

We do know that this core has a VMX/Altivec unit, at least one FPU, and supports simultaneous multithreading (SMT). It's also in-order issue, like the SPUs. So it appears that this core also lacks an instruction window, presumably for the same reasons that the SPUs do (i.e. to save on die space and cut down on control logic.) I have in my notes that the core is two-issue, like the SPUs, but I can't find this corroborated anywhere else. So it's possible that the core only issues two instructions per cycle peak, i.e. one from each currently-running thread.
[...]
the PPC core does have a VMX unit. Nonetheless, I expect this VMX to be very simple, and roughly comparable to the Altivec unit o the first G4. Everything on this processor is stripped down to the bare minimum, so don't expect a ton of VMX performance out of it, and definitely not anything comparable to the G5. Furthermore, any Altivec code written for the new G4 or G5 would have to be completely reoptimized due to inorder nature of the PPC core's issue

In realtà, al momento della commercializzazione della PS3 il core PPC è stato migliorato, ma non credo vada (molto) oltre il G4e. Da wikipedia:

Cell combines a general-purpose Power Architecture core of modest performance with streamlined coprocessing elements

Forse troverai interessante anche questo (era nella news che ho linkato dopo i 2 articoli):

Yesterday, IBM announced a project that will join forces with Brazilian game developer Hoplon Infotainment to develop a Cell-based mainframe system that will host massively multiplayer online games targeted at console and PC users. IBM is calling this system a "gameframe," and it will use Cell BE coprocessors to handle message passing and physics simulation for a Hoplon-developed MMOG middleware layer, called bitVerse, that the two companies are porting to Cell. The mainframe's general-purpose CPUs (probably POWER, but not specified yet) will handle aspects of the MMOG like logistics, connectivity, and the Websphere- and DB2-driven portions of bitVerse.

The system will be Linux-based, and though this isn't stated, it might be based on the IBM System Cluster 1350, if not identical to it. The System Cluster 1350 is a high-performance computing product with models that integrate the Cell BE as a coprocessor with general-purpose processors from Intel, AMD, or IBM.

Come a dire: per IBM Cell è così general purpose, che lo usa come coprocessore matematico in abbinamento ad altri processori, sia Power, sia x86.

Poi tu dici che nel general purpose va meglio dei processori tradizionali con o senza ooo, e mi fai pensare a certe "sparate" di Kenshi Manabe, della Sony, sparate che, per quanto riguarda il general purpose, su arstechnica definiscono "boriose" senza mezzi termini (full of it). Ti riporto la conclusione:

The consumer demand for Cell-like levels of DSP prowess is limited to gaming right now, and probably will be for a few more years. But the demand for UltraSparc T1-levels of performance per watt is there yesterday in the datacenter. I don't have any kind of insider information at all on this, but I think it's a near certainty that IBM will announce some kind of server-specific version of Cell with an altered, integer-focused SPE architecture as soon as they reasonably can.[nota: sono voci circolate nel 2005, ad oggi non mi risulta che l'architettura di una spe sia stata effettivamente modificata]

This point brings me back to the statement quoted above, and to the issue of whether or not Cell really is "better than" the Pentium line. Manabe's claim is meaningless unless you ask, "better at what?" If Manabe means "better at DSP," then yeah, Cell is certainly better than anything in Intel's current to near-term x86 lineup for that niche. If he means "better at general purpose computing tasks," then, well, he's full of it. And if he means "better at throughput computing applications, like high-volume web servers," then he's either full of it or he's talking about some version of Cell that hasn't been made public yet.

Per quanto riguarda il discorso dei database, mi daresti qualche link? Vorrei capire che algoritmi usano, perchè senza conoscerli posso solo fare delle osservazioni di carattere generale, che potrebbero anche non calzare troppo.

Intanto, il problema principale con gli alberi non sono tanto i salti, quanto piuttosto i frequenti accessi in memoria (che è più lenta, e quindi ti fa perdere tempo, a meno di poter andare avanti con le altre istruzioni, ma questo Cell non lo fa), perchè si tratta di una struttura dati dinamica, con i dati sparsi in memoria, e che per di più va "attraversata" per trovare ciò che si trova, poichè ogni elemento contiene l'indirizzo del successivo (non puoi prendere un elemento a colpo sicuro, ma lo devi cercare). PERO', gli algoritmi che esplorano gli alberi, siccome sono molto importanti, hanno subito nel corso degli anni una notevole ottimizzazione: per citarne una, un albero generico viene sempre trasformato in un albero binario (= ogni nodo ha al massimo due figli), e questo consente, per dati ordinati (o da ordinare), di effettuare algoritmi di ricerca (o di ordinamento) molto veloci, a cui si aggiunge un altro algoritmo, detto di bilanciamento, che consente di avere dei sottoalberi con lo stesso numero di nodi (ogni nodo ha due figli, che a loro volta ne hanno due, e così via), in modo da dividere la, chiamiamola, "area di ricerca" in due parti uguali, dimezzando ulteriormente il tempo di ricerca; il bilanciamento in genere prevede che si conservino a parte delle informazioni, in strutture dati idonee (che possono anche essere degli array), in modo tale e da semplificare le operazioni di bilanciamento, e da velocizzare la ricerca (alla fine, non trovo i dati che mi servono a colpo sicuro, ma quasi).

Per quanto riguarda i database, inoltre, se non ricordo male, una certa parte dell'elaborazione si effettua su dati organizzati in blocchi sequenziali.

Inoltre, una struttura dati, che si chiami "albero", "lista", "pila", "coda", "grafo" ecc., è per lo più un concetto astratto che può essere implementato in modi diversi: quello che ho descritto usa l'impementazione basata sulle "liste concatenate" (che è la versione "concreta" e dinamica del concetto di lista), ma può usare anche vettori (in particolare per le pile, o stack, e le code), o delle matrici (principalmente per i grafi, e un albero è molto simile, come concetto, ad un particolare grafo). Ogni implementazione ha i suoi pro e i suoi contro: ad esempio, nell'uso di vettori/matrici si ha una notevole velocità nell'accesso ai dati, ma una maggiore lentezza se i dati devono essere cancellati (e tolti del tutto, per risparmiare spazio) e/o aggiunti; inoltre, l'occupazione di memoria può essere molto peggiore (specialmente per i grafi "sparsi" e gli alberi). Di conseguenza, gli alberi vengono implementati come struttura dinamica, e non dubito che nei test a cui ti riferisci abbiano usato questo approccio. Aggiungo solo che spesso, nell'esplorare un albero, si fa uso della ricorsione, ovvero si richiama la stessa funzione, ed eseguire delle chiamate a funzioni (con pochi salti al loro interno) può essere meno pesante (anche molto meno) rispetto all'esecuzione di una porzione di codice lunga (= complicata) con molti salti, specialmente in una architettura risc o risc-like (come quella interna delle cpu x86 attuali), con o senza ooo (soprattutto senza, ma anche con).

In definitiva, comunque, ciò che conta maggiormente nei database è la velocità nei calcoli interi, e la possibilità di eseguire in parallelo molte operazioni diverse (= non sugli stessi dati), e su questo, per quanto riguarda Cell, farei un paio di considerazioni.

Innanzi tutto, "apparentemente" Cell ha una notevole potenza di calcolo sugli interi, in virtù delle sue unità SPE vettoriali (2 operazioni ciascuna su 4 interi a 32 bit), però le operazioni necessarie tendono ad essere diverse, quindi non possono essere facilmente vettorializzate, ragion per cui una SPU finisce col poter fare al più 2 operazioni "scalari" (cioè, ogni operando è un solo intero). Per di più, la logica delle due unità SIMD presenti in una SPE effettua anche calcoli in virgola mobile, quindi la circuiteria è più complessa e la singola operazione (un po') più lenta rispetto ad una semplice alu. Ed è per questo che in uno dei quote che ho preso da arstechnica si accenna a cambiamenti nell'architettura delle SPE per trasformarle da unità vettoriali in scalari, per meglio competere, ad esempio, con un UltraSparc (cpu in-order, ma molto "ferrata" nel calcolo intero scalare, che macina database e applicazioni web server alla grande).

D'altra parte (osservazione numero due) ci sono 8 spe, ciascuna delle quali può effetuare una singola transazione, per cui con un po' di sana ottimizzazione e sfruttando tutte le unità in parallelo (e i database si prestano bene a questo tipo di lavoro, anzi ne hanno bisogno), si può ottenere un risultato notevole. In generale, mi aspetto risultati simili con algoritmi parallelizzati a livello di "task", ovvero con dei thread che operano su dati diversi; meno buoni invece se la parallelizzazione prevede la collaborazione delle spe, visto che la loro architettura è pensata principalmente per svolgere compiti autonomi, e le comunicazioni per lo scambio di dati non sono efficientissime, almeno non quanto lo sono gli algoritmi di ispezione della cache e le comunicazioni via hyper transport in un opteron, oppure la condivisione della cache in un Core 2. Se poi vado a confrontare il risultato con un processore tradizionale, dual core monothread, mi aspetto che il cell, con i suoi algoritmi ottimizzati e le 8 spe, vada più veloce; ne sono meno convinto se il confronto vado a farlo con un quad core, oppure con un sistema dual cpu dual core, specialmente se con hyper transport e gestione della memoria NUMA.

Veniamo ai DSP. Innanzi tutto, avevo definito, alla fine, come dsp un processore che, per le sue caratteristiche tecniche, viene sfruttato al meglio con un certo tipo di algoritmi ottimizzati, in particolare su flussi digitali. In origine i dsp non erano vettoriali, ma per lo più eseguivano calcoli scalari su interi: siccome, però la maggior parte di questi calcoli coinvolge operazioni uguali su molte variabili, allora è stato normale trasformarli in unità vettoriali per massimizzarne la velocità di calcolo. Un dsp "puro" ha poi, spesso e volentieri, un'architettura particolare, detta di harvard, con la memoria dati separata dalla memoria di programma, e accede ad entrambe separatamente, per andare ancora più veloce (le cpu "tradizionali" lo fanno di solito con la cache L1), ma sono dettagli.

Le unità vettoriali inserite in una cpu general purpose aggiungono delle funzionalità da dsp, quindi sono parzialmente d'accordo nel dire che diventano ancora più "general". Ma solo parzialmente, perchè le stesse cose poteva farle già prima, solo adesso le fa meglio, quindi, in un certo senso, poichè sono calcoli specializzati, la nostra cpu general purpose si è anche un po' specializzata.

D'altro canto, un dsp può essere molto specializzato, oppure può avere un certo grado di generalità, e quindi può anche essere programmato (con maggiore o minore difficoltà, a seconda dei casi) per compiti meno specifici, al di fuori del campo per cui è stato progettato, ottenendo prestazioni meno buone di quelle che ottiene nel suo campo, ma potenzialmente (anche molto) valide. Alla fine della fiera, parlerei di architetture più o meno ibride general-purpose/dsp, eventualmente sbilanciate verso l'una o l'altra tipologia.

E se un certo processore ha un'architettura tale da eseguire meglio i calcoli tipici di un dsp (come nei test condotti da IBM sul calcolo matriciale, che hanno tirato fuori da Cell il 98% della sua potenza massima teorica!), se la maggior parte delle sue unità di calcolo "assomigliano" a quelle tipiche di un dsp, e se per ottenere buoni risultati nel general purpose deve affidarsi, in tutto o in parte, alle controp@lle del compilatore, ed eventualmente ad una qualche "emulazione" software della logica ooo (perchè se vuoi andare veloce devi riempire tutte le pipeline che lavorano sullo stesso thread, e per farlo spesso sei costretto a riordinare le istruzioni), allora non mi sembra sbagliato parlare di architettura sbilanciata verso il dsp. Oppure, come avevo detto nel post precedente a questo, dire che il processore in questione si comporta prevalentemente come un dsp.

Ma se non vogliamo dire dsp, allora diciamo "streamlined processor", anche se il concetto è simile (per certi versi assomiglia a quello di più dsp che lavorano in parallelo, come fanno le SPE, ma può riferirsi anche al multicore di una cpu tradizionale, anche se "streamlined" ha in sè il concetto dell'elaborazione di un flusso di dati).

Spero di aver messo abbastanza punti :p

Criceto

25-05-2007, 14:10

Per quanto riguarda il discorso dei database, mi daresti qualche link? Vorrei capire che algoritmi usano, perchè senza conoscerli posso solo fare delle osservazioni di carattere generale, che potrebbero anche non calzare troppo.

http://www.ddj.com/dept/64bit/197801624

Comunque scrivi TROOOOPPO!! :D

Florio

25-05-2007, 15:29

Lud von Pipper

25-05-2007, 16:46

Xeal perdonami, ma perchè ti ostini a tentare di far capire le cose a qualcuno che trae le sue informazioni da playstation magazine o fonti del genere, paventando comunque conoscenze assolute?
Non ti infastidisce vedere i tuoi sforzi presi per giunta in giro?

Solo un consiglio spassionato tra siciliani, investi meglio le tue spiegazioni :)

Florio, perdonami, ma perchè non ti fai gli affaracci tuoi e li lasci continuare, per una volta che c'è una discussione interessante e istruttiva?
Se ti annoi vai su un altro 3D, prendi la palla e vai fuori a giocare, o fai quello che vuoi, senza per forza tacciare di "bimbominkiaggine" questo o quello :rolleyes:
Nessuno ha citato articoli da "PS3 news fino ad ora, quindi di che ti lamenti"?
Se sei nato "imparato" buon per te ma le argomentazioni ci sono eccome, da una parte e dall'altra, quindi lascia a noi mortali la possibilità "leggere" e "farci un idea".

Per me non sono cose ovvie come sembrano essere per te, quindi chiedo venia e riprendo a leggere il 3D

^TiGeRShArK^

25-05-2007, 18:35

Criceto

25-05-2007, 19:03

strano però ke ancora nessuno mi abbia risposto..
se il Cell da quello ke dite è un super-processore in grado di fare tutto, le SPE sono dei processori general-purpose con prestazioni magnifiche.. ecc .. ecc...
allora per quale minGhia di motivo IBM è stata tanto masochista da buttare 5 anni di ricerca e sviluppo sul power 6 visto ke a quanto dite il Cell è il non-plus ultra? :p
..e vediamo se al terzo post qualcuno si degna di rispondermi :D

Perchè per sfruttare a dovere il Cell devi riscrivere i programmi da zero. Gli algoritmi devono essere reimplementati in modo totalmente differente. E può essere molto difficile farlo (oltre che sicuramente dispendioso).

Quindi sono più adatti dove ci sono piccoli algoritmi standardizzati da ottimizzare, piuttosto che per porting di mastodontici software da altre piattaforme, che è il pane del Power6.

E probabilmente è il motivo per cui Apple ci ha rinunciato. Sarebbero stati fantastici per i vari "core-video, core-audio, core-image", e altre librerie ottimizzate dell'OS, ma si sarebbe ritrovata con il 95% dei software di terze parti che giravano solo sulla PPE, con prestazioni da G4.

^TiGeRShArK^

25-05-2007, 19:37

Perchè per sfruttare a dovere il Cell devi riscrivere i programmi da zero. Gli algoritmi devono essere reimplementati in modo totalmente differente. E può essere molto difficile farlo (oltre che sicuramente dispendioso).

Quindi sono più adatti dove ci sono piccoli algoritmi standardizzati da ottimizzare, piuttosto che per porting di mastodontici software da altre piattaforme, che è il pane del Power6.

E probabilmente è il motivo per cui Apple ci ha rinunciato. Sarebbero stati fantastici per i vari "core-video, core-audio, core-image", e altre librerie ottimizzate dell'OS, ma si sarebbe ritrovata con il 95% dei software di terze parti che giravano solo sulla PPE, con prestazioni da G4.
ecco..
quindi sei d'accordo con me che il Cell non è affatto la panacea che viene dipinta in questo forum..
e soprattutto non è assolutamente detto che ogni tipo di algoritmo possa girare con prestazioni maggiori sul cell rispetto ad un qualsiasi altro processore, anzi, ci sono forti indizi per il contrario.
Non dimentichiamo che se ci fosse solo la difficoltà di scrivere software ottimizzato e non l'impossibilità di scrivere codice con prestazioni migliori in ogni campo allora IBM non avrebbe avuto alcun problema a gettare via il suo power 6 e a spingere su cell.
Basta ricordare l'architettura EPIC su cui è basato itanium su cui intel ha spinto moltissimo (anke se con scarsi risultati x diversi motivi).

xeal

25-05-2007, 20:06

Ragazzi, su, non litigate :p
Non voglio certo portare avanti la discussione all'infinito, ed effettivamente scrivo troppo :p però l'argomento è interessante, e con la scusa sono andato a rivedere un po' di cose :p

Veniamo all'algoritmo ottimizzato: occhio che si tratta di grafi, non di alberi. E i grafi si prestano a volte ad essere trattati come vettori/matrici, oppure con una struttura ibrida vettore-lista, che è quella adottata nell'algoritmo, più altri vettori con informazioni rilevanti. Ma come dicevo, un Cell è ottimizzato per trattare meglio i flussi di dati continui (= vettori) rispetto alle liste, anche se ha delle ottimizzazioni per ridurre il gap, e nell'algoritmo si usano degli hack per sfruttare queste ottimizzazioni più un double buffering dei dati caricati nella memoria interna del processore (e riportati in memoria centrale), per mascherare le latenze di accesso alla ram (accesso che oltretutto va programmato "a manina" ). Questo complica le cose e mi dimostra, ancora una volta, come Cell sia ottimizzato, in hardware, più per accessi sequenziali e usi specifici che per accessi casuali e utilizzi generali.

Ma veniamo (in breve) all'algoritmo: si tratta di una esplorazione "in larghezza", contrapposta all'esplorazione in profondità che si preferisce con gli alberi. E' un'algoritmo che potremmo definire quasi "brute force", perchè per un certo livello di profondità io prendo tutti i nodi e li esamino contemporaneamente, ma si presta bene per una parallelizzazione estrema, specialmente se nei livelli ci sono molti nodi (cioè se ogni nodo è collegato a molti altri nodi, anche in livelli precedenti).

Va bene per molte applicazioni con i grafi (ma non per tutte), molto meno per gli alberi, specialmente se i dati sono ordinati/ordinabili (una delle situazioni principali in cui si ricorre agli alberi, appunto), perchè so che per qualunque nodo, a sinistra avrò tutti i nodi con elementi "minori", a destra tutti quelli "maggiori", e se l'albero è ben bilanciato, ogni volta che vado a destra o a sinistra dimezzo il numero di nodi da considerare. Vero è che il bilanciamento ha un costo computazionale, però nell'algoritmo sui grafi preso in considerazione, per ottimizzare la distribuzione dei nodi alle spe e per migliorare ulteriormente l'accesso ai dati, il grafo viene preliminarmente organizzato e riordinato opportunamente (presumo quindi che una variante sugli alberi dovrebbe essere parimenti "sistemata" ).

Oltretutto, l'analisi in larghezza del grafo (o anche di un albero) può andar bene (anche se più lenta per gli alberi) se il contenuto è "fissato" prima dell'elaborazione, mentre non va bene se il contenuto è dinamico, come ad esempio nel caso di elaborazioni che utilizzano un albero per organizzare i risultati parziali, e spesso, una volta ottenuti dei risultati significativi, cancellano delle (grosse) parti dell'albero, prima di andare avanti, ottimizzando l'uso della memoria (è il caso di algoritmi di backtracing, di cui si fa largo impiego, ad esempio, nell'intelligenza artificiale e nei programmi di ottimizzazione, tipo graams).

Ma quello che più colpisce è la difficoltà nell'ottimizzazione: il codice (semplificato) di partenza si compone di 60 righe, quello finale di ben 1200!! Questo vuol dire che per spremere un Cell serve uno sforzo notevole, che diventa ancora più grande se si deve adattare il programma o a una variante (possibile in futuro) di Cell con più spe (è noto che per farlo nella maggior parte dei casi occorrerebbe riscrivere una parte del programma), oppure per farlo eseguire da più Cell (da questo punto di vista, i processori "tradizionali" scalano un po' meglio, ma non troppo). Quindi, un Cell si dimostra più adatto a scopi specifici nei quali le prestazioni ottenute valgono il prezzo di un'ottimizzazione spinta (= tempo, e quindi denaro, maggior rischio di incorrere in bug, maggiore difficoltà nella manutenzione/modifica del codice). Insomma, non è esattamente quello che si intende per general purpose. Inoltre, per ammissione degli stessi programmatori, il loro codice superottimizzato è poco leggibile, e questo contrasta con una delle regole "generali" della programmazione: all'ottimizzazione e alle prestazioni, se non strettamente necessarie, è sempre preferibile la semplicità e la leggibilità del codice (perchè con un codice poco leggibile aumentano a dismisura i problemi cui accennavo poco sopra).

Infine, farei un piccolo appunto alla "metodologia" di confronto, che annichilisce un povero P4 a 3.4 Ghz con HT. Mi sembra di capire che il P4 abbia eseguito la versione base dell'algoritmo; tuttavia, poichè l'articolo è incernierato sulle prestazioni massime ottenibili con quell'algoritmo, avrei gradito uno sforzo per ottimizzare il codice anche per il Pentium e creare una struttura dati adegeguata, come è stato fatto per il Cell, per sfruttarne bene l'HT e possibilmente anche le SSE + MMX (visto che per il Cell hanno ottimizzato in modo da eseguire dei calcoli SIMD nelle spe). Naturalmente mi aspetto ancora una "sconfitta" per la cpu monocore, però magari un risultato un po' migliore, e presumo che aggiungendo delle ottimizzazioni per il multicore (o per sfruttare più cpu) un quadcore avrebbe sfigurato ancora meno.

Lud von Pipper

25-05-2007, 20:11

ecco..
quindi sei d'accordo con me che il Cell non è affatto la panacea che viene dipinta in questo forum..
e soprattutto non è assolutamente detto che ogni tipo di algoritmo possa girare con prestazioni maggiori sul cell rispetto ad un qualsiasi altro processore, anzi, ci sono forti indizi per il contrario.

No, mi sa che non hai afferrato bene la differenza tra un cell e un, diciamo X86

Il secondo è un processore NATO per esegure codice preesistente, un ibrido complesso di tecnologie CISC e RISC con Pipelines (lunghe o corte che siano) che cerca, per velocizzare i processi attraverso sofisticati meccanismi di predizione delle richieste del software: in pratica scommette su quello che il programma chiederà di fare per "mettersi avanti" con il lavoro.
Il P4 era un esempio di processore con Pipelines molto lunghe, L'A64 ha Pipes più brevi ma è più efficiente.

Il CELL è "sui generis", e penso che qui ci sia gente che può descriverlo molto meglio di me.
La potenza di calcolo, soprattutto in certi ambiti è altissima, ma in altri soffre di "semplificazione", quindi è difficile fare porting di applicazioni gia scritte.
Prendi per farti un esempio un processore RISC all'antica, come un ALPHA della Digital. La potenza di calcolo era diverse volte maggiore per esempio di un MIPS CISC montato ad esempio dalle stazioni Silicon graphic.
Eppure gli Alpha non si sono mai espansi (pur non essendo particolarmente costosi) al di fuori di una nicchia limitata di informatica perchè la loro semplicità costruttiva (relativa) obbligava i programmatori ad una programmazione di basso livello, dispendiosa e complessa.
In pratica le istruzione ridotte del processore richiedevano programmi più "dettagliati", certo non un semplice compilatore C++ se si voleva ottenere il massimo dalle prestazioni del porcessore.

Il Cell ha problemi simili: programmazione complessa e difficile, programmi completamente riscritti (e non semplicemente "portati"), sistemi operativi esistenti molto orientati ad architetture diverse dal Cell.
Anche per portare un semplice word processor si sarebbe dovuto riscriverne gran parte, cosa poco pratica in termini economici.

PS3 ha dimostrato proprio questo: il Cell che potenzialmente sarebbe docuto essere il cuore unico del sistema, in grado di calcolare la grafica, fungere da CPU centrale e da unità di gestione audio è stato affiancato da schede grafiche e cooporcessori per rendere la programmazione della consolle meno "aliena" e permettere un porting più semplice dei programmi da altre consolle (basate su evoluzioni del G4)
Non so quali prestazioni avrebbe offerto nella grafica il Cell di PS3 ma è comune opinione che nella configurazione attuale il sia molto sottosfruttato.

Power6 invece può facilmente usufruire di tutte le applicazioni gia scritte per risc6000 e generazioni successive, cosiderando che per i clienti di workstation IBM il software è uno degli investimenti più costosi.

^TiGeRShArK^

25-05-2007, 20:53

No, mi sa che non hai afferrato bene la differenza tra un cell e un, diciamo X86

bhè.. se lo dici tu :D

Il secondo è un processore NATO per esegure codice preesistente,

gli 8086 quale grande base di codice preesistente avevano a disposizione? quello dei 4004? :p

un ibrido complesso di tecnologie CISC e RISC con Pipelines (lunghe o corte che siano) che cerca, per velocizzare i processi attraverso sofisticati meccanismi di predizione delle richieste del software: in pratica scommette su quello che il programma chiederà di fare per "mettersi avanti" con il lavoro.

e questa è l'unità di branch prediction e non ha nulla a che vedere con le caratteristiche in-order o out of order di un processore :D
Il principio dell'out of order è ke le istruzioni vengono riorganizzate in modo da permettere alle unità di calcolo di non restare bloccate mentre è richiesto un accesso potenzialmente ad elevata latenza: ovvero un accesso alla memoria.

Il P4 era un esempio di processore con Pipelines molto lunghe, L'A64 ha Pipes più brevi ma è più efficiente.

Il CELL è "sui generis", e penso che qui ci sia gente che può descriverlo molto meglio di me.

ovvero?
che processore è un processore "sui generis"?

La potenza di calcolo, soprattutto in certi ambiti è altissima, ma in altri soffre di "semplificazione", quindi è difficile fare porting di applicazioni gia scritte.
Prendi per farti un esempio un processore RISC all'antica, come un ALPHA della Digital. La potenza di calcolo era diverse volte maggiore per esempio di un MIPS CISC montato ad esempio dalle stazioni Silicon graphic.
Eppure gli Alpha non si sono mai espansi (pur non essendo particolarmente costosi) al di fuori di una nicchia limitata di informatica perchè la loro semplicità costruttiva (relativa) obbligava i programmatori ad una programmazione di basso livello, dispendiosa e complessa.

veramente ai tempi i processori RISC dominavano di fatto il mercato dei Server.
La vera ragione della sconfitta dei RISC è stata la creazione dei processori odierni che hanno l'architettura ibrida da te citata che permette loro di tradurre le operazioni complesse CISC in micro-ops RISC che possono essere eseguite a piena velocità dall'unità di esecuzione di tipo RISC interna.
Ovviamente così facendo però si è complicato lo stage di decode ma si è anke reso possibile l'uso di tecniche "interessanti" (vedi la micro-ops fusion dei processori CORE).
Inoltre l'ottimizzazione dei compilatori ha reso praticamente inutile ricorrere alla scrittura in assembly e quindi quella da te citata non può essere la causa della scomparsa dei RISC dato che se programmi in C se hai davanti un processore CISC o un RISC non te ne frega nulla.
Tra l'altro i processori 680x0 della motorola erano MOLTO ma MOLTO + semplici da programmare in assembly dei corrispettivi INTEL.
vabbè.. a parer mio in effetti era anke + semplice l'assembly degli SPARC rispetto a quello "CISC" degli x86.. ma lì andiamo in una questione di gusti soggettivi :p

In pratica le istruzione ridotte del processore richiedevano programmi più "dettagliati", certo non un semplice compilatore C++ se si voleva ottenere il massimo dalle prestazioni del porcessore.

Il massimo delle prestazioni deve essere ottenuto nell'1% di codice in cui si ha lo spreco del 90% del tempo della CPU.
Scrivere tutto il codice in assembly è pura follia perchè si avranno ovviamente prestazioni peggiori rispetto ad un compilatore che conosce tutti i trucchetti e sa perfettamente come ottimizzare e ovviamente si avrò uno spreco di anni-uomo assurdo per arrivare ad un risultato peggiore.

Il Cell ha problemi simili: programmazione complessa e difficile,

Per ottimizzare adeguatamente un algoritmo in maniera da sfruttare adeguatamente le SPE sono d'accordo.

programmi completamente riscritti (e non semplicemente "portati"), sistemi operativi esistenti molto orientati ad architetture diverse dal Cell.
Anche per portare un semplice word processor si sarebbe dovuto riscriverne gran parte, cosa poco pratica in termini economici.

Perchè per un semplice word processor si sarebbe dovuto riscrivere gran parte del codice?
un word processor ha forse requisiti prestazionali spinti?
Sarà che ero abituato ad usare wordstar su un 286...
ma non credo che un word processor possa beneficiare delle SPE del cell :p

PS3 ha dimostrato proprio questo: il Cell che potenzialmente sarebbe docuto essere il cuore unico del sistema, in grado di calcolare la grafica, fungere da CPU centrale e da unità di gestione audio è stato affiancato da schede grafiche e cooporcessori per rendere la programmazione della consolle meno "aliena" e permettere un porting più semplice dei programmi da altre consolle (basate su evoluzioni del G4)

O forse perchè quello non era il campo di utilizzo del Cell?
Secondo voi il Cell ha risorse infinite ed è la panacea per ogni problema di programmazione se adeguatamente ottimizzato?

Non so quali prestazioni avrebbe offerto nella grafica il Cell di PS3 ma è comune opinione che nella configurazione attuale il sia molto sottosfruttato.

Se parli di grafica inteso come sfruttamento all'interno di una pipeline grafica del tutto simile a quella di una moderna GPU.. bhè.. il Cell sarebbe impallidito al confronto :p
Per operazioni di post-processing e di geometria invece avrebbe avuto da dire la sua.

Power6 invece può facilmente usufruire di tutte le applicazioni gia scritte per risc6000 e generazioni successive, cosiderando che per i clienti di workstation IBM il software è uno degli investimenti più costosi.
E inoltre le prestazioni del power 6 in totale, checchè se ne dica su questo forum sono maggiori rispetto al cell.
Il cell in diversi ambiti sarebbe stato superiore.
Ma una CPU come il power 6 non è pensata per lavorare in ambiti ristretti ma è una CPU pensata per dare il meglio di sè in tutti gli ambiti possibili.

Ancora sicuro ke non ho afferrato bene la differenza tra cell e x86? :D

Lud von Pipper

25-05-2007, 22:07

bhè.. se lo dici tu :D:D

Ok, scusa, pensavo che tu veramente non avessi capito e cercavo di spiegare in termini comprensibili da tutti.
Visto che vuoi fare il brillante dimostrando tutta la tua cultura informatica, muovi pure il culo e leggi TUTTE E QUATTRO le pagine precedenti: li trovi tutto quello che vuoi sapere sull'argomento compresa la domanda con cui ci vai assillando da quattro post. :muro:

Piccola precisazione: X86 rivolto a un processore indica un processore in grado di eseguire codice di quel tipo, compreso A64, Core2, centrino e tutti i processori di quel genere.
Ovvio che se parliamo di Cell, non ha molto senso parlare di 8088 e del software sviluppato all'epoca.:rolleyes:

Se poi sei qui per dire che il Cell non vale nulla fai pure, ma il fatto che tu non capisca non indica necessariamente che le tue tesi siano valide :asd:

^TiGeRShArK^

25-05-2007, 22:41

Ok, scusa, pensavo che tu veramente non avessi capito e cercavo di spiegare in termini comprensibili da tutti.
Visto che vuoi fare il brillante dimostrando tutta la tua cultura informatica, muovi pure il culo e leggi TUTTE E QUATTRO le pagine precedenti: li trovi tutto quello che vuoi sapere sull'argomento compresa la domanda con cui ci vai assillando da quattro post. :muro:
ehmm..
veramente ai tempi abbiamo riempito + di una 50ina di pagine parlando del cell..:p
quindi non è ke mi spaventino le 4 pagine..
è ke io la mia idea ce l'ho e IBM sembra confermarla in toto pensando a investire 5 anni in R&D sul power 6 piuttosto che sul cell che ora come ora semplicemente non è adatto ad essere impiegato in tutti i campi di utilizzo del power 6.

Criceto

25-05-2007, 23:31

ehmm..
veramente ai tempi abbiamo riempito + di una 50ina di pagine parlando del cell..:p
quindi non è ke mi spaventino le 4 pagine..
è ke io la mia idea ce l'ho e IBM sembra confermarla in toto pensando a investire 5 anni in R&D sul power 6 piuttosto che sul cell che ora come ora semplicemente non è adatto ad essere impiegato in tutti i campi di utilizzo del power 6.

Anche per i Cell ci ha investito 5 anni.

Sono entrambi (Power6 e Cell) processori eccellenti, il meglio della tecnologia odierna, il Power6 è un processore dal punto di vista costruttivo senza compromessi (num. transistor, banda, cache, ecc) ma tutto sommato "tradizionale", fatto per far girare al meglio il codice esistente.

Il Cell non è così spinto a livello costruttivo (1/3 di transistor o meno), perchè nell'attuale evoluzione è nato per tutt'altro mercato, ma ha caratteristiche uniche che in molti ambiti (non così ristretti come molti pensano), con software appositamente scritto, lo può far eccellere.

Insomma io il SuperCell da desktop, con un solo core Power6, un po' meno cache, e qualche SPE (magari ottimizzata per la doppia precisione) ce lo vedrei tutto! ;) Peccato che IBM sia uscita da quel mercato.

xeal

26-05-2007, 02:10

Credo che si possa (e si debba) chiudere la diatriba sul general purpose. Cell è sicuramente più generico di un "semplice" dsp (anche se un buon 70% dei suoi transistor si trovano dentro unità ottimizzate per fare un lavoro da dsp), ma per riuscire a sfruttarlo in ambiti diversi bisogna fare i salti motrali, quindi ha senso usarlo solo se il gioco vale la candela. Molto probabilmente è vero che nella PS3 è sottosfruttato, ma perchè la tipologia di applicazioni cui è destinata si adatta meglio ad altre tipologie di hardware (oltre un certo limite, non si può parallelizzare un gioco senza diventare pazzi), e per questo motivo, rispetto ai piani iniziali, il die è stato aumentato per migliorare le prestazioni dell'unico core general purpose.

Alla fine della fiera, un'architettura è vincente nel general purpose quanto più è semplice da programmare per la maggior parte delle applicazioni, ottenendo prestazioni mediamente buone senza dover tenere conto dell'architettura. Cioè, scaricando il compito delle ottimizzazioni al compilatore, guardando alle architetture di interesse in maniera il più possibile trasparente, e con un compilatore che sia anch'esso facile da scrivere. In questo, storicamente i CISC (e secondo molti il motorola 68000 va considerato come CISC, visto che la parte maggiormente in comune con i RISC è la lunghezza fissa delle istruzioni) hanno primeggiato, con i RISC che davano (e danno) il meglio sulla lunga distanza e con algoritmi che necessitano di una notevole ottimizzazione. Per questo motivo, col tempo i Risc si sono "adattati" alle esigenze del general purpose diventando meno risc: il numero di istruzioni è cresciuto notevolmente, così come la loro complessità, allontanandosi dalla definizione canonica di "reduced set, reduced instruction"; sono state introdotte circuiterie per l'esecuzione fuoriordine e la predizione dei salti; si è arrivati anche a una soluzione "ibrida" simile a quella degli attuali x86, con una unità d'esecuzione ancora più risc rispetto al set di istruzioni. Poi ci sono Risc più "classici", che riprendono l'approccio della semplicità estrema, e si prestano meglio per scopi specifici che per usi "generici", come appunto il Cell (fortemente sbilanciato in hardware per la gestione di flussi digitali).

Il problema del Cell nel general purpose non è tanto la presenza di codice in abbondanza per le architetture "precedenti", perchè in tal caso "basterebbe" un buon compilatore per risolvere in gran parte il problema, visto che un'applicazione "general purpose" non è caratterizzata da un'ottimizzazione estrema; tutt'al più si potrebbe avere un periodo di transizione con un jit, che potrebbe operare in background e impegnare un paio di spe. E nemmeno la difficoltà nel programmarlo, perchè sono sicuro che, finchè ci si limita alle tipologie di calcolo per le quali l'architettura Cell è progettata (e sbilanciata, rispetto al general purpose), come i flussi audio-video (o più in generale applicazioni con strutture dati a blocchi contigui, forte parallelizzazione e possibilmente operazioni vettoriali), allora programmare un Cell non può essere così difficile. Il problema è la difficoltà nel programmare Cell al di fuori di un ambito tutto sommato ristretto, perchè Cell soffre gli accessi casuali in memoria, e quindi bisogna inventarsi un double buffering + altri barbatrucchi; perchè le spe non hanno una cache, ma un local storage che si comporta come una specie di ram privata, e bisogna decidere "a mano" cosa conviene caricare e quando, e quando invece spostare i dati nella ram; perchè mancando la logica per ooo e branch prediction bisogna scrivere un compilatore con le alle quadrate, più complicato da realizzare rispetto ad uno per architettura più general purpose, e in alcuni casi potrebbe essere addirittura necessario scrivere un layer software per emulare le funzioni della logica ooo/bp, oppure fare molta attenzione ad evitare accuratamente salti di qualsiasi genere, trasformando un semplicissimo ciclo for in una sequenza in cui si indicano tutte le operazioni sequenzialmente (è quello che hanno fatto nell'algoritmo dei grafi!!!).

E non è tanto una questione di algoritmi ottimizzati per altre architetture, ma piuttosto di problemi di per sè poco adatti all'architettura Cell, che non solo ha bisogno di un'ottimizzazione specifica, ma in molti casi ha bisogno di molta più ottimizzazione per così dire alla base. In questo senso ha ragione TigerShark quando parla di impossibilità, però bisognerebbe chiarire un po' meglio il concetto, per evitare fraintendimenti e altre quattro pagine che rischierebbero di trasformarsi in un litigio. NON è impossibile effettuare il porting di una qualche applicazione per Cell, e NON è impossibile ottimizzare il programma in modo da sfruttare decentemente Cell, ma POTREBBE, in alcuni casi e in tempi compatibili con la vita di una persona, o anche solo con il ciclo del software, essere impossibile ottenere risultati SENSIBILMENTE MIGLIORI rispetto a quelli ottenibili, in molto meno tempo e con molta meno fatica, su altre piattaforme. Se dopo aver speso tempo, denaro, fatica, scopri che non hai guadagnato abbastanza (e questo lo scopri solo alla fine) e dovresti ottimizzare ancora, senza la certezza di riuscirci, allora rischi una reazione che è un misto di pianto, rabbia, urla, sconforto, incredibie ulk, maniaco suicida, chi più ne ha più ne metta. Insomma, finchè non ci metti le mani sul serio non sai se il gioco valga la candela.

Qundi, benchè l'architettura Cell sia in qualche modo adatta/adattabile al general purpose, usarla al di fuori dei campi per i quali è maggiormente ottimizzata non è necessariamente una buona idea. Questo perchè l'essere ottimizzato per certi scopi vuol dire che un Cell ha un'architettura sbilanciata per fare alcune cose meglio di altre, e di conseguenza se si vuole tirare fuori il massimo delle sue prestazioni anche con quelle altre, bisogna "trasformarle" in quelle che fa meglio, ma questo non è nè facile, nè possibile con certezza. E allora perchè IBM, o qualcun altro, dovrebbe pensare di usare Cell per fare tutto e il contrario di tutto, invece di fargli fare esattamente ciò che gli riesce meglio, a meno di poter predire in qualche modo gli esiti, o di avere a che fare con applicazioni che necessitano veramente di una notevole (e difficile) ottimizzazione (quindi, casi abbastanza specifici)? ;)

In realtà potrebbe, a patto però di modificare l'architettura di Cell: un "SuperCell", con un cuore Power "completo" (lo lascerei dual core, per non ricascare nel problema delle ottimizzazioni), con tanto di logica ooo (più o meno castrata), e delle SPE diverse, capaci anche di calcoli in doppia precisione più veloci e diversamente specializzate, alcune scalari, altre vettoriali, sarebbe qualcosa di diverso da ciò che Cell è oggi, assomiglierebbe al concetto di multicore eterogeneo di amd, con dei core general purpose x86 accanto a core specializzati per fare da coprocessore (anche se nella visione di amd si dovrebbe fare in modo che per il compilatore sia semplice decidere quale core usare, sgravando il più possibile il programmatore dalle decisioni difficili). Sarebbe sicuramente una belva, e non solo per applicazioni desktop (anzi, per lo scopo avrebbe fin troppi transistor :p ma avrebbe senso con un processo di miniaturizzazione molto spinto). E allora potremmo fare dei ragionamenti diversi, perchè sarebbe molto meno ottimizzato per scopi specifici.

NeatoEurope

26-05-2007, 06:56

Se non lo fanno evidentemente avranno i loro buoni motivi, però non mi dispiacerebbe vedere IBM entrare anche in ambito desktop a competere con AMD e Intel, servirebbe una terza azienda.

IBM che si può considerare l'inventrice dell'informatica attuale, come caratteristica ha quella di vendere i rami poco remunerativi prima che si secchino, vedi prima il settore PC, poi quello HD e di recente anche quello dei portatili.

Non scenderebbe mai direttamente in una lotta del genere ma ne rimane uno dei fulcri con tutti i suoi brevetti.

Ciao

Sèvero

Criceto

26-05-2007, 11:39

Credo che si possa (e si debba) chiudere la diatriba sul general purpose.

Discorso ragionevole. :mano:

Comunque un paio di precisazioni.
La famiglia 68000 è SEMPRE stata CISC e senza ombra di dubbio.

Negli anni 80-90 i RISC (IBM, HP, SPARC, MIPS, ALPHA) erano significativamente superiori ai CISC dell'epoca, cioè in pratica ai 68k e x86 che andavano per la maggiore, ed erano utilizzati in costose workstation (SUN, SGI) e nei server. Poi, in particolare Intel e AMD, hanno inziato a ibridizzare la loro architettura colmando piano piano il gap prestazionale e spesso superando i vari RISC. Nell'altro ambito la famiglia Power di IBM ha assunto alcuni aspetti dei CISC (il numero di istruzioni, in particolare, è molto elevato). Oggi la distinzione tra CISC e RISC non è così netta come 10-15 anni fà.

Però l'architettura x86 risente comunque di una progettazione davvero iniziata male, anche in confronto degli altri CISC dell'epoca (68k) e anche con i salti mortali di cui è capace Intel per me difficilmente potrà mai competere con un'implementazione di alto livello di un'architettura partita con un approccio molto più moderno ed efficiente come la famiglia Power di IBM (quindi l'attuale Power6).

E per TigerShark, anche i MIPS di Silicon Graphics erano RISC e anche molto "puri" come tipologia.

^TiGeRShArK^

26-05-2007, 12:17

E per TigerShark, anche i MIPS di Silicon Graphics erano RISC e anche molto "puri" come tipologia.
:mbe:
guarda che lo so benissimo che i MIPS al pari degli ALPHA degli SPARC dei PA-RISC erano RISC.. :mbe:
dove avrei detto il contrario? :mbe:
Io parlavo dei 68000 e quelli si che sono cisc..
basta usare un pò del loro assembly per rendersene perfettamente conto :p

xeal

26-05-2007, 17:23

Io però non mi riferivo alle prestazioni, ma ad una qualche facilità nell'ottenere rapidamente un'ottimizzazione decente, senza però riuscire ad andare (molto) oltre i primi buoni risultati, con i RISC che invece progredivano senza soluzione di continuità, in un epoca in cui, comunque, l'ottimizzazione spinta era una necessità abbastanza pressante. Per arrivare ad oggi, con i RISC preferiti nei supercomputer dediti al calcolo scientifico più pesante, anche in virtu di algoritmi particolari, vecchi di decenni ma sempre validi, giunti nel tempo ad un livello di ottimizzazione eccellente proprio sui risc, ma anche in datacenter "cattivi", dove macinano database alla grande (ma in quest'ambito gli amd non sfigurano, ma anche gli xeon - un po' peggio però, dai 4 processori in su, per via dell'assenza di un controller integrato e dell'architettura NUMA, anche se i core 2 e derivati sono davvero molto veloci) anche senza logica ooo (perchè alla fine contano le prestazioni sugli interi e la parallelizzazione delle transazioni, e le ultime famiglie SUN, ad esempio, sono in order, ma multithreaded e multicore, quindi sopperiscono alla (potenzialmente) minore parallelizzazione a livello di istruzione con una notevole parallelizzazione a livello di thread/task). Sicuramente i motivi saprebbe spiegarteli meglio di me repne scasb, ad esempio (lei si diverte, nel tempo libero, a scrivere e ottimizzare compilatori, anche direttamente in esadecimale :D un po' d'esperienza ce l'ha); mi pare che tempo fa qualche dettaglio l'aveva anche accennato in una vecchia discussione, non ricordo di preciso quale fosse la discussione.

Effettivamente, i primi x86 non reggevano il confronto con i 68K, che avevano soluzioni molto più intelligenti (ad esempio, gli x86 usavano dei multiplexer per accedere virtualmente a qualsiasi registro contemporaneamente, ma non serviva e quindi era uno spreco di transistor e denaro, mentre i 68k usavano più intelligenemente un bus - più altre cosucce interessanti). Col tempo, però, l'isa x86 è stata sistemata, e come giustamente dicevi non c'è più una grandissima differenza tra CISC e RISC. Forse le due principali differenze rimaste sono il formato istruzione a lunghezza fissa, che ha dei vantaggi per calcolare facilmente spiazzamenti di un certo tipo, anche se la lunghezza variabile delle istruzioni x86 ha (meglio, aveva) dei vantaggi nel minimizzare l'occupazione di memoria, e comunque non se ne risente particolarmente, e la presenza (ancora) di microcode, che però si riduce praticamente ad ogni nuova famiglia, e ormai serve solo per istruzioni poco usate e solo se l'alternativa sarebbe più lenta (ormai, i compilatori le evitano abbastanza bene). Inoltre, nel tempo sono state introdotte istruzioni interessanti, come le varie cmovx che consentono, se sfruttate bene, di minimizzare i salti (ad esempio, confrontando su uno stesso processore un semplice confronto, come il massimo di due numeri, fatto con le istruzioni condizionali e con una versione linearizzata dell'algoritmo (= totalmente senza salti, ma solo una serie di addizioni e operazioni logiche, o al più moltiplicazioni), il primo è più veloce del secondo, che a sua volta è più veloce di uno con i salti (cioè, con la più semplice traduzione di un if-else)). E comunque riconosco pienamente i meriti dei RISC, che hanno introdotto soluzioni interessanti (ma col tempo sono diventati meno risc), come il concetto di pipeline e istruction window per velocizzare l'esecuzione delle istruzioni e l'aumento del clock, che poi si è evoluto, è diventato un approccio superscalare, e si è complicato molto, tanto nei cisc quanto nei risc

In fin dei conti, vista la notevole somiglianza, le differenze sono praticamente da ricercare più nella bontà delle implementazioni tecniche, che nel tipo di ISA (a tal proposito, vedrei bene la sparizione del concetto di RISC e CISC come in qualche modo contrapposti, perchè alla fine entrambi gli approcci, salvo implementazioni particolari, fanno la stessa cosa: tolgono complessità dove non serve e l'aggiungono dove serve, per massimizzare le prestazioni, quindi mi permetto di coniare l'espressione "Balanced Complexity Architectures", che a seconda degli approcci "storici" e ai set di istruzioni distinguerei in "BCA-RISC" e "BCA-CISC" - ma siccome sono anche le mie iniziali, diventerebbero i risc e i cisc secondo me :p). E vorrei ben vedere che un processorone con 790 milioni di transistor, a quasi 5 GHz, con una fpu aggiuntiva per i calcoli sui decimali (codificati in bcd) e ben due memory controller con una banda eccezionale, e che ha pure mantenuto, almeno in parte, la logica ooo (per l'fpu si sa già che c'è, per gli interi non è certo, ma potrebbe esserci in versione ridotta, e comunque compenserebbe col multithreaded, attribuendo ciascuna alu a un diverso thread, che nei server high-end fa molto comodo) non riuscisse a mangiarsi tutto il mangiabile della concorrenza. Ma se un'azienda come Cray costruisce dei "supercomputerini" di tutto rispetto con degli Opeteron, allora forse l'architettura x86, nella sua incarnazione attuale, tanto da buttar via non è.

Criceto

26-05-2007, 23:21

:mbe:
guarda che lo so benissimo che i MIPS al pari degli ALPHA degli SPARC dei PA-RISC erano RISC.. :mbe:
dove avrei detto il contrario? :mbe:

Scusa, era Lud Von Pipper. (mi sono confuso perchè l'avevo letto in tuo quote).

Criceto

26-05-2007, 23:29

Ma se un'azienda come Cray costruisce dei "supercomputerini" di tutto rispetto con degli Opeteron, allora forse l'architettura x86, nella sua incarnazione attuale, tanto da buttar via non è.

La vera Cray è morta da tempo, con il suo geniale inventore.
Quello di oggi porta solo il suo nome e non ha nulla di innovativo.

I veri Cray erano davvero "spaziali", estremi, innovativi, geniali. E' molto interessante leggere la storia di quei calcolatori. Oggi le CPU si somigliano un po' tutte, a parte il Cell che un po' richiama gli approcci estremi del geniale Seymour.

xeal

27-05-2007, 04:38

Secondo me, più che la "vera" Cray, è "morto", per certi versi, quel tipo di approccio al supercomputing. I Cray a cui ti riferisci erano dei gioielli sotto tutti i punti di vista possibili e immaginabili, e anche di più, ma a un certo punto si sono trovati ad avere problemi e di scalabilità, e di performance rispetto ad altre architetture emergenti nel panorama del supercomputing; poi, si, concettualmente i microprocessori usati somigliavano al Cell, e questo sicuramente comporta le stesse limitazioni e problematiche che avrebbe l'impiego in "massa" (= come unica architettura per tutti i campi) di Cell: difficoltà di programmazione e ambiti d'uso "ottimale" ridotti (piccola nota: fino a quel momento, l'approccio di Cray era il migliore e il più facile da programmare in qualsiasi ambito del supercomputing, col tempo però le cose cambiarono e divenne via via più facile programmare macchine con molti processori non vettoriali - Massive Parallel Processors). Processori di tipo vettoriale vengono usati, attualmente, all'interno dei supercomputer come dei coprocessori affiancati a processori meno specializzati, e sembra che il futuro fada in questa direzione, con l'integrazione di core eterogenei nella stessa cpu.

Al punto in cui si trovava, bisognava fare una scelta: proseguire sulla stessa strada e ottimizzare le soluzioni già adottate (migliorando le architetture esistenti e/o cercandone sul mercato di simili), rischiando di rinchiudersi in una nicchia sempre più ristretta (all'interno di quella che è già una nicchia - non è che di supercomputer da 100 TeraFlops se ne vendano miliardi in un anno :D); oppure guardarsi intorno per valutare altre, differenti architetture, da affiancare alle "proprie", se non adottare in alternativa alle proprie se necessario/utile, per ampliare la propria offerta e farne una scelta valida.

E' stata scelta la seconda via, e a giudicare dai risultati non è stata poi così sbagliata: nella TOP500 attuale (aggiornata a novembre 06), al secondo posto, dietro l'inossidabile BlueGene, si piazza proprio un Cray che usa degli Opteron, infrange il muro dei 100 TFlops (101,4 ottenuti nei test, su 127,411 massimi teorici), che corrispondono a poco più di 1/3 delle prestazioni del primo in classifica (sia come picco, sia come risultato dei test), con circa 1/5 dei processori. Oserei dire che non abbiano proprio perso tutto lo smalto dei bei tempi andati nel mettere insieme dei pezzi di silicio da spremere al massimo ;)

Ma mi rendo conto che guardi alla Cray vecchia scuola come ad una specie di cattedrale nel deserto dell'innovazione che è venuta meno. Del resto, bisogna tener conto dei problemi finanziari e dei passaggi di mano dalla metà degli anni '90 (bisogna però anche dire che già da qualche anno aveva cominciato ad affiancare ai propri processori vettoriali delle cpu non vettoriali, in particolare gli Alpha), però continua ad avere delle soluzioni interessanti, e a progettarle, in parte, in casa: si sta orientando verso soluzioni Torrenza, con cpu Opteron affiancate (in "proporzioni" variabili a seconda degli scopi) da chip programmabili FPGA (altamente customizzabili), da processori multithread e specializzati (fatti in casa) e da progetti vettoriali, passando per soluzioni (in progetto) che vedono un misto delle varie soluzioni (Opteron + FPGA + Multithread Processor +Vector Processor) e arrivando a un coprocessore "Multithread Vector Processor" (dovrebbe essere un ibrido dei due approcci, capace di un qualche "trasformismo"). Ma difficilmente, ormai, si può pensare ad un approccio puramente (ed esclusivamente) vettoriale.

Comunque, mi sa tanto che non ci saranno rivoluzioni tecnologiche sbalorditive fino a quando entreremo nell'era dei computer quantistici, perchè con le tecnologie attuali praticamente s'è già visto tutto e il contrario di tutto, e si va avanti un po' con i classici corsi e ricorsi storici, ibridizzazioni di tecnologie note (più o meno sbilanciate in una direzione o in un'altra) e ottimizzazioni varie, con qualche nuovo materiale d'uso immediato o futuristico (come nanotubi e grafene) e qualche variazione sul tema (ma finchè si va avanti e si riesce a migliorare prestazioni e consumi, va bene anche così ;)).

[Edit: ho corretto un "piccolo" errore di circa 3 ordini di grandezza nel riportare i risultati della top500]