Link alla notizia: http://news.hwupgrade.it/10360.html

Pubblicata una analisi dettagliata dell'architettura del nuovo processore utilizzato per il Power Mac G5

Click sul link per visualizzare la notizia.

sarà sicuramente interessante: su lithium pubblicano articoli molto curati :)

Sembrerebbe veramente un bel Mac...

ho letto l'articolo: come al solito è molto interessante, in perfetto stile lithium... era un po' che non aggiornavano il sito con un nuovo articolo...

incorpora anche il SOI!
Nessuno sa se anche Opteron e Athlon 64 hanno tale tecnologia?

incorpora anche il SOI!
Nessuno sa se anche Opteron e Athlon 64 hanno tale tecnologia?

Si, anke i nuovi procio a 64 bit di AMD incorporano il SOI

Beh! AMD ne ha fatto il suo cavallo di battaglia!

Certo anche i processori AMD integrano la tecnologia SOI! E' stata fatta amplia pubblicità prima del debutto del 64bit di AMD, già quando sottoscrissero il contratto con la IBM!

L'articolo (ottimo, seppur "stringato"), contiene delle imprecisioni:

1) "Inoltre il G5 è a tutti gli effetti il primo processore per personal computer totalmente a 64bit (almeno in attesa di Athlon 64)."

Non mi sembra che esistano G5 attualmente in commercio. Anche HP ha annunciato di recente il supporto all'Athlon64, ma non vende ancora alcunché. Quando sarà REALMENTE possibile acquistare uno dei due sistemi, gli si potrà attribuire la palma di primo desktop a 64 bit...

2) "IBM ha progettato un core con pipeline profonde ma a differenza di quanto fatto a suo tempo da Intel con il P4, IBM ha anche pensato bene di dorare il tutto di numerose unità di elaborazione e di affrontare il passaggio ai 64bit".

Il PPC970 deriva direttamente dal Power4 di IBM, che risulta già nativamente a 64 bit. Non ha progettato un core con pipeline profonde, perché queste ultime sono già presenti nei Power4. Il PPC970 è, a tutti gli effetti, derivato dalla "castrazione" del core di un Power4 (che risulta nettamente più performante), a cui è stata aggiunta un'unità Altivec per l'elaborazione delle operazioni SIMD...

3) "Nel G5 ci sono 12 unità di elaborazione, e le pipeline hanno una lunghezza media di 16 stage (sono 9 nel G4 e 20 nel P4)."

Il G4e o G4+ possiede 7 stadi di pipeline e non 9 (il G4, invece, soltanto 4!).

E' decisamente approssimativo e fuorviante fornire una "media" degli stadi di pipeline, data la notevole complessità degli stessi.

In realtà 16 è il numero MINIMO di stadi di pipeline che un'istruzione del PPC970 deve affrontare prima di arrivare al completamento.

Per essere precisi, 16 sono gli stadi per le istruzioni intere, 17 per quelle di load/store, 21 per quelle floating point, mentre quelle Altivec vanno da un minimo di 19 (per quelle di permutazione: le meno diffuse) fino ad un massimo di 25 (per quelle che eseguono operazioni più complesse...)

4) "La gestione dell'esecuzione fuori ordine avviene a gruppi di 5 istruzioni alla volta. uno schema che semplifica e velocizza la gestione."

Detta così sembra che questo porti esclusivamente vantaggi al PPC970: in realtà l'esecuzione non è relativa alle istruzioni PowerPC vere e proprie, ma a delle istruzioni ancora più semplici in cui vengono suddivise quelle originali, esattamente come fanno gli x86 dal K5 di Amd (che per prima introdusse un core RISC-86), fino agli ultimi P4 e Hammer...

Oltre a ciò il raggruppamento e l'esecuzione di queste microistruzioni è soggetto a tanti di quei vincoli che sarebbe necessario un articolo molto lungo (e tecnico) per riuscire a comprerne il funzionamento e le implicazioni che ne derivano.

Non sono tutte rose e fiori, insomma: sono presenti anche numerose spine...

Per maggiori informazioni: http://www-1.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4.html

5) "Inoltre, il velocity engine e' in grado di allocare e portare a termine due istruzioni per colpo di clock sulle sue 4 unità di elaborazione interne. Questo comparto risulta a parità di clock inferiore all'equivalente del G4, tuttavia la grande capacità di banda e la maggiore frequenza portano il G5 in netto vantaggio."

Anche il G4 può eseguire due sole istruzioni Altivec per ciclo di clock. La differenza SOSTANZIALE rispetto al PPC970, è che può eseguirne due qualsiasi, mentre quest'ultimo soltanto una di permutazione e un'altra, più complessa, degli altri tre tipi disponibili.

Altro fattore estremamente rilevante, l'implementazione Altivec dei PPC970 non supporta dati a precisione doppia, ma soltanto singola, come erroneamente riportato...

Infine, l'elevata banda permessa dall'FSB, la cache L2 raddoppiata e la maggiore frequenza servono a compensare i difetti di cui sopra e l'elevata lunghezza delle pipeline per l'esecuzione di istruzioni Altivec.

6) "Le unità intere sono 2, operano su un register file di 32 registri a 64bit, possono ciascuna eseguire la quasi totalità delle istruzioni, semplici o complesse che siano (una leggera asimmetria per l'istruzione di divisione disponibile su una sola unità)."

In realtà le unità intere sono 3, poiché ne è presente una che si occupa dell'esecuzione delle sole istruzioni relative al registro dei flag che, pur essendo più rare delle altre, necessitano di un diverso trattamento. Un'ottima scelta che ha permesso di rendere, appunto, più "simmetriche" le altre due unità di esecuzione...

7) Sulle unità di Load & Store ci sono ancora poche informazioni che possano consentire di comprenderne appieno il funzionamento e le implicazioni prestazionali.

8) L'FSB multiplexa le linee di controllo, per cui la banda realmente disponibile è inferiore a quella teorica. Come dai dati rilasciati da IBM, un FSB a 900Mhz, che possiede un banda teorica di 7.2GB/s, in realtà ne mette a disposizione una reale di 6.4GB/s.

Oltre a ciò, ritengo che la suddivisione del bus a metà per le operazioni di lettura e scrittura comportino degli svantaggi rispetto ai tradizionali bus bidirezionali presenti nei sistemi x86. In caso di carico di lavoro "sbilanciato" in lettura o scrittura, l'FSB di un P4 a 800Mhz è in grado di arrivare a fornire una banda di 6.4GB/s in lettura o scrittura, mentre quello del PPC970 (e dei Power4, da cui deriva), al più 3.2GB/s in lettura o scrittura.

Le operazioni di lettura dalla memoria, infatti, sono mediamente quelle che impegnano di più le operazioni con l'FSB...

9) Le conclusioni sulle performance sono tutte da verificare, perché attualmente i benchmark forniti da Apple sono palesemente artefatti a proprio uso e consumo. Vengono smentiti perfino dalla stessa IBM, che alla presentazione del PPC970 allo scorso MPF ha dato dei valori di SPECint e SPECfp nettamente diversi da quelli forniti da Apple...

Vedremo quando finalmente saranno commercializzate le prime macchine G5...

adesso, non per sembrare polemico, ma potevi limitarti a segnalare solo i punti 3, 5 e 6

1) 'E sempre così, anche x la questione del primo processore a 1GHz è stata solo e soprattutto una questione di annunci (anche se AMD è effettivametne arrivata prima)

2)"Non ha progettato un core con pipeline profonde, perché queste ultime sono già presenti nei Power4"
EH? Embè? Il Power4 chi l'ha pregettato? Madre teresa?
...

4) Non mi sembra che abbiate detto velocizza la gestione INVECE DI QUEI PIRLA DI ATHLON E P4, ha solo descritto una caratteristica (superficialmete per di più)

7)Vabbuò

8)Non è nè il primo nè l'ultimo componente hardware a non raggiungere il limite teorico

9)Opinioni personali (cmq concordo)

Originally posted by "B|4KWH|T3"

adesso, non per sembrare polemico, ma potevi limitarti a segnalare solo i punti 3, 5 e 6

Anche gli altri mi sembrano egualmente importanti. Poi non ho mancato di giusticarli minuziosamente...


2)"Non ha progettato un core con pipeline profonde, perché queste ultime sono già presenti nei Power4"
EH? Embè? Il Power4 chi l'ha pregettato? Madre teresa?
...

Prova a leggerti bene l'articolo: è come se dicessero che IBM ha appositamente progettato il PPC970 in questo modo: in realtà deriva dal Power4 che funziona già ESATTAMENTE allo stesso modo.

Nulla di nuovo, insomma, mentre dall'articolo sembra l'esatto contrario...


4) Non mi sembra che abbiate detto velocizza la gestione INVECE DI QUEI PIRLA DI ATHLON E P4, ha solo descritto una caratteristica (superficialmete per di più)

Proprio perché era troppo superficiale ed ottimistica ho scritto il punto 4. :rolleyes:


7)Vabbuò

Le unità Load & Store sono estremamente importanti in un processore: se non se conoscono le caratteristiche tecniche (numero di porte, quante richieste possono accodare, se sono bloccanti o no, ecc. ecc.) non è possibile capire bene come verrà sfruttata la banda di memoria e in che modo è possibile trarne vantaggio...


8)Non è nè il primo nè l'ultimo componente hardware a non raggiungere il limite teorico

E allora? Ha dei limiti CONSISTENTI, ma sono stati omessi!

E' come se ti dicessero che la tua 500 fa 200 km/s (sulla carta), mentre arriva al massimo a 100km/h dalla 1a alla 4a e altri 100km/h in retromarcia (100+100 = 200), ma a causa del cambio le velocità vengono ulteriormente ridotte a 90km/h...:rolleyes:

Insomma, non mi pare una cosa da niente...

Ciao.

CdiMauro, commento ok, tranne per una cosa.
La scomposizione dell'ISA in istruzioni più semplici è un passaggio molto, am molto, più snello nell'architettura PowerPC di quanto possa mai esserlo nell'architettura x86, vistane la maggiore efficienza dell'istruction set.
Infatti sembra che il 90% delle istruzioni vengono tradotte in un solo microoperando, direttamente, evidentemente è un vantaggio dell'ISA RISC PowerPC.

Originally posted by "cdimauro"

L'articolo (ottimo, seppur "stringato"), contiene delle imprecisioni:

...
3) "Nel G5 ci sono 12 unità di elaborazione, e le pipeline hanno una lunghezza media di 16 stage (sono 9 nel G4 e 20 nel P4)."

Il G4e o G4+ possiede 7 stadi di pipeline e non 9 (il G4, invece, soltanto 4!).

E' decisamente approssimativo e fuorviante fornire una "media" degli stadi di pipeline, data la notevole complessità degli stessi.

In realtà 16 è il numero MINIMO di stadi di pipeline che un'istruzione del PPC970 deve affrontare prima di arrivare al completamento.

Per essere precisi, 16 sono gli stadi per le istruzioni intere, 17 per quelle di load/store, 21 per quelle floating point, mentre quelle Altivec vanno da un minimo di 19 (per quelle di permutazione: le meno diffuse) fino ad un massimo di 25 (per quelle che eseguono operazioni più complesse...)

...

Premetto che sono un frequentatore assiduo di Lithium (sito su cui è apparso l'articolo), che sporadicamente contribuisce con articoli sui processori.

Ho trovato le tue precisazioni straordinariamente valide, significative e corrette, però inserirle organicamente in un articolo significherebbe scrivere un trattato, come tu stesso affermi nel tuo post. Il che mi porta a fare due affermazioni: primo, l'articolo è comunque ottimo e corretto; secondo, riviste di settore e siti molto più blasonati spesso sono addirittura meno precisi.

Il caso più lampante che mi viene in mente è la pipeline del P4 che di fatto NON HA 20 stadi, addirittura neanche nel caso minimo. Il valore 20 viene stranamente riportato da quasi tutte le fonti (slide Intel incluse), pur essendo palesemente smentito sia dalle descrizioni discorsive della pipeline, che dai diagrammi dell'architettura interna.

Originally posted by "Hocico"

Ciao.

CdiMauro, commento ok, tranne per una cosa.
La scomposizione dell'ISA in istruzioni più semplici è un passaggio molto, am molto, più snello nell'architettura PowerPC di quanto possa mai esserlo nell'architettura x86, vistane la maggiore efficienza dell'istruction set.
Infatti sembra che il 90% delle istruzioni vengono tradotte in un solo microoperando, direttamente, evidentemente è un vantaggio dell'ISA RISC PowerPC.

Considera che già ai tempi dell'Athlon, ad esempio, la grande maggioranza delle istruzioni più usate vengono convertite in una corrispondente istruzione RISC-86 (direct path), e i compilatori che ottimizzano il codice tengono già da tempo in considerazione questo particolare. Ma anche se dovesse girare un programma "vecchio", le istruzioni più complesse (vector path) sono comunque più rare e quindi meno usate.

Con la famiglia degli Hammer (Opteron & Athlon64), Amd ha fatto un grosso lavoro "under the wood", migliorando il core RISC-86 e promuovendo anche altre istruzioni, che prima era "più complesse", allo status di "semplici". Questo lavoro ha permesso un ulteriore boost delle prestazioni, in particolare sul fronte del floating point. Di questo ne dovrebbero trarre vantaggio i compilatori nella generazione di codice per quest'architettura, sia a 32 che a 64 bit.

Non conosco l'esatta percentuale di istruzioni che adesso vengono considerate "semplici" (dovrei andare a conteggiarle dalla tabella presente in un manuale di Amd), e quindi trasformate in una sola ROP RISC-86, ma la percentuale dovrebbe essere abbastanza alta (IMHO ben oltre il 75%), e quindi tale da rendere questi processori competitivi con il Power4/PPC970 anche sotto questo punto di vista (oltre che per l'IPC...)

Originally posted by "lombardp"


Ho trovato le tue precisazioni straordinariamente valide, significative e corrette, però inserirle organicamente in un articolo significherebbe scrivere un trattato, come tu stesso affermi nel tuo post. Il che mi porta a fare due affermazioni: primo, l'articolo è comunque ottimo e corretto; secondo, riviste di settore e siti molto più blasonati spesso sono addirittura meno precisi.

Ti ringrazio per l'apprezzamento e condivido per buona parte quello che hai scritto. Non pretendo certo che un articolo sul PPC970 si trasformi in un trattato su quest'architettura, ma i punti da me riportati evidenziano soltanto che l'articolo poteva essere scritto rispecchiando maggiormente la realtà dei fatti.

Mi sembra, insomma, che esalti positivamente quest'architettura anche quando i dati dimostrano delle pecche macroscopiche e significative.

L'utente inesperto potrebbe, quindi, pensare di trovarsi di fronte ad un'architettura priva di talloni d'Achille e aprioristicamente superiore alle altre con cui si mette in competizione.


Il caso più lampante che mi viene in mente è la pipeline del P4 che di fatto NON HA 20 stadi, addirittura neanche nel caso minimo. Il valore 20 viene stranamente riportato da quasi tutte le fonti (slide Intel incluse), pur essendo palesemente smentito sia dalle descrizioni discorsive della pipeline, che dai diagrammi dell'architettura interna.

Indubbiamente. La fase di "cracking" delle istruzioni, che le porta quindi sotto forma di una o più istruzioni che vengono spedite poi alla trace cache, è un esempio lampante di tutto ciò. Questa fase occupa non pochi stadi di pipeline/cicli di clock per poter portare a compimento questo lavoro, e da nessuna parte viene conteggiata.

La questione è, però, abbastanza "pelosa", poiché, una volta convertite in istruzioni RISC, queste vengono spedite direttamente all'unità di elaborazione senza alcun altro passaggio. Al contrario, gli altri processori (Athlon/Hammer e PPC970) eseguono la fase di conversione ogni volta che un'istruzione dev'essere eseguita.

E' difficile, insomma, inquadrare il funzionamento delle pipeline del P4 secondo i classici canoni, e la confusione, pertanto, regna sovrana.

La cosa che mi disturba non poco, comunque, è il fatto che ogni volta che vengono effettuati dei confronti fra architetture diverse, è il P4 (con le sue "20" pipeline) a venir preso come modello, quando esistono altre soluzioni x86 altrettanto e a volte anche più valide: Athlon (10 stadi effettivi) e Opteron/Athlon64 (12 stadi effettivi) penso che abbiano parecchio da dire in merito...