Newsgroup: it.comp.hardware.cpu
Titolo: Pricing for Athlon 64 (939 pin chip won't be compatible with 940 CPU)

http://www.theinquirer.net/?article=11150
Saluti.

 Saluti.
Bhe... cavolo.. fa un po incazzare... io stavo aspettando a cambiare mobo
proprio per quello...
speriamo non sia vero...

 ha scritto nel messaggio
news:X1s1b.125433$cl3.3...@news2.tin.it...

E invece sarà proprio così, l'Athlon 64 non avrà prezzi possibili prima di
gennaio '04. Normale politica commerciale.
Arruffato

 gennaio '04. Normale politica commerciale.
[..]
Ma sai... al di la del prezzo quello che lascia persplessi è il lancio di
due CPU che hanno un solo PIN di differenza nell'arco di 4 mesi e che
richiedono quindi 2 mb diverse... ma che cavolo di politica è? Chi se lo
compera subito deve cambiare mb dopo 4 mesi?
Bha!!
ora mi vado a vedere il roadmap AMD.. cosi  cerco di capirci qualcosa..

 ha scritto nel messaggio
news:X1s1b.125433$cl3.3...@news2.tin.it...

ma tu credi  che OGGI con WinXp sfrutteresti Athlon64 ?
Longhorn (che sarà ottimizzato a 64bit) esce tra due anni e Win2003 server
costa un PATRIMONIO oltre a non servire ai tuoi scopi (suppongo)
Athlon 64 sarà una CPU dedicata a Workstation e Server per questo un piedino
in più dopo 4 mesi non fa differenza.
Chi compra un servere a Gennario non lo cambia ad Aprile (a meno che non sia
stupido)
:)
-- 
-------------------------------------------------------------------------
Susy
P4 3000@3750 FSB1000 --  P4C800 Deluxe
1024Mb Kingston HyperX PC4000
GeForce 5900Ultra
3DMark 2003 b330=7412
-------------------------------------------------------------------------

 stupido)
[..]
Hai ragione, però è anche vero che oltre ad essere a 64 bit è la nuova
versione dell'athlon. Ora non ho ancora visto nessun test in giro quindi non
so dire esattamente, ma la mia idea è che comunque sarà più veloce
dell'athlon xp anche nell'esecuzione del codice 32 bit. Stanti cosi le cose
non la vedo poi molto fuori luogo l'idea di comperare l'Athlon 64 che, se
non ho capito male, è dedicato al mondo consumer e non professional per il
quale c'è già l'Opteron.
Poi su come si comporterà M$ non ho idea... però una qualche patch per
abilitare in XP l'uso di almeno alcune feature del nuovo proc (ovvero parti
ricompilate del SO) anche prima del supporto nativo non mi stupirebbe più di
tanto: se non erro accadde già cosi per il passaggio ai 32 bit e, senza
andare troppo indietro anche per altre tecnologie come L'usb per la quale M$
si adeguò rilasciando patch e aggiornamenti.
Poi una considerazione politico-economica:
AMD sta perdendo terreno per mancanza di competitività di XP verso il P4 e
punta sull' Athlon  64 per recuperare terreno: che non si sia mossa in alcun
modo per ottenere da M$ un qualche supporto anche fuori dal mercato
professional? Sarebbero dei folli no? ;-)

compera subito deve cambiare mb dopo 4 mesi?
[Mode Flame On]
Chiedilo a tutti quelli che comprano Intel!!!! ^__^
[Mode Flame Off]
Si', effettivamente e' una boiata!
Ciao.
----------------------------------------------------
-+- Dumah, Demone dell'Agonia -+-
"Muhahahahahahahahahah... coff coff coff... gasp!...
anf puff pant!... coff coff...... ehm... Muhahahahahahahah..."

 quale c'è già l'Opteron.
Esatto :) ad ogni modo Linux supporta già l'x86-64 e XP pure
https://www.microsoft.com/windowsxp/64bit/
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
rhy...@NOSPAMmyself.com


Mah! Non e' molto chiaro.
*Non* parlano del socket, ma dei chip, considerando che quelli
con 940 pin sono abilitati per le configurazioni multiprocessore
ed i 939 no, mi sembra ovvio che non sono compatibili.
Per capire quanto c'entri il socket bisognera' aspettare
notizie piu dettagliate.
Intanto circolano informazioni interessanti riguardo i chip per
il socket 754
(su 
www.theregister.co.uk
 "AMD to ship Athlon 64s as Athlon XPs"
  e
  su 
www.theinquirer.com
 "AMD to migrate Athlon XP to 754 pins"
  con riferimento ad un articolo precedente su xbitlabs
).
Mi riferisco al Paris (in scala 130 nm) ed al Victoria (in scala 90nm).
Sembra che a partire dal 2004 ci sara' un "Athlon XP su Socket 754"
(o un Athlon64 "che funziona solo a 32bit") con 256KB di cache L2.
Al solito le date di uscita non sono chiare (su The Register
arrivano a dire che il Paris uscira' gia a fine 2003).
La notizia e' interessante visto che la cosa permette ad AMD di
produrre delle cpu a 32bit "economiche" con prestazioni
superiori agli Athlon XP attuali senza crescere troppo
di clock e senza dover avere spese aggiuntive di progettazione.
Inoltre questa mossa dovrebbe incentivare la produzione di schede madri
"economiche" per Athlon64 (sulle stesse fasce di prezzo di quelle per
Socket A, per intendersi).
Mettiamola in questo modo: un Athlon XP che supporta le SSE2, usa
il package (ed i mega dissipatori) dei K8 ed ha un memory controller
integrato, se avra' un prezzo "umano" sara' molto
interessante per chi non ha bisogno (o non puo permettersi)
una cpu a 64bit.
L. Micheletto

 una cpu a 64bit.
Peccato non abbia il dual channel, ormai sono 8 mesi che lavoro in dual e mi
dispiacerebbe perderlo, darà anche solo guadagni dell'ordine dell'1,5% ma
sarebbe un peccato perderli.
Sui prezzi secondo me la concorrenza con Intel farà giustizia, a parità di
prestazioni dovrà corrispondere come minimo prezzo equivalente, altrimenti
la forza del marchio Intel diventa vincente.
Arruffato

 sarebbe un peccato perderli.
Se si passa da un Athlon XP + chipset dual channel
ad un "K8-32bit" su socket 754 e' assai probabile che a parita
di clock sia il secondo ad essere piu veloce nei programmi
in cui le prestazioni sono limitate dagli *accessi* alla ram.
Le cpu su Socket 754 non avranno il dual channel, ma in compenso
gli accessi alla ram hanno latenze circa dimmezzate.
Con gli Athlon XP su socket A la richiesta di lettura passa
da cpu a northbridge esterno e poi arriva alla ram, a quel punto
inizia il trasferimento verso il northbridge e poi dal northbridge
alla cpu attraverso il FSB.
Il northbridge inoltre lavora ad un clock/data_rate corrispondente
legato a quello del FSB o della ram (dipende da quale e' piu veloce)
quindi l'effetto finale e' come se la latenza della ram venisse
aumentata di molto (dipende ovviamente da come viene realizzato il
northbridge e come bufferizza i trasferimenti, basta pensare alle
differenze di prestazioni dei chipset VIA passando ad esempio
da KT266 a KT266A).
Con le cpu con memory controller integrato invece la richiesta
va dritta dalla cpu alla ram e dalla ram alla cpu.
Il collegamento *interno* tra memory controller integrato
ed il resto della cpu equivale alla presenza di un FSB che lavora
"alla stessa frequenza di clock della cpu", se ad esempio la cpu
va a 2Ghz e' come avere un FSB a 2Ghz, inoltre i buffer "intermedi"
del memory controller vengono letti/scritti "a pieno clock"
mentre di solito i buffer sui  northbrige "esterni" opera a
frequenze bel piu basse; mettendo insieme le due cose si ottiene
la drastica riduzione delle latenze reali di cui parlavo sopra.
Ed ora si arriva al punto cruciale, ovvero il legame tra banda
di i/o con la memoria, cache e latenze.
Attualmente uno dei motivi per cui si piazzanono cache sempre piu grandi
sui chip e si aumenta la banda verso la memoria
(dual channel, ecc. ecc.) e' perche le latenze (il tempo che passa
tra quando richiedi una dato alla ram ed il momento in cui arriva)
sono elevate in rapporto al clock interno delle cpu.
Si tratta di approcci che mirano a "mascherare" le latenze
sfruttando il fatto che nel blocco di 64..128 byte che viene
caricato quando si ha un cache miss nella L2, probabilmente
ci sono altri dati a cui si fara' accesso "senza piu latenze elevate"
(visto che negli accessi successivi il resto del blocco si trova
  gia in cache).
Ma in ogni caso la latenza elevata si nota comunque al primo accesso
e quando si fanno un sacco di accessi "sparsi" sulla ram
(strutture dati allocate dinamicamente in momenti diversi, che quindi
  tendono a "spargersi nello spazio di memoria", ecc. ecc.).
Nella maggior parte dei casi la banda verso la memoria serve solo per
"abbassare le latenze apparenti" (anche perche di solito il
programmatore e/o il compilatore mirano a sfruttare i registri e la
presenza della cache proprio per ridurre il piu possibile gli accessi
verso la ram esterna).
L. Micheletto

compera subito deve cambiare mb dopo 4 mesi?
Ovvero... come dare occasioni preziose ad Intel e vivere felici ;-)
___________________________________
[[[ 
http://members.xoom.it/scai
 ]]]
     Modding & (poco) Altro...
[Broadband connections kill the video star]

 
https://www.microsoft.com/windowsxp/64bit/
The 64-bit Microsoft Windows platform will provide high availability,
advanced scalability, and large memory support based on the Intel® ItaniumT
processor family with its extensive multiprocessing features, powerful
floating-point arithmetic extensions and multimedia-specific instructions.
La pagina che citi parla di XP per Itanium e non x86-64 ;-)
Ciao,
Jena

 La pagina che citi parla di XP per Itanium e non x86-64 ;-)
Non ho letto quella pagina ma Xp64 per x86-64 e` uscito in beta (molto
riservata a pochissimi eletti) in questi giorni. E` prevista l'uscita per
inizio 2004.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Debian Sid Proud User

 inizio 2004.
Ed esiste anche un fantomatico compilatore Microsoft C per AMD64. In realtà
procurarselo dovrebbe essere abbastanza semplice, visto che dovrebbe essere
contenuto tra gli strumenti di sviluppo driver per Windows/AMD64, già
pubblici sul sito Microsoft da svariati mesi (addirittura da prima
dell'annuncio di Windows per AMD64, se non ricordo male). Il problema è che,
per vederlo in azione, occorre un sistema AMD64 con installata una
prerelease di Windows/AMD64 :-)
Mi pare anche che la prossima versione di .NET dovrebbe essere la prima a
supportare i 64 bit, per cui aspettiamoci compilatori per Itanium
(ovviamente) e per AMD64 (probabilmente).
Saluti.
-- 
\/   | |         Wilmer Ricciotti - ICQ UIN: 3233084
/\ e | | o s s   
wi...@libero.it
HiT - EdenGames: 
http://hit.edengames.net
sito  personale: 
http://www.cs.unibo.it/~ricciott/
 (non attivo)

Ed esiste anche un fantomatico compilatore Microsoft C per AMD64. In realtą
Che grado di ottimizzazione hanno i compilatori MS?
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

 Che grado di ottimizzazione hanno i compilatori MS?
Ultimamente molto elevato. Stanno raggiungendo icc come prestazioni su
codice x86. Spero che abbiano una implementazione altrettanto buona
per AMD64.
