Newsgroup: it.comp.hardware.cpu
Titolo: Caratteristiche Thunderbird

Riporto la notizia.....
1 mag h 14:00 - Secondo alcuni test preliminari svolti in Giappone, il nuovo
processore Thunderbird di AMD risulta dotato di 64 Kb di cache di primo
livello e di 256 Kb di secondo livello, quantità quest'ultima pari a quella
del processore Pentium III Coppermine di Intel. Anche il modello AMD potrà
inoltre contare su un tipo di cache di tipo on-die, ovvero inserita nello
stesso nucleo centrale della cpu.
--
________________________________
per rispondermi iliasba(at)
tin.it
bye Brain

stesso nucleo centrale della cpu.
sembra assolutamente incredibile che AMD dimezzi la cache L1...
anche sul Duron (sigh) la L1 e' di 128kb..
cmq.. staremo a vedere.
ciao r.d.

cmq.. staremo a vedere.
E RAGAZZI ^_^
Non contate un fattore fondamentale
La Ls del T-bIrd sarà 16-way associative. Quella del Duron manco si sa
con certezza quanto sarà grande...
per Tom's Hardware è 128Kb
per qlcn'altro sono 64Kb...
e probabilmente sarà 8-way associative quindi le differenze ci sono...
MOLTO probabilmente saranno 128 8-way così ottengono una differenza
tale che la cache del T-bird sembrerà 4 volte più grande pur
mantenendo la differenza di cache con i Celenron2-PIII...
Se fosse vero è una mossa della madonna ^_^

stesso nucleo centrale della cpu.
Il Thunderbird ha le seguenti caratteristiche:
L1 Istruction:	64k	2-way set associative	
L1 Data:		64k	2-way set associative
L2 Unified:	256k	16-way set associative
La L1 è la stessa dell'Athlon.
Ciò che cambia è la L2, che passa ad essere on-die, con un'ampiezza di
256bit. 
Quello che non so (a spero che qualcuno mi illumini, perchè la
curiosità mi corrode! :-), è la velocità della L2.
Essendo integrata, dovrebbe essere pari a quella del core.
Ma si vocifera che la L2 possa essere addirittura DDR!!
In tal caso, un Thunderbird con frequenza di lancio di 1.25 Ghz (e
sicuramente in rame), avrebbe la L2 alla frequenza effettiva di 2.5
Ghz!!
Per favore, ditemi che non è vero!! 8-()	



Io sono quasi certo che la L2 del Duron sarà da 64k.
Resta da vedere quanto Amd intenda differenziare le linee produttive
del T-bird e del Duron.
Effettivamente la differenza del 10-12% sugli interi a favore del
T-bird rispetto al Duron, potrebbe essere giustificata non solo dalla
L2 più grande, ma anche dalla 16-way invece della 8-way associative
che potrebbe avere il Duron, come da te prospettato.
Comunque sto' monitorando il sito Amd, per scaricarmi il datasheet
appena possibile.

 Ghz!!
La frequenza massima di introduzione difficilmente supererà il GHz, e a mio
parere il massimo sono gli 1.1 GHz. Non credo che possiamo aspettarci di più
prima che Dresda (e quindi il rame) vada a regime (Q3).
--
Wilmer Ricciotti
wi...@tin.it

Se fosse vero è una mossa della madonna ^_^
mah... gia' Intel pare (dico pare xche' lei smentisce) abbia differenziato 
i celII - PIIIcopp con un abbassamento della associativita' della cache
(comprensibile date le taglie) e un AUMENTO della latenza dei cel.. per 
aumentare il gap prestazionale tra le due CPU...
almeno stando a i test visti... 
ciao r.d.

aumentare il gap prestazionale tra le due CPU...
IxBT-labs smetisce...
non è differenza di latenza di cache...
per lui funge tutto nello stesso modo

prima che Dresda (e quindi il rame) vada a regime (Q3).
Il T-bird è al rame...
non so se è 512bit... mi sembra troppo...
mi sa che hai raddoppiato il valore in bit al posto che quello della
grandezza...
512 bit sono un enormità... sarebbero quasi fuori dal mondo
si arriverebbe a prestazioni su interi e fpu da capogiro

Il Duron ha una L1 da 64 Kb e una L2 da 64 Kb.
Non ne capisco l'utilità, dato che la L2 non può non essere una una copia
della L1.

 si arriverebbe a prestazioni su interi e fpu da capogiro
Soprattutto sugli interi... questa ampiezza di banda potrebbe anche essersi
rivelata necessaria perché, avendo l'Athlon ben 128kb di cache L1, forse
l'incremento di prestazioni non sarebbe stato sufficiente. Si parla anche di
cache esclusiva: non si sa se essa sia limitata al Duron o estesa al T-bird
(la qual cosa, a mio avviso non sarebbe assurda per limitare le spese - si
potrebbero recuperare gran parte dei T-bird riusciti male disabilitando 3/4
della cache L2 e vendendoli come Duron).
Saluti
--
Wilmer Ricciotti
wi...@tin.it

 della L1.
No, ha una L1 da 128kb e una L2 da 64kb.
Ed evidentemente la L2 non può contenere i dati contenuti nella L1 (si
chiama "cache esclusiva", sul forum di Ace's hardware se ne parla da
parecchio).


Pare invece che l'ampiezza sia addirittura di 512 bit, ma ci pensate???
Salve!
Mi viene in mente, e lo scrivo: chiedo scusa se è una cavolata.
Un bus ampio 512 bit, per essere sfruttato, imporrebbe il
trasferimento di 2 linee di L2 alla volta (ciascuna di 32 byte; e
devono restare di 32 byte per la limitazione del bus ram, immagino)
verso L1 e cpu: una linea contiene il dato richiesto dalla cpu, ma
l'altra? Come la scelgo? Io credo che non avrebbe molto senso...
Certo, se la L2 fosse in linee di 64 byte... non so, forse in futuro
si potrebbe sfruttare la ram DDR (con la sua velocità) per realizzare
cicli di accesso alla ram a 8 'stadi' (intendo sostituire  x-1-1-1 con
x-0,5-0,5-0,5-0,5-0,5-0,5-0,5), ma credo che si avrebbe una totale
incompatibilità coi vecchi chipset, mentre si parla già di
adattatori...
-- 
Bye.
       Lem
----------------- 'CLOCK is what you make of it' -----------------
Ricerca nuovi numeri primi: 
www.entropia.com/primenet/status.shtml

l'altra? Come la scelgo? Io credo che non avrebbe molto senso...
molto semplicemente in questo modo riduci la latenza. 
invece di aspettare 5-7 cicli di clock che la cache sia pronta a spedirti i
dati richiesti puoi ridurre a 3 cicli o anche meno facendo le richieste a
pacchetti.
---
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
    I bimbi buoni vanno in paradiso.
    I bimbi cattivi vanno dove gli pare!

pacchetti.
Certissimo, ma se la linea di cache è di 32 byte (256 bit), ed il bus 
L2 è a 512, vuol dire che:
1) ne uso solo la metà, e allora non ho vantaggi rispetto alla 
soluzione con bus a 256 bit (che ha portato effettivamente 
importantissimi risultati in tema di riduzione della latenza sui 
Cumine);
2) trasferisco due linee di L2 alla volta: ripeto, come si sceglie la 
seconda linea (considerato che va a cancellare qualcosa in L1, che 
magari serve ancora)? A seconda della vicinanza fisica (potrebbe 
comunque contenere dati/istruzioni che non c'entrano nulla con la 
prima riga, e che non servono affatto)? A caso ? Ecco, io non riesco 
ad immaginare il principo in base al quale effettuare la scelta. La 
differenza, IMVHO, sta nel fatto che la linea di L2 contiene 
dati/istruzioni che sono 'consecutivi' anche nella ram (da cui è 
copiata), quindi probabilmente 'correlati', mentre due linee non 
necessariamente hanno legami di alcun tipo l'una con l'altra.


ad immaginare il principo in base al quale effettuare la scelta. La 
hargh, accidenti a te, ora mi tocca passare una settimana a dipanare un
caching 16way per capire come diavolo possono aggirare il problema...
un "boh" non ti basterebbe come risposta? ^____^
ah, c'e' anche da dire che se allarghi le linee di cache da una parte
aumenti il "costo" dei dati non contigui, dall'altra riduci drasticamente
gli indirizzi cacheabili...
non vorrei che avessero fatto qualche cazzata tipo "max 256mb cacheable", e
gli annunci di dei probabili thunder con un mb di cache on-die iniziano a
sembrare molto meno belli di quanto non pensassi... :-(


sembrare molto meno belli di quanto non pensassi... :-(
Già, non avevo pensato a questo possibile problema...


si, vedo il tuo punto... ^____^
Debbo scusarmi.
Ho appena (sigh!) ricordato (o forse dovrei dire appreso) che le 
linee di L2 sull'Athlon sono effettivamente lunghe 64 bytes, ed il ciclo
di lettura della ram è proprio un 5-1-1-1-5-1-1-1.
Quindi ecco che anche un bus a 512 bit dalla L2 verso la L1 si 
giustificherebbe appieno, senza comportare problemi di sorta (ora, 
infatti, per trasferire una linea di cache dalla L2 alla L1 ci 
vogliono due cicli, più altri due per portare la L1 soppressa in L2).
La lettura che mi ha aperto gli occhi (grazie a Xelloss per aver dato il 
link sul ng) è stata: 
http://www.chip-architect.com/mw.pdf
, il cui 
argomento generale è il confronto fra Willamette e Mustang.
-- 
Bye.
       Lem
---------------- 'CLOCK is what you make of it' ----------------
Ricerca nuovi numeri primi: 
http://www.mersenne.org/freesoft.htm

vogliono due cicli, più altri due per portare la L1 soppressa in L2).
.... 
err...
mi era sempre sembrato che l'athlon fosse fortemente castrato dall'attuale
subset cache - ram, ma non mi aspettavo qualcosa a questi livelli...
humm...
devo ritoccare parecchio verso l'alto le mie stime della differenza di
prestazioni fra athlon e t-bird ^______^
