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

Nuove informazioni sui futuri processori AMD della famiglia Hammer, nelle versioni desktop, server e mobile

Click sul link per la notizia completa.

il 1800+ 0.13 si vedrà set o ott?

Intel,incomincia a tremare
AMD Rulez

Mamma quanta roba :)
Ma è possibile che il semplice raddoppio della memoria di cache L2 giustifichi un simile innalzamento delle prestazioni con l'AMD? Mi riferisco al fatto che alla stessa frequenza reale il Tbred sia considerato 2000+ e il Barton 2600+!!!

fino adesso hanno sempre ben calcolato le prestazioni finali
^__^'
fa ben sperare...

Si in effetti anche a me sembra strano ,ma dato che finor a l'han calcolato abbastanza giusto...

basti vedere intel quando ha raddoppiato la cache nel p4

Ma quale amd rulez e amd rulez forse una volta,ma ormai l'andazzo che ha preso amd non mi piace proprio.Insomma come si fa ad uscire con l' hammer ancora a 256kb, quando anche il barton (che costera molto di meno) ne ha 512.BOH non dubito che sara un mostro però già che c' erano potevano raddopiarla la cache no?

Per me, AMD col suo TPI del caz... sta prendendo per i fondelli (cioè per il cul...) migliaia di suoi ormai ex estimatori. Mi fa ridere pensare che un processore a 2000 MHz reali passi dal Thoro al Barton (entrambi a 0.13 micron) ad un incremento di TPI di ben 600+ solo perchè ha raddoppiato la cache L2 e senza cambiamenti nè nell'archittettura del core nè del FSB!
AMD pagherà cara questa scelta di marketing....

Originariamente inviato da Scanseby
[B]Per me, AMD col suo TPI del caz... sta prendendo per i fondelli (cioè per il cul...) migliaia di suoi ormai ex estimatori. Mi fa ridere pensare che un processore a 2000 MHz reali passi dal Thoro al Barton (entrambi a 0.13 micron) ad un incremento di TPI di ben 600+ solo perchè ha raddoppiato la cache L2 e senza cambiamenti nè nell'archittettura del core nè del FSB!
AMD pagherà cara questa scelta di marketing....

Mah, non credo che AMD sia così avventata, probabilmente hanno guardato come vanno i campioni e li hanno classificati... dopotutto non possono permettersi di fare un xp 2500+ che va meglio del 2600+... o no?

Per johnvs.
La tua osservazione è pertinente. Ma tu credi davvero che un Athlon delle serie Thoro con TPI di 2500+ e 2000 Mhz reali sia meno perfornmante di un Barton catalogato come 2600+ ma che ha solo 1667 MHz reali???
Mi chiedo se AMD faccia i passi del gambero oppure più semplicemente non riesce ad aumentare di frequenza così facilmente come fa Intel col suo PIV che a Natale avrà raggiunto i 3000 MHz reali...

sempre i soliti discorsi..... hammer con 512kb di cache? oltre che costare tanto, non ne ha bisogno.... la cache alta non è sinonimo di alte prestazioni! Deve essere sfruttata bene. Si possono ottenere ottimi risultati con 256 e una buona architettura (E qui amd insegna). Cmq il barton avra sicuramente dei cambiamenti a livello di architettura per poter sfruttare i 512kb di cache. Il che potrebbe giustificare l'aumento di 600 tpi. E cmq è un prodotto che uscirà tra minimo 4 mesi... gia iniziamo a criticare senza avere niente in mano?

è inutile polemizzare...!! Non c'è storia,il barton sarà una vera belva! Abbiate fiducia!!!

Ho la sensazione che barton non verra' costruito, ma verra' tirato per il collo il thoro in attesa del lancio del claw, rifare ancora le maschere dopo tre mesi per amd sarebbe un salasso

Originariamente inviato da ^[D]r[3]1[K]^
[B]sempre i soliti discorsi..... hammer con 512kb di cache? oltre che costare tanto, non ne ha bisogno.... la cache alta non è sinonimo di alte prestazioni! Deve essere sfruttata bene. Si possono ottenere ottimi risultati con 256 e una buona architettura (E qui amd insegna). Cmq il barton avra sicuramente dei cambiamenti a livello di architettura per poter sfruttare i 512kb di cache. Il che potrebbe giustificare l'aumento di 600 tpi. E cmq è un prodotto che uscirà tra minimo 4 mesi... gia iniziamo a criticare senza avere niente in mano?
Ti sbagli grossa quantità di cache E' sinonimo di prestazioni migliori ( se vuoi ti posso dire anche la formula con cui cambia l'accesso alla ram al variare della cache)....e ti dirò di +...+ la ram diventa vasta e + si ha bisogno di cache altrimenti i cache miss aumentano...siccome nel 2003 probabilmente chiunque comprerà 1 hammer ci metterà 512mega.....direi che anch'io avrei preferito e di molto 512K di cache....l'unico motivo x cui non c'è è che ci verrà messa dopo...altrimenti non cambieresti la CPU ;), secondo me chiaramente.....inoltre la cpu Hammer MP esisterà in versione anche da 1Mbyte di cache probabilmente con 512k nessuno la avrebbe comprata così invece ....:)
Con poca cache, i cache miss aumentano e di conseguenza si accede di + alla RAM, che è lentissima rispetto a 1 processore a 2Ghz.....e che fà perdere 1 bordello di tempo....
x il resto non si stà criticando si stanno esprimendo semplicemente dei desideri e cioè quello di avere 512K, di cache

Originariamente inviato da +Benito+
[B]Ho la sensazione che barton non verra' costruito, ma verra' tirato per il collo il thoro in attesa del lancio del claw, rifare ancora le maschere dopo tre mesi per amd sarebbe un salasso
il thoro ha una forma diversa dal vecchio palomino....appunto xché è già Barton compatibile...cioè mettendo da 1 lato 256K di cache si ottiene dal thoro il barton .... spero di essermi spiegato....

Originariamente inviato da ErPazzo74
[B]
Ti sbagli grossa quantità di cache E' sinonimo di prestazioni migliori ( se vuoi ti posso dire anche la formula con cui cambia l'accesso alla ram al variare della cache)....e ti dirò di +...+ la ram diventa vasta e + si ha bisogno di cache altrimenti i cache miss aumentano...siccome nel 2003 probabilmente chiunque comprerà 1 hammer ci metterà 512mega.....direi che anch'io avrei preferito e di molto 512K di cache....l'unico motivo x cui non c'è è che ci verrà messa dopo...altrimenti non cambieresti la CPU ;), secondo me chiaramente.....inoltre la cpu Hammer MP esisterà in versione anche da 1Mbyte di cache probabilmente con 512k nessuno la avrebbe comprata così invece ....:)
Con poca cache, i cache miss aumentano e di conseguenza si accede di + alla RAM, che è lentissima rispetto a 1 processore a 2Ghz.....e che fà perdere 1 bordello di tempo....
x il resto non si stà criticando si stanno esprimendo semplicemente dei desideri e cioè quello di avere 512K, di cache

Finalmente qualcuno che ha colto il senso delle mie parole e che ha fornito una valida spiegazione sulla cache L2.Volevo solo dire che se ne mettono 512 sul barton non vedo come non possano metterne la stessa quantita anche sull' hammer(molto+costosoeperformante)

Ragazzi Ragazzi....
Dopo un lungo silenzio di AMD pensavo ke volesse + competere con Intel...ma......
Si deve aver paura sempre del cane ke nn Abbaia!!!
Bye

Originariamente inviato da ^[D]r[3]1[K]^
[B]sempre i soliti discorsi..... hammer con 512kb di cache? oltre che costare tanto, non ne ha bisogno.... la cache alta non è sinonimo di alte prestazioni! Deve essere sfruttata bene. Si possono ottenere ottimi risultati con 256 e una buona architettura (E qui amd insegna). Cmq il barton avra sicuramente dei cambiamenti a livello di architettura per poter sfruttare i 512kb di cache. Il che potrebbe giustificare l'aumento di 600 tpi. E cmq è un prodotto che uscirà tra minimo 4 mesi... gia iniziamo a criticare senza avere niente in mano?
Non condivido pienamente il tuo pensiero sulla cache, ed inoltre, come già + volte affermato sdai principali siti mondiali, Xp=Thoro=Barton a livello di architettura
Xp : core Xp a 0.18 micron
Thoro : core Xp a 0.13 micron
Barton : core Xp a 0.13 micron e L2 cache raddoppiata; nessuna ulteriore modifica architetturale, esattamente come è stato nel passaggio da P4 Willy a Northwood.
Proprio perchè non ce l'abbiamo ancora in mano è inutile speculare su caratteristiche che non avrà mai.

Byex ;)

Vedo con grande stupore che quasi tutti hanno dimenticato che il barton integra la tecnologia SOI non ha solo la cache raddoppiata. E questo significa un aumento della velocità; i circuiti in tecnologia SOI sono più veloci a parità di dimensioni degli equivalenti CMOS.

Cmq chi dice che la cache porta ad un immediato aumento di prestazioni sbaglia. La cache troppo ampia può portare ad un forte aumento della latenza cosa a volte svantaggiosa. Se il PIV integra 8k di cache al primo livello è proprio per questa ragione. L'hammer ha un'architettura completamente diversa e integra in se anche il controller ram, non possiamo sapere se i benefici di 512k di cache sarebbero al confronto apprezzabili.
vedremo....

Il Barton, nei piani originari di Amd, doveva integrare anche la tecnologia SOI, però già da un bel po' di tempo è stato annunciato che avrà semplicemente la cache L2 raddoppiata. La tecnologia SOI sarà, quindi, esclusivo appannaggio degli Hammer...

[B]Cmq chi dice che la cache porta ad un immediato aumento di prestazioni sbaglia. La cache troppo ampia può portare ad un forte aumento della latenza cosa a volte svantaggiosa. Se il PIV integra 8k di cache al primo livello è proprio per questa ragione. L'hammer ha un'architettura completamente diversa e integra in se anche il controller ram, non possiamo sapere se i benefici di 512k di cache sarebbero al confronto apprezzabili. Vedremo....

Infatti se la cache L2 del Barton, pur raddoppiandone la quantità, continuerà ad avere la stessa latenza (il che, a mio avviso, è abbastanza plausibile), le performance non possono che subire dei miglioramenti. Stesso discorso per l'Hammer, che in parte eredita il design dell'Athlon.

Comunque, quando arriveranno questi benedetti processori potremo finalmente sapere la verità...

eheheheh!
non vedo l'ora di vederli testati e vedere se aveva ragione l'amd o no, peccato dover aspettare tutta l'estate...

^___^

Non so se dico una bestialita' ma essendo il Barton un Tbred con il doppio di cache L2, dovrebbe prestarsi meno a qualunque tipo di OC. Non e' che in questo modo un Tbred in OC potrebbe ridurre il divario di prestazioni con il Barton di pari frequenza rendendolo meno "appetibile"?

Originariamente inviato da Super-Vegèta
[B]Vedo con grande stupore che quasi tutti hanno dimenticato che il barton integra la tecnologia SOI non ha solo la cache raddoppiata. E questo significa un aumento della velocità; i circuiti in tecnologia SOI sono più veloci a parità di dimensioni degli equivalenti CMOS.

Cmq chi dice che la cache porta ad un immediato aumento di prestazioni sbaglia. La cache troppo ampia può portare ad un forte aumento della latenza cosa a volte svantaggiosa. Se il PIV integra 8k di cache al primo livello è proprio per questa ragione. L'hammer ha un'architettura completamente diversa e integra in se anche il controller ram, non possiamo sapere se i benefici di 512k di cache sarebbero al confronto apprezzabili.
vedremo....
ci sono 2 falle in quel che dici:
1) cos'è la latenza x te? guarda che la latenza è composta x la maggior parte da il tempo di risposta che ovviamente rimane =.....
2) infatti si vede come và il P4.......ed anche intel ne è cosciente visto che vuole triplicare la dimensione della cache L1...fidati + cache + velocità.
3)In effetti non avevo tenuto conto del controller integrato...xò 1 cache miss è sempre 1 cache miss...cioè ti porta pur sempre in RAM...che anche se è + veloce come tempo di latenza grazie al controller integrato è sempre qualche ordine + lenta delle cache L1 e L2........

Allora qui stiamo a discutere di cose che neanche dovremmo sapere da che parte cominciare a commentare dato che dietro all'Hammer ci ha lavorato per mesi un equipe di ingenieri di certo ad un livello piu alto del nostro e di un ingeniere elettronico di una ditta qualunque (qui intendo che AMD come Intel se li sceglie), Quindi se all'Hammer gli hanno messo 256k di chace e perche data la potenza della cpu per adesso non ne serve di più se no andrebbe troppo avanti ad Intel sulle prestazioni e rimarrebbe per troppo tempo con una cpu uguale! Quindi a fine 2003 probabilmente vedremo un Hammer 512k superare Intel in prestazioni ma questo e normale!!!
La Intel il suo P4 lo sta modificando continuamente tra bus e chace come se avesse paura di AMD!
Poi secondo me e vero che la cache e sinonimo di prestazioni le prove le abbia mo sul Barton ma le prestazioni aumentano le l'architettura lo permette!
Per quanto riguarda i 2600+ a 1667mhz sono giusti e inutile criticare AMD perche la Intel e oramai hai 3ghz mentre AMD no mi sembra ora di capirla dopo un anno che non bisogna piu guardare la fraquenza!!!Azz
AMD nella architettura fa scuola!!! voglio ricordare che i powerPC hanno appena superato da qualche mese il 1ghz e vanno almeno il doppio dei P4 2.53ghz Quindi a me fa piacere che AMD si impegni nella ottimizzare la tecnica!
Anche un pentium166 a 20ghz va come un 1600+ sarebbe troppo facile ragionare come gli americani che alzare la potenza della auto aumentano la cilindrata!

Ciao a tutti

scusate gli errori ortagrafici ma sono svizzero e parlo anche tedesco quindi faccio degli errori heehheeh
;)

Originariamente inviato da Scanseby
[B]Per johnvs.
La tua osservazione è pertinente. Ma tu credi davvero che un Athlon delle serie Thoro con TPI di 2500+ e 2000 Mhz reali sia meno perfornmante di un Barton catalogato come 2600+ ma che ha solo 1667 MHz reali???
Mi chiedo se AMD faccia i passi del gambero oppure più semplicemente non riesce ad aumentare di frequenza così facilmente come fa Intel col suo PIV che a Natale avrà raggiunto i 3000 MHz reali...


Mah, io non mi sbilancio, dopotutto se sarà più veloce il 2500+ farà bene, altrimenti ci compreremo tutti il 2500+ che andrà più veloce e costerà meno;)

vedrete........
con 512k di cache i TB voleranno.......
ricordate i vekki P3T
un 1133 stava dietro a un TB 1400 :)

provare per credere :)
IMHO se AMD dice che un 1666 Barton è un 2600 vedrai che sarà così.......magari nn in tutte le applicazioni ma nella maggior parte :)

BYEZZZZZZZZZ

So benissimo cos'è la latenza cmq grazie per l'eventuale lezione...
Non è "assolutamente" vero che + cache è "sempre" uguale a + prestazioni non c'è alcuna falla in ciò che dico.
Dipende tutto dall'architettura, il PIV senza modifiche architetturali non potrebbe integrare quantità di cache superiori (salvo errori progettuali) o avrebbe prestazioni inferiori con la latenza attuale. E l'architettura del PIV si può anche se molto impropriamente assimilare ad un'architettura seriale in cui i dati vengono processati ad alta velocità, più che pensare a molti dati contemporanei. Filosofia opposta per l'athlon invece. Dell'hammer per ora si sa molto poco...

In un sistema seriale un buffer troppo grande porta a rallentamenti anzichè vantaggi a meno che non abbia latenza bassa. Non sempre una cache o un buffer maggiori portano vantaggi. Che sia uguale la latenza nell'hammer è tutto da vedere non sappiamo che tipo di cache integrerà.

X il resto per quanto ne so il barton dovrebbe avere tecnlogia SOI

Originariamente inviato da Super-Vegèta
So benissimo cos'è la latenza cmq grazie per l'eventuale lezione...
Non è "assolutamente" vero che + cache è "sempre" uguale a + prestazioni non c'è alcuna falla in ciò che dico.


In verità si......basta guarda i processori RISC...hanno quantità di cache elevate......e poi Itanium 2 che dovrebbe averne addirittura 6M di 3rzo livello.....
Basta guardare indietro al K6 II e III e III+......
Chiaramente per confrontare tutte queste cache si deve guardare alla loro "velocità" cioè siccome sono tutte sincrone con il clock della CPU, quelle di cui parliamo noi, allora si può dire + cache + prestazioni....è chiaro che se aggiungi cache + lenta allora si che la latenza aumenta.....ma sappiamo benissimo che qui si parla (o almeno io così intendevo) di cache sincrona al clock della CPU.....

[B]
Dipende tutto dall'architettura, il PIV senza modifiche architetturali non potrebbe integrare quantità di cache superiori (salvo errori progettuali) o avrebbe prestazioni inferiori con la latenza attuale. E l'architettura del PIV si può anche se molto impropriamente assimilare ad un'architettura seriale in cui i dati vengono processati ad alta velocità, più che pensare a molti dati contemporanei. Filosofia opposta per l'athlon invece. Dell'hammer per ora si sa molto poco...


Tutte le CPU da pentium in poi sono superpipelined cioè seriali.....tipo "catena di motaggio"......dimmi allora che l'Athlon ha una catena di montaggio in + ;)


In un sistema seriale un buffer troppo grande porta a rallentamenti anzichè vantaggi a meno che non abbia latenza bassa. Non sempre una cache o un buffer maggiori portano vantaggi. Che sia uguale la latenza nell'hammer è tutto da vedere non sappiamo che tipo di cache integrerà.

:confused: :confused: :confused: :confused:
In base a cosa??
[B]
X il resto per quanto ne so il barton dovrebbe avere tecnlogia SOI
Da una roadmap di tempo fà si vide chiaramente che rispetto alla precedente al Barton era stata lasciata la .13m ma non SOI

Originariamente inviato da ErPazzo74
[B]
2) infatti si vede come và il P4.......ed anche intel ne è cosciente visto che vuole triplicare la dimensione della cache L1...fidati + cache + velocità.

Le minori prestazioni del P4, a mio avviso, sono principalmente dovute all'esagerata lunghezza delle sue pipeline: 20 stadi sono veramente troppi senza un sistema di branch prediction che si avvicini realmente al 99%.
L'altro fattore, come giustamente facevi notare, è la dimensione della cache L1, che è troppo piccola. Ma questo non affligge certo le applicazioni multimediali, per migliorare le quali è stato appositamente progettato. E difatti, pur avendo una misera cache L1 di soli 8K, ma con una latenza di soli 2 cicli di clock (contro i 3 dell'Athlon, se non ricordo male. Non ho i data sheet sotto mano purtroppo :)), riesce a rispondere molto bene proprio in questi casi.

Per tutto il resto, per il codice "general purpose", il progetto fa veramente acqua, come hai già detto.

Comunque più cache non necessariamente implica maggiori performance: spesso le cache più grandi hanno delle latenze maggiori, per cui posso arrivare a rendere anche meno di cache più piccole, ma con latenze estremamente aggressive. Oltre a questo conta anche la banda che riescono ad erogare, e quante richieste (porte) in lettura e/o scrittura possono soddisfare contemporaneamente per ogni ciclo di clock.

Insomma, per farla breve, non è così semplice valutare l'impatto della dimensione di una cache, perché il suo "design" è strettamente legato al progetto dell'architettura di cui fa parte, e, come ho già detto, le variabili in gioco sono diverse e comportano impatti diversi per condizioni di esecuzione diverse (il codice per il multimedia è MOLTO diverso dal codice per la valutazione della strategia ottimale per un gioco di scacchi).

[B]3)In effetti non avevo tenuto conto del controller integrato...xò 1 cache miss è sempre 1 cache miss...cioè ti porta pur sempre in RAM...che anche se è + veloce come tempo di latenza grazie al controller integrato è sempre qualche ordine + lenta delle cache L1 e L2........

E' vero, ma le cache possono anche tenere "pendenti" più richieste di accesso alla ram, sospendendone l'esecuzione e "riattivandola" all'arrivo del dato, oppure possiedono più "porte" di lettura/scrittura, ecc. ecc. ecc. Insomma, ripeto, bisogna vedere bene com'è stata costruita la cache e i valori di tutti questi parametri prima di valutarne la bontà con i diversi tipi di codice.

Altrimenti, non mi spiego come mai le performance dei PA-RISC di HP siano più o meno a livelli degli avversari (IBM/Power, Sun/Sparc, Digital/Alpha), pur avendo una cache L1 veramente enorme (a seconda dei modelli arriva anche a 2Mb!!!).

Per Vegeta: il Barton inizialmente doveva essere SOI (nelle prime roadmap era riportato questo), ma ultimamente è stato annunciato diversamente da parte proprio dell'Amd.

Saluti

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 :-)

Originariamente inviato da Super-Vegèta
[B]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????

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]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.

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]Che poi sia un proggetto pietoso posso concordare pure...ma sta di fatto che è tutto l'insieme che non va!

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]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 :-)

Grazie per i complimenti, che comunque rigiro anche te. :)

Originariamente inviato da Emotionengine
[B]Allora qui stiamo a discutere di cose che neanche dovremmo sapere da che parte cominciare a commentare dato che dietro all'Hammer ci ha lavorato per mesi un equipe di ingenieri di certo ad un livello piu alto del nostro e di un ingeniere elettronico di una ditta qualunque (qui intendo che AMD come Intel se li sceglie)

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

[B]Quindi se all'Hammer gli hanno messo 256k di chace e perche data la potenza della cpu per adesso non ne serve di più se no andrebbe troppo avanti ad Intel sulle prestazioni e rimarrebbe per troppo tempo con una cpu uguale! Quindi a fine 2003 probabilmente vedremo un Hammer 512k superare Intel in prestazioni ma questo e normale!!!

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]La Intel il suo P4 lo sta modificando continuamente tra bus e chace come se avesse paura di AMD!

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]Poi secondo me e vero che la cache e sinonimo di prestazioni le prove le abbia mo sul Barton ma le prestazioni aumentano le l'architettura lo permette!

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]Per quanto riguarda i 2600+ a 1667mhz sono giusti e inutile criticare AMD perche la Intel e oramai hai 3ghz mentre AMD no mi sembra ora di capirla dopo un anno che non bisogna piu guardare la fraquenza!!!Azz

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]AMD nella architettura fa scuola!!!

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]voglio ricordare che i powerPC hanno appena superato da qualche mese il 1ghz e vanno almeno il doppio dei P4 2.53ghz

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]Quindi a me fa piacere che AMD si impegni nella ottimizzare la tecnica!

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

[B]Anche un pentium166 a 20ghz va come un 1600+ sarebbe troppo facile ragionare come gli americani che alzare la potenza della auto aumentano la cilindrata!

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? :p

Originariamente inviato da cdimauro


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).

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à.....
[B]
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? ;)


Piacere ;)


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... ;)

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.

Originariamente inviato da Acrobat
[B]Ed ecco puntuale la domanda che faccio ad ogni aggiornamento di roadmap AMD: si suppone che il Barton resti compatibile con mobo kt266a? :p

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

Originariamente inviato da ErPazzo74
[b]
Essendo 1 processore VLIW (Very Long Instruction Word)o EPIC come lo chiama Intel.....è chiaro che debba inserire dei NOP.....

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 ;)

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.....

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]questo permette di spostare a livello di compilazione ciò che viene normalmente fatto nel processore......

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]Grosso limite è che si deve imporre 1 compilatore x quel processore e solo x quel processore.........

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.

[B]la tecnica VLIW è stata sperimentata in ricerca molti anni fà.....



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

Originariamente inviato da Super-Vegèta
[B]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.


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... :)

Originariamente inviato da P V
[B]Non so se dico una bestialita' ma essendo il Barton un Tbred con il doppio di cache L2, dovrebbe prestarsi meno a qualunque tipo di OC. Non e' che in questo modo un Tbred in OC potrebbe ridurre il divario di prestazioni con il Barton di pari frequenza rendendolo meno "appetibile"?

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...

Mi è venuto un dubbio... ma il barton non dovrebbe avere anche le SSE2? Se così fosse andrebbe a recuperare in tutti i programmi che le utilizzano nei confronti del PIV, e se per il momento sono pochi in futuro saranno uno standard... forse è anche per questo che un 1.67Ghz può permettersi un rating di 2600+... qualcuno sa qualcosa?

Originariamente inviato da johnvs
[B]Mi è venuto un dubbio... ma il barton non dovrebbe avere anche le SSE2? Se così fosse andrebbe a recuperare in tutti i programmi che le utilizzano nei confronti del PIV, e se per il momento sono pochi in futuro saranno uno standard... forse è anche per questo che un 1.67Ghz può permettersi un rating di 2600+... qualcuno sa qualcosa?
La licenza delle SSE2 comprata da AMD è dal 1/1/2003 in poi...x cui penso che il Barton non le avrà......e nemmeno Hammer...anche se ero convinto le avesse....BOH.....

La questione penso sia decisamente semplice. Ci si è dimenticati di quanto il rating fosse sottovalutato già con la cache a 256k l'athlon rivaleggiava con PIV superiori alla frequenza di riferimento (di che ne dica amd il rating è riferito a loro lo sappiamo tutti). Ora con 512k di cache credo possa essere paragonato a livelli più elevati, il rating non è mai stato una presa in giro

Originariamente inviato da ErPazzo74
[B]
La licenza delle SSE2 comprata da AMD è dal 1/1/2003 in poi...x cui penso che il Barton non le avrà......e nemmeno Hammer...anche se ero convinto le avesse....BOH.....

Così si dice (in merito alla data), ma è anche vero che tutta la famiglia Hammer possiederà le SSE2 (ho letto molti documenti, anche di Amd, ed è confermato l'implementazione dell'SSE2 "estesa" però a 16 registri) e sicuramente non il Burton...

Ma i primi Clawhammer dovrebbero arrivare a Dicembre... In effetti la cosa è alquanto strana. Boh. Vedremo cosa succederà quando arriveranno (magari Intel farà causa ad Amd per aver usato l'SSE2 un mese prima della licenza... ;))

x Super-Vegeta: concordo pienamente con le tue riflessioni sul P-Rating.

Originariamente inviato da Super-Vegèta
[B]La questione penso sia decisamente semplice. Ci si è dimenticati di quanto il rating fosse sottovalutato già con la cache a 256k l'athlon rivaleggiava con PIV superiori alla frequenza di riferimento (di che ne dica amd il rating è riferito a loro lo sappiamo tutti). Ora con 512k di cache credo possa essere paragonato a livelli più elevati, il rating non è mai stato una presa in giro

Già all'inizio il rating era decisamente sottovalutato, ma ora bisogna dire che non è più così... o almeno non allo stesso modo: il PIV è passato da 256 a 512k di L2, e i benefici sono stati tangibili, poi adesso i modelli con cui si scontrerà il burton avranno anche il bus a 533 invece che a 400...

E poi il rating è fatto male, premia troppo gli aumenti di frequenza: se il 1600+ va a 1400 un ipotetico 3200+ dovrebbe andare a 2800, se fosse una cosa proporzionale, invece sappiamo che AMD ad un aumento di 66 da un aumento di 100+, quindi un ipotetico palomino 3200+ sarebbe andato a 2600...
Mi sa che ormai AMD è entrata nell'ottica dell'entry level e metterà il rating in paragone con i celeron, dato che con l'Hammer in circolazione sarà lì che dovrà scontrarsi il burton.... speriamo solo costi poco e vada bene nelle attuali schede madri...

Originariamente inviato da johnvs
[B]

Già all'inizio il rating era decisamente sottovalutato, ma ora bisogna dire che non è più così... o almeno non allo stesso modo: il PIV è passato da 256 a 512k di L2, e i benefici sono stati tangibili, poi adesso i modelli con cui si scontrerà il burton avranno anche il bus a 533 invece che a 400...

Dai test fatti fino ad ora, gli Athlon XP hanno dimostrato di poter competere, in media, con gli equivalenti P4/512Kb/533Mhz... Il P-Rating è stato introdotto come metro di paragone rispetto ai Thunderbird, quando ancora c'era il P4 Willamette in giro... E difatti i numeri erano ben superiori a quei P4, e Amd ne era consapevole. Oggi quel P-Rating, a mio avviso, calza a pennello con i nuovi P4... Mi posso anche sbagliare, ma mediamente mi pare che sia proprio così...

[B]E poi il rating è fatto male, premia troppo gli aumenti di frequenza: se il 1600+ va a 1400 un ipotetico 3200+ dovrebbe andare a 2800, se fosse una cosa proporzionale, invece sappiamo che AMD ad un aumento di 66 da un aumento di 100+, quindi un ipotetico palomino 3200+ sarebbe andato a 2600...

Difatti la formuletta impiegata da Amd indica, appunto, che ad un aumento di 66Mhz corrisponde un aumento di 100 nel P-Rating. D'altra parte, come si fa "legare" l'aumento del clock al corrispondente aumento del "lavoro" fatto dal processore? Qualcosa, seppur empiricamente, si doveva trovare... Fino ad ora i test hanno dimostrato che i numeri calzano abbastanza bene...

[B]Mi sa che ormai AMD è entrata nell'ottica dell'entry level e metterà il rating in paragone con i celeron, dato che con l'Hammer in circolazione sarà lì che dovrà scontrarsi il burton.... speriamo solo costi poco e vada bene nelle attuali schede madri...

Veramente il Burton potrebbe benissimo competere con i Northwood, grazie all'aumentata cache... :)

L'Hammer tirerà fuori ben altri numeri e, almeno fino all'arrivo del Prescott (P5?), non avrà alcun rivale...

Comunque, come ho già detto più volte, quando arriveranno questi nuovi prodotti, sapremo qual è la verità... :)

Originariamente inviato da cdimauro
[B]
...
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...

Chiaramente io non parlavo di prestazioni pure ma di rapporto prezzo prestazioni. Non so se ci sono previsioni sul rapporto di prezzo fra Barton e Tbred ma quello che vorrei sapere e' se le prestazioni che potra' raggiungere un Barton (meno overcloccabile) saranno talmente superiori a quelle di un Tbred (piu' overcloccabile) da giustificarne l'acquisto. Questo anche tenendo presente che le CPU "non di punta" tendono a crollare immediatamente di prezzo. Forse chi fra qualche mese riuscisse a trovare un Tbred a clock alto ad un prezzo conveniente potrebbe fare un buon affare ;).

Originariamente inviato da P V
[B]

Chiaramente io non parlavo di prestazioni pure ma di rapporto prezzo prestazioni. Non so se ci sono previsioni sul rapporto di prezzo fra Barton e Tbred ma quello che vorrei sapere e' se le prestazioni che potra' raggiungere un Barton (meno overcloccabile) saranno talmente superiori a quelle di un Tbred (piu' overcloccabile) da giustificarne l'acquisto.

Se così non fosse, non sarebbe giustificabile neppure la sua commercializzazione... Basterebbe il Toro stesso a farlo fuori... :)

[B]Questo anche tenendo presente che le CPU "non di punta" tendono a crollare immediatamente di prezzo. Forse chi fra qualche mese riuscisse a trovare un Tbred a clock alto ad un prezzo conveniente potrebbe fare un buon affare ;).

Farebbe un affare chi comprerebbe i modelli di base del Toro: con un po' di overvolting potrebbero arrivare a frequenze di tutto rispetto...

E' per questo che ho preso un XP 1600+... Peccato che la mia motherboard non permetta di overvoltare CPU e memoria (a meno di qualche piccola modifica hardware, comunque fuori dalla mia portata), perché sarebbe stata la classica ciliegina sulla torta... ;)