Roadmap AMD aggiornata

Ma non funziona così! continui a insistere su cose aleatorie quei processori hanno architetture diverse forse non leggi bene? Cosa c'entra itanium che ha un'architettura TOTALMENTE diversa in cui non solo cambia la lunghezza delle istruzioni ma anche la compilazione software per eliminare gli errori di predizione dei salti e molte altre cose che avvantaggiano fortemente l'uso della cache???? Stessa cosa si può dire di hammer. Il PIV è stato progettato per salire in frequenza velocemente è proprio per questo che la cache è ridotta ma a latenza bassissima, proprio per rispondere in modo veloce. Che poi sia eccessivamente piccola è un errore progettuale che posso capire e in quel caso forse se ne avesse avuto 16k sarebbe stato meglio. Che poi sia un proggetto pietoso posso concordare pure...ma sta di fatto che è tutto l'insieme che non va!

X il resto controlla le architetture seriali in generale (e non dico sui processori) e le loro risposte alle latenze alte forse poi forse capirai quello che dico.


XCDimauro Finalmente qualcuno che sa quello che dice in modo opportuno. E' tutto sempre legato all'architettura non tutto risponde allo stesso modo alla cache o ai buffer in genere :-)

Hum... Però la lunghezza delle istruzioni nell'Itanium è anche uno dei suoi più grossi difetti (rispetto al tipo di codice generato per le architetture x86), in quanto si spreca molta banda per caricare istruzioni che, possibilmente, non possono essere eseguite assieme alle altre nel "bundle" (il compilatore genera delle NOP), e anche per il fatto che l'EPIC, essendo molto, ma molto RISC come design (prevede, se non ricordo male un solo tipo d'indirizzamento verso la memoria), richiede più istruzioni per "emulare" il lavoro svolto da una sola istruzione x86, comportando quindi un aumento notevole delle dimensioni del codice (la dimensione media di un'istruzione x86 è 1,8 byte).

Quindi parte della maggiore cache L3 viene comunque "sprecata" per i suddettivi motivi. E' anche per questo che tale cache ha dimensioni spaventose (le prossime saranno da 6Mb! )

Si sarà capito che a me non piace molto l'architettura dell'Itanium, vero?

[B]

Infatti, sono d'accordo con te. Per la cache da aumentare, beh, è sicuramente una cosa che Intel deve fare (e farà perché 8K di L1, anche se molto veloce, è un limite troppo grande per il codice generico. La sfida sarà vedere se riuscirà a costruirne una da 32K (così è stato annunciato) mantenendo le stesse proprietà (latenza, banda, porte, ecc.): non è mica facile... Ma ormai i chip stanno arrivando ad integrare centinaia di milioni di transistor, quindi direi che la cosa potrebbe essere fattibile...

[B]

Sono ampiamente d'accordo con te. Tra l'altro vorrei far notare che i 20 cicli degli stage delle pipeline sono uno "specchietto per le allodole", perché prevedono che le istruzioni siano già presenti nella trace cache. Quando non lo sono, bisogna sempre aggiungere il tempo necessario per decodificarle (una volta caricate dalla memoria), e questo incide ancora di più nelle basse performance del P4, come pure incide il fatto che la trace cache riesce a spedire alle unità di elaborazione al massimo 3 micro-op per ciclo di clock (quanto l'Athlon). A questo punto mi chiedo quale vantaggio reale abbia apportato l'introduzione di questa (troppo) osannata trace cache...

Beh, force ci stiamo lasciando prendere un po' troppo la mano con queste discussioni troppo tecniche...

[B]

Grazie per i complimenti, che comunque rigiro anche te.

Perché poni dei limiti alle capacità della gente che frequenta il forum?

[B]

Consentimi di dissentire: è evidente che il Clawhammer, coi suoi 256Kb di cache L2, è destinato al mercato consumer, e quindi deve costare poco. E' questo il principale motivo per cui integrerà tale quantità di cache: per ridurre i costi di fabbricazione sia per gli utenti finali, che non possono spendere sempre dei milioni per il solo processore. Per contro, un Hammer con 256Kb di cache sarà un po' "azzoppato" a livello di performance rispetto ai suoi attuali concorrenti (tra cui persino il Burton ), che possono vantarne il doppio (tenendo sempre presente il discorso fatto finora fra architettura/cache/prestazioni!).

Comunque Amd ha già annunciato processori della famiglia Hammer con cache fino ad 1Mb per il 2003, quindi non c'è da temere che possa perdere il carro delle prestazioni migliori. Semplicemente tali processori sono destinati a fasce diverse di mercato (server o chi vorrà spendere di più... )

[B]

Non è che abbia paura, perché ricordiamo comunque che è un colosso di dimensioni spaventose paragonato ad Amd. Deve continuare a fare il suo gioco per tornare a dominare il mercato dei processori. Tutto qui...

[B]

Per fortuna che ti sei corretto nell'ultima parte... Altrimenti Super-Vegeta ti avrebbe spedito a romper le scatole a Re Kaioh e alla sua scimmietta...

[B]

Purtroppo la pubblicità martellante e le conoscenze ridotte della "massa" non possono che privilegiare i Ghz al lavoro effettivamente svolto. Comunque non condanno chi compra Intel perché "ha più Ghz": non si può certo pretendere che ognuno faccia un corso di "Architettura dei sistemi di elaborazione" prima di comprare un processore. In questo la colpa è anche e soprattutto di Amd, che non ha saputo pubblicizzare adeguatamente i suoi prodotti, spiegando chiaramente e in modo semplice il perché del suo P-Rating...

[B]

Veramente sono stati ben altri a fare scuola: IBM, HP, Digital, Sun, ecc. nel campo dei processori, e tantissime università in generale.

E' anche vero che Amd ha saputo tirare fuori soluzioni innovative relativamente al miglioramento dell'architettura x86. E se Intel è rimasta indietro nella ricerca, la colpa è certamente tutta sua, che ha sempre fatto il bello e il cattivo tempo nel mercato dei processori x86, e non avrebbe mai pensato che una società che fino ad allora aveva soltanto cercato di scopiazzare, avrebbe tirato fuori (in 3 anni di ricerca e sviluppo) un design talmente innovativo e performante da tagliarla fuori dalla corsa ai Mhz e alle prestazioni.

Ha subito il colpo e si è messa subito in moto, col P4, per cercare di risollevare la sua immagine. E c'è riuscita con i suoi ultimi processori della serie P4 (con cache L2 da 512Kb e bus a 533Mhz).

Questo comunque, non può che far piacere a noi utenti, perché da una competizione sempre più serrata non possiamo che trarne benefici. Lunga vita ad Amd, Intel, e chiunque altro vorrà entrare in questo mercato!

[B]

Vorrei sapere in base a quali dati puoi affermare una cosa del genere. Ti ricordo che ormai anche i processori con architettura x86 hanno integrato moltissimi concetti sviluppati nelle architetture RISC (anzi, sono proprio dei RISC all'interno ), come l'esecuzione fuori ordine e speculativa, la ridenominazione dei registri, ecc. ecc.

I processori della serie PowerPC riescono a processare SULLA CARTA 4 istruzioni intere e 2 FP, ma dalla teoria alla pratica ne passa... Il codice che devono eseguire per, che sò, emulare un 68000, si presta ad essere eseguito più o meno allo stesso modo in entrambe le architetture, perché non si può "parallelizzare" più di tanto.

Poi ti ricordo che Motorola, per arrivare a quella fatidica soglia del Ghz, ha DOVUTO aumentare gli stage della pipeline, portandoli da 4 a 7, con evidenti perdite di performance (in parte dei test, il G4/4 stadi a 400Mhz surclassa il G4/7 stadi a 700Mhz...)

Quindi cerchiamo di non pronunciare delle affermazioni che, estrapolate da uno specifico contesto, non possono che ritenersi assolutamente arbitrarie...

[B]

Anche a me! Ottimizzazione -> Maggiori performance -> Più concorrenza -> Costi minori per gli utenti (che comunque hanno processori più potenti...)

[B]

Sgorgle! Lasciamo perdere... Vale sempre il discorso di sopra: lasciamo da parte certe affermazioni (anche se condivido lo spirito della tua frase... )

Saluti

Ed ecco puntuale la domanda che faccio ad ogni aggiornamento di roadmap AMD: si suppone che il Barton resti compatibile con mobo kt266a?

Essendo 1 processore VLIW (Very Long Instruction Word)o EPIC come lo chiama Intel.....è chiaro che debba inserire dei NOP.....
La vera forza di questo tipo di processori è che si sposta tutta l'ottimizzazione a livello di compilatore in modo di avere 1 codice già esattamente predisposto per le massime performance.....questo permette di spostare a livello di compilazione ciò che viene normalmente fatto nel processore......
Grosso limite è che si deve imporre 1 compilatore x quel processore e solo x quel processore.........la tecnica VLIW è stata sperimentata in ricerca molti anni fà.....

Piacere


MMMMM........vedremo

[B]

Sono ampiamente d'accordo con te. Tra l'altro vorrei far notare che i 20 cicli degli stage delle pipeline sono uno "specchietto per le allodole", perché prevedono che le istruzioni siano già presenti nella trace cache. Quando non lo sono, bisogna sempre aggiungere il tempo necessario per decodificarle (una volta caricate dalla memoria), e questo incide ancora di più nelle basse performance del P4, come pure incide il fatto che la trace cache riesce a spedire alle unità di elaborazione al massimo 3 micro-op per ciclo di clock (quanto l'Athlon). A questo punto mi chiedo quale vantaggio reale abbia apportato l'introduzione di questa (troppo) osannata trace cache...

Beh, force ci stiamo lasciando prendere un po' troppo la mano con queste discussioni troppo tecniche...

[B]

Grazie per i complimenti, che comunque rigiro anche te. [/quote]
Ciao a tutti...........

Intel non potrà salire in eterno in frequenza il suo progetto pIV ha dei limiti molto seri che risiedono nella tecnologia produttiva.
Saranno costretti a modificare il processo produttivo costantemente per avere prestazioni decenti.

Per contro gli athlon attuali dissipano davvero troppo calore, e amd nel tentativo di ridurre i costi restringe al massimo l'area del core creando ulteriori problemi (e mettendosi contro il mondo degli overclockers). Con il sistema SOI l'athlon sarebbe salito molto molto più facilmente in frequenza con minore dissipazione termica.
Intel ha fatto male a snobbare questa tecnologia, amd avrà un forte vantaggio una volta integratala nel sistema produttivo. Un incremento del 20% della legge di moore e non è poco dato che è portabile a ogni livello produttivo.

Se le motherboard sono compatibili col Toro, dovrebbero esserlo anche con il Burton, che dovrebbe avere semplicemente la cache raddoppiata...

Infatti, ma lo spreco è troppo grande: anche una sola NOP spreca 5 volte lo spazio di una NOP di un x86, e tiene pure impegnata qualcha unità dell'Itanium

[B]

Consentimi di dubitare di quest'affermazione: un compilatore può avere soltanto una visione "statica", e non "dinamica" dell'esecuzione di un programma, per cui potrà ottimizzare il codice soltanto a livello delle istruzioni che, in quel contesto, gli sembra siano le migliori.

In ogni caso non è affatto sicuro che il codice compilato sia comunque quello che offre le migliori performance: realizzare un compilatore che genera codice che abbia il massimo delle performance è un problema NP-Completo (cioé "intrattabile", dal punto vista informatico), per cui, a livello d'implementazione, i compilatori possono avere soltanto delle (buone) approssimazioni...

[B]

E' proprio in questo che, a mio avviso, hanno sbagliato Intel e HP nel progettare l'EPIC: è difficile, come ho già detto, generare codice fortemente ottimizzato, di per sé. Per avere buoni compilatori per l'Itanium ci vorrà molto tempo, e comunque il suo grande limite è rappresentato dal fatto che il processore sarà costretto ad eseguire il codice sempre allo stesso modo, come il compilatore ha pensato bene di fare. Non è possibile eseguire istruzioni fuori ordine, né ricorre all'esecuzione speculativa, perché tutto è già stato deciso "in partenza". Al contrario, l'Hammer e tanti altri processori permettono di "variare" l'esecuzione del codice in base al "momento", quando "capiscono" di poter eserguire certe istruzioni e altre no, quando vedono che un'istruzione è "bloccata" perché il processore deve accedere alla ram (e qui l'Itanium non può fare proprio nulla, perché non si possono predire, in fase di compilazione, i cache miss, come pure l'andamento dei salti condizionali).

Insomma, come avrai potuto ben capire, non approvo assolutamente questa scelta architetturale: i vantaggi sono troppo pochi rispetto agli svantaggi...

[B]

Non è assolutamente il caso: lo GNU può compilare benissimo per qualunque architettura, EPIC inclusa. E' sufficiente che il back-end del compilatore sia a conoscenza di tutte le sue restrizioni e i suoi vantaggi.



E' vero, ma questo non vuol dire niente... Attualmente è una "novità", e ci vorrà ancora del tempo per accettarla e poterla rendere appetibile per il mercato consumer... Se mai ci riusciranno...

Saluti

Del P4 non trovo giustificazione logica la presenza di due ALU che viaggiano al doppio della frequenza del processore. In teoria dovrebbero permettere di eseguire 4 operazioni per ciclo di clock, ma la trace cache riesce a spedirne al più 3 per ciclo, quindi un'unità non sarà mai utilizzata nel suo 1/2 ciclo di clock. Questa per me è una cosa veramente ridicola: avrebbero potuto, invece, pensare di aggiungere il barrel shifter presente nel "vecchio" P III, che aiuta tantissimo il codice che fa uso di shift per velocizzare l'esecuzione.

Oggi, sul P4, una banale SHL è molto più lenta di qualunque altra operazione aritmetica/logica (moltiplicazione e divisione escluse, ovviamente), e lo stesso dicasi per una LEA in cui sia presente il fattore moltiplicativo, un tempo impiegata per velocizzare il codice sfruttando l'AGU, è diventata molto più lenta. E tutto il vecchio codice, che usa una quantità impressionante di questi "trucchetti", si trova ovviamente svantaggiato...

Che senso ha, quindi, avere due unità ALU che viaggiano al doppio della frequenza, quando non le sfrutti in realtà? Queste rappresentano, come giustamente hai fatto notare, uno dei grossi limiti che impedirà al P4 di salire di più in frequenza in futuro.

Mah Per me, oltre al processo produttivo, dovrebbero rivedere bene TUTTO il progetto del P4...

E' chiaro che sarà meno overclockabile: lo scotto per il maggior numero di transistor si dovrà pur pagare in qualche modo, oltre all'aumento della dimensione del core del processore.

Ma non penso che un Toro potrà salire tanto da annullare i benefici della maggior cache del Barton, altrimenti sarebbe molto più conveniente per Amd puntare tutto sul Toro, che gli costa di meno e non richiede lo sviluppo di un nuovo processore (anche se in buona parte ricicla il progetto precedente)...

IMHO, il Barton sarà sicuramente superiore, anche considerando il fattore OC...