Newsgroup: it.comp.hardware.cpu
Titolo: Ancora Sul Bench di Hammer

http://www.aceshardware.com/
E' riportato il bench di ANSYS 7.0 
Le tabelle sono chiare.. 
Da leggere assolutamente il commento sul forum
http://www.aceshardware.com/forum?read=80050451
sopratutto per chi , come me, poco o niente sa del 
bench usato il aprere di un user del prodotto in questione.
Puntualizza anche alcune ,?, incongruita' dei risultati.
Alla fin fine il test sembra molto promettente per il 
Clawhammer.. anche se ,come e' stato sottolineato, non
e' possibile estrapolare linearmente i risultati in base al clock.
D'altra parte pare che in alcuni test la memoria "ridotta" sia
un handicap notevole ed anche di questo va tenuto conto,
infine , se non ho capito male, la macchina era un 256k L2
nel qual caso l'influenza della cache al procedere del clock 
sarebbe quasi costante con il taglio da 1M.
Nel caso la macchina a 2Ghz (2.5x)sarebbe veramente impressionante.
Credo che il collo di bottiglia (costante x AMD ormai) sara' la 
velocita' della memoria.. almeno fino al doppio canale degli 
Opteron.
ciao r.d.

 Opteron.
Bah ti dirò che ci si capisce poco, anche perchè la soluzione
''controller integrato'' potrebbe favorire in modo notevole
certo sw e nulla o quasi altro ancora. Gli unici dati in nostro
possesso sono le dichiarazioni Amd, che con tutta evidenza
rendono conto della media dei risultati ottenuti con i vari
pacchetti sw. Sembra il caso di SMT, inefficace in certi casi
formidabile in altri, con una media dichiarata del +20%.
Vorrà dire che chi usa Ansys si compra un Amd, chi usa
programmi di fotoritocco prende il P4..........e siam tutti felici.
Ciao.
Alberto.

 ha scritto nel messaggio
news:asioad$3pa$1...@atlantis.cu.mi.it...

Aspettiamo ancora un pò prima di dare una valutazione. E' ancora troppo
presto. Bisogna testare un modello di K8 con frequenza comparabile alle
frequenze effettive che saranno messe in commercio. Comunque il test è
interessante. Vedremo.
Saluti.

programmi di fotoritocco prende il P4..........e siam tutti felici.
Appunto.. la differenziazione che si sta avendo nel campo, in effetti,
permette di scegliere il sistema in base alle necessita' principali.
Non ci sarebbe storia pero' se AMD non si fosse sempre mostrata 
"timida" nell'aproccio alla comunicazione con la memoria.
penso al boost di prestazioni di un dual Athlon senza il 
collo di bottiglia della memoria. (il che non incita 
ad aumentare il FSB degli MP tra l'altro..)
ciao r.d.

 ad aumentare il FSB degli MP tra l'altro..)
Approccio timido senz'altro ben motivato, stai certo.
Ciao.
Alberto.

 programmi di fotoritocco prende il P4..........e siam tutti felici.
IMHO anche nel fotoritocco ci saranno "sorprese".
Il K8 non e' "solo" un x86 esteso a 64bit come non e' solo
una cpu con il memory controller integrato.
Per esempio, gli accessi al bus AGP ed alla memoria
possono avvenire in parallelo (visto che non si devono
spartire il FSB), inoltre l'IPC dei K8 e' piu elevato
di quelli dei K7 e scompaiono i problemi dovuti
al non potersi avvantaggiare delle SSE2 ...
... e tutto questo usando "solo" codice a 32bit!!!!
L. Micheletto

 ... e tutto questo usando "solo" codice a 32bit!!!!
Vero vero, infatti Amd ha un ''sistema'' che gli permetterà
di pareggiare la partita con Intel, anche se l'incognita
compilatore rimane......tenuto conto del nuovo nato 7.0........
Insomma Amd si ritrova a rendere a dovere con il 5.0,
già il 6.0 rompe le uova nel paniere, figuriamoci il 7.0; prova
ne è il fatto che i dati spec sono tutti basati sul C++ 5.0.1,
strano vero ?.
E che diamine! cosa dobbiamo pensare? che tutto il nuovo
sw gira male su Amd?, vi sono segni preoccupanti in questo
senso, basta leggere la prova del P4 3.06G su Aces.
Ho il vago sospetto che il P4 sia talmente diverso dalla
concorrenza, da spiazzare tutti nel caso di una riscrittura
completa del sw, o magari anche di una aggressiva ricompilazione
con gli ultimi tools. Spero che la mio sia solo un timore
infondato, ma se anche accadrà il 50% di quello che temo,
il P4 si rivelerà la più grossa ''bastardata'' della storia informatica.
Ciao.
Alberto.

 il P4 si rivelerà la più grossa ''bastardata'' della storia informatica.
Beh... già quello che è successo fino adesso lo è, chiedilo a quelli che si
erano comprati i Willamette con le Rambus...

possono avvenire in parallelo (visto che non si devono
c'e' anche l'altro lato della moneta, una cosa che dovrebbe avere
effetti irrisori probabilmente, ma potrebbe anche avere un certo
impatto in casi limite - l'agp per accedere alla memoria deve
attraversare il processore, cosa che alza di qualcosa le latenze...
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]

compilatore rimane......tenuto conto del nuovo nato 7.0........
il 6.0 era ottimizzato per p4 in modo "lineare",  cosa che porta
vantaggi enormi con la lunghissima pipeline del p4 e svantaggi per chi
ha pipes piu' corte, il 7.0 e' ottimizzato principalmente per disporre
i dati in parallelo per sfruttare le capacita' multithread di ht -
questa ottimizzazione la possono sfruttare _TUTTI_ i processori con
alto parallelismo interno e/o multiprocessing...
direi che amd debba dire un bel "grazie" ad intel per i nuovi
compilatori, sono il massimo per hammer :-)


 il P4 si rivelerà la più grossa ''bastardata'' della storia informatica.
Ma potrebbe anche accadere che AMD abbia preparato bene
"la contro-bastardata" come con il K7 (quando analizzo' per bene
i punti deboli dei PII e tiro' fuori una cpu capace di eseguire *meglio*
il software ottimizzato per essi), la stessa cosa e' successa
con SSE dai Palomino in su.
Ora semplicemente con i K8 ci sara' una gestione migliorata
delle SSE2 rispetto a quanto fa il P4, anche perche a parte l'SMT
buona parte delle ottimizzazioni specifiche per P4 riguardano
le istruzioni di prefetch delle linee di cache e l'uso dei
registri XMM in tutti i modi possibili.
L. Micheletto

 attraversare il processore,
cosa questa assolutamente falsa.

 compilatori, sono il massimo per hammer :-)
Dici bene, ma Hammer non è multithread........i dati se li
parallelizza da solo, chissà se digerisce la pre-masticatura
pro P4, io penso di no, potrebbe essere costretto a un
lavoro di riorganizzazione piuttosto penalizzante.
Vediamo........aspettiamo i bench.
Ciao.
Alberto.

 ha scritto nel messaggio
news:fi7I9.66046$2B1.1...@twister2.libero.it...

In quest'ottica avrei ampliato i bus cache a 128 bit..............
tutto è possibile ma penso che quello che auspichi verrà
con K9.
Ciao.
Alberto.

 ha scritto nel messaggio
news:asr2qo$tvj3c$1...@ID-157938.news.dfncis.de...

E perchè ? dove risiede il memory controller?
Hammer è una formidabile macchina per server,
pensata nell'ottica server, in effetti il problema
AGP esiste, ma potrebbe essere irrilevante.
Ciao.
Alberto.



falsa? l'agp e' collegato al convertitore agp->hypertransport che e'
collegato al processore che contiene il ram controller che e'
collegato alla memoria.
quiz: come fa l'agp ad accedere alla memoria senza passare per il
processore?


 attraversare il processore, cosa che alza di qualcosa le latenze...
Non passa "attraverso" il processore, passa attraverso
la sua sezione di I/O (memory controller, crossbar switch
e controller bus HT), apparentemente sembra una cosa pesante
ma e' quasi come succede con i sistemi in cui e' il northbridge
a gestire il trasferimento da ram ad AGP o viceversa.
La sezione di I/O dei K8 internamente lavora a
frequenze molto piu elevate di un northbridge classico
quindi "pesa meno" sul tempo totale di transito
(e questo e' proprio uno dei vantaggi di cui G. Sartori
   aveva parlato mesi fa proprio in questo ng).
Inoltre, considerando il tipo di traffico "diretto"
tra ram ed AGP (di solito si tratta di volumi di dati
abbastanza grossi rispetto ad un singolo blocco di dati)
la latenza pesa relativamente visto che un agp controller
"pensato per il K8" puo richiedere la lettura del blocco
successivo mentre quello richiesto in precedenza e' gia
in transito (grazie al fatto che sul bus HT i dati viaggiano
simultaneamente nei due sensi).
L. Micheletto

a gestire il trasferimento da ram ad AGP o viceversa.
e' piu' pesante, introduce sia latenze, sia ritardi dovuti al fatto
che il processore ha sempre la precedenza.
e' il motivo per cui creare mb per hammer con video integrato e
memoria condivisa e' un macello...
comunque, come ho detto, i casi in cui la cosa sia significativa sono
praticamente zero.
