Memorie DDR2-1066 per le cpu K8L di AMD

Le future cpu Athlon 64 basate su core K8L dovrebbero supportare in modo nativo le memorie DDR2-1066, che nel frattempo verranno standardizzate dal JEDEC
di Paolo Corsini pubblicata il 02 Gennaio 2007, alle 14:23 nel canale ProcessoriAMD
38 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoMi sembra che a volte ci siano correnti di pensiero troppo diverse nell'informatica...
Secondo voi riusciranno ad abbassare temperature e consumi anche delle VGA (tralasciando il GPU Shrink)
sì i consumi gpu stanno andando sempre più su nonostante le architetture a 0,09micron e anche il mio nf4ultra non ci scherza, a questo punto se le 8800 uscite un mesetto fa consumano così tanto non riesco ad immaginare fra un paio d'anni che succederà... ecco perchè stanno iniziandoa vedersi in giro alimentatori da 750w e 1kw
Spiega, spiega... Cioè i 65nm avrebbero cache L2 più lenta dei 90nm ?
In sistemi multisocket si...
Si, gli attuali processori AMD a 65 nm con core "Brisbane" hanno la latenza della cache L2 che è passata da 12 a 20 cicli. Hanno anche spesso 100 MHz in più, ma ciò non toglie che a parità di rating siano leggermente più lenti delle CPU che li hanno preceduti. Pare che AMD abbia dichiarato che l'aumento di latenza sia dovuto alla possibilità di rilasciare future versione della CPU con cache maggiorate. Come successe per il Prescott "seconda versione" con cache L2 da 2 Mbytes ma latenza maggiorata da 10 a 20 cicli. A me la cosa pare un pò strana perchè:
1) esistevano versioni di K8 a 90 nm con cache L2 da 1 Mbyte per core e stessa latenza di 12 cicli
2) Nelle roadmap non ci sono CPU con più di 1 Mbyte di cache L2 per core, anche se è possibile (IMHO difficile) che vengano rilasciate versioni "maggiorate"
Possibile che ci siano stati dei problemi tecnici e che l'aumento di latenza fosse l'unico modo per garantire l'uscita "in tempo" di queste CPU, visto che comunque il costo di produzione viene ridotto e la corsa velocistica è persa in partenza senza una nuova architettura, mentre buone rimangono le "performance per watt" e la dissipazione delle nuove versioni. Possibile che un respin, un pò come successe tra Thorougbred A e B, possa colmare le lacune, oppure si punterà tutto sul K8L.
1) esistevano versioni di K8 a 90 nm con cache L2 da 1 Mbyte per core e stessa latenza di 12 cicli
2) Nelle roadmap non ci sono CPU con più di 1 Mbyte di cache L2 per core, anche se è possibile (IMHO difficile) che vengano rilasciate versioni "maggiorate"
Possibile che ci siano stati dei problemi tecnici e che l'aumento di latenza fosse l'unico modo per garantire l'uscita "in tempo" di queste CPU, visto che comunque il costo di produzione viene ridotto e la corsa velocistica è persa in partenza senza una nuova architettura, mentre buone rimangono le "performance per watt" e la dissipazione delle nuove versioni. Possibile che un respin, un pò come successe tra Thorougbred A e B, possa colmare le lacune, oppure si punterà tutto sul K8L.
Bè è successo la stessa cosa anche con il core Clawhammer sostituito con il core Newcastle per il processo produttivo a 130nm e stessa cosa è capitata con il core Winchester rimpiazzato dopo pochissimi mesi dal core Venice/San Diego per quando riguarda le CPU a 90nm...
Molto probabile che AMD non abbia affinato per bene il processo a 65nm...
Molto probabile che AMD non abbia affinato per bene il processo a 65nm...
Si, con la differenza che tra Thoroughbred A e B non cambiavano le prestazioni, e Newcastle era un nuovo core solo perchè c'erano 512 Kbyte di cache in meno (ma per "apparare" il rating venivano dati 200 MHz in più rispetto alla versione con 1 Mbyte di cache, per cui il Newcastle a parità di PR andava spesso meglio). Winchester era un die shrink di Newcastle ma non toccava le latenze (e le prestazioni). E Venice/San Diego introducevano il supporto alle SSE3 e un controller della memoria migliorato ma questo si quantificava in prestazioni migliori, anche se di pochissimo. Brisbane sarebbe dovuto essere solo un die shrink e invece sono andati a toccare le latenze e di conseguenza a ridurre le prestazioni in maniera non sostanziale ma comunque "avvertibile"
Per questo penso ci sia comunque bisogno di un respin.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".