Newsgroup: it.comp.hardware.cpu
Titolo: Articolo su S. Sandra e H.Threading.

Lo trovate su:
http://www.overclockers.com/tips00164/
e' un interessante articoletto sui risultati che Sandra 
attribuisce ad H.T., in effetti una contestazione dei medesimi.
L'autore afferma che l'unico programma veramente ottimizzato 
per HT e' proprio Sandra.
Facendo riferimento ad un test fatto da :
http://www.2cpu.com/Hardware/ht_analysis/
dove le differenze eclatanti sono proprio e solo in Sandra.
Un incremento (non disprezzabile!) del 15% sembra la media reale.
cmq da leggere (sono brevi articoli molto chiari) e da meditare, anche 
magari, solo per contestarne le conclusioni.
ciao r.d.

 magari, solo per contestarne le conclusioni.
Io dico solo che andranno rivisti ampiamente i MN di Amd,
anche se vedessimo solo un miglioramento del 10% nel P4
con SMT.
Ciao.
Alberto.

con SMT.
Rileggendo qua e la... alla fine, nel mondo reale, non ci si dovrebbe 
discostare da li'.
ciao r.d.

 con SMT.
Probabilmente in futuro (almeno per gli XP) se l'HT funzionerà davvero e 
quei 450Mhz di cui parli saranno "reali" potremmo confrontare "finalmente" 
i processori AMD e gli Intel a parità di Mhz e non più a parità di MNvsMhz.
-- 
| (o_  | Piersandro Guerrera  -  Eden.Games Group    |            _o)  |
| //\  |  URL: 
http://www.edengames.net
              | (o_  (o_   /\\  |
| V_/_ |  Togli NOSPAM per rispondere in e-mail.     | (/)_ (/)_ _\_V  |

 --
Lo stesso problema si ripresenterà (amplificato) con Clawhammer.
Sappiamo che solo una parte delle applicazioni beneficerà in modo
apprezzabile della minore latenza del sottosistema memoria, voglio
vedere come giustificherai la cpu Amd...............;-).
E' comunque certo che mai si giungerà alla parità di IPC.
Ciao.
Alberto.

 discostare da li'.
Alla presentazione penso anche io, con l'aumentare dei sw dedicati
e con Prescott le cose cambieranno ancora.
Vedremo un K9 con SMT?
Ciao.
Alberto.

 Vedremo un K9 con SMT?
Se allungano il pipeline per salire in frequenza,
direi che saranno costretti ad aggiungere SMT o
qualcosa di simile...
bye,
-- 
  Piergiorgio Sartor

 che il P4 a 3G vale come un K7 a 3G.
No, io direi che un P4 a 3G vale come un P4 a 3G... mentre ora un P4 a 2.53G 
vale come un P4 a 2.0G.
Cosa prendo come mezzo di paragone? Mai visti i P3 1000 andare piů veloce 
dei P4 a 1.5Ghz?


 dei P4 a 1.5Ghz?
E anche questo č un strano modo di metterla :-).
Una cpu vale il prodotto IPC*Clock, non i singoli
termini. E' una questione di scelta progettuale, nulla
piů e non deve creare partigianerie inutili.
Il P4 a 2.53G vale quello che vale e se l'aggiunta di
migliorie (che perň costano dal punto di vista termico)
innalza l'IPC, bah......puň essere un bene o un male.
In effetti un P4 liscio, senza SMT, potrebbe scalare meglio
di frequenza senza fondere la mobo.............
Ho il sospetto che l'attuale HT sia solo un richiamo commerciale.
Vedremo Prescott.
Ciao.
Alberto.

 qualcosa di simile...
E son curioso di vedere se implementeranno
la trace cache. Chissà chissà...
Ciao.
Alberto.

Io dico solo che andranno rivisti ampiamente i MN di Amd,
IHMO se intel avrà un bost in prestazioni come quello dichiarato a
parità di frequenza forse è ora che cambi nome alla cpu o che aggiunga
lei un MN, fino ad ora è stata troppo legata ai MHz nonostante ci
siano cpu con stesse frequenze a prestazioni differenti (1.8-1.8A;
2.4@100 - 2.4@133). 
Personalmente dopo un certo periodo di scetticismo l'MN ha cominciato
a piacermi.

 Cosa prendo come mezzo di paragone? Mai visti i P3 1000 andare più veloce
dei P4 a 1.5Ghz?
Uffaaa!!! Ancora!!! È stato detto un miliardo di volte su questo NG che non
si possono fare i confronti fra PIII e P4 a parità di MHz perchè si tratta
di due architetture diverse (il PIII non riesce a salire molto in frequenza
mentre il P4 comincia a lavorare bene dai 2 GHz in poi)
È vero che i primi P4 Willy erano assai deludenti, ma gli attuali P4
Northwood a 2.4 - 2.8GHz, con 512K di L2 e 533MHz di bus sono tutta un'altra
cosa, e soprattutto sono ENORMEMENTE più veloci di qualsiasi PIII (e io
possiedo proprio un PIII 1000). Io ho provato un P4 a 2.53 + GeForce4 e sono
rimasto impressionato dalla rapidità con cui faceva girare alcune
applicazioni (specie nel multimediale). Non c'è proprio paragone, credimi
Red

 credimi Red
Mica devo credere a te ;o)
Basta dare un'occhiata ovunque, Alberto ha capito l'osservazione... tu ti 
sei attaccato alle parole...


Vedremo un K9 con SMT?
no, smt e' una soluzione per risolvere i problemi del p4, ovvero
l'incapacita' di sfruttare al meglio il parallelismo interno e
l'enorme pipeline.
hammer non ha la pipeline ne le unita' esecutive organizzate come il
p4 quindi non necessita del smt.
--
    (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]

Alberto wrote:
 > Lo stesso problema si ripresenterà (amplificato) con Clawhammer.
 > Sappiamo che solo una parte delle applicazioni beneficerà in modo
 > apprezzabile della minore latenza del sottosistema memoria, voglio
 > vedere come giustificherai la cpu Amd...............;-).
Uh?!?!?
Guarda che c'e' una bella differenza tra sfruttare l'SMT dei P4 con HT
e sfruttare la minor latenza della memoria "esterna".
Per sfruttare *bene* l'SMT devi:
1) codificare le applicazioni in modo da usare piu thread
     (se usi piu *processi* l'SMT da meno vantaggi)
     *anche* se il programma normalmente non trae vantaggio
     dal far girare piu thread su sistemi multiprocessore;
2) *cambiare* le block optimization in modo da sfruttare
     implicitamente meta della cache L1 ed L2 (devi "coabitare"
     con un altro thread, se setti la block optimization
     per sfruttare tutta la cache finisce che i thread in coabitazione
     "si fanno i dispetti" fottendosi a vicenda le linee di cache).
     Questo *abbassa* le prestazioni in un sistema non-SMT
     (anche se magari e' multiprocessore si ritrova con codice
      ottimizzato per sfruttare mezza cache), ma le alza su un sistema
     SMT.
In caso contrario risci di trovardi con applicazioni che vanno
piu veloci se disabiliti l'SMT.
Per sfruttare *bene* la minor latenza della ram devi:
1) eseguire il programma.
     Non importa per quale cpu sia stato ottimizzato, andra' piu
     veloce rispetto ad un sistema con pari cache e pari IPC. :-)
Se poi l'applicazione "sta tutta in cache" i vantaggi della
minor latenza si notano poco, ma su "roba da server" si notano
eccome! (e senza dove riscrivere una riga di codice o ricompilare)
L. Micheletto

 eccome! (e senza dove riscrivere una riga di codice o ricompilare)
Ecco hai colto nel segno.
Ho i miei dubbi che le applicazioni office faranno faville su
Clawhammer, come pure certi programmi cpu intensivi di
simulazione strutturale ove il lavoro maggiore si svolge in
cache e il traffico bus non giustifica tali sofisticherie. Ovvio
che nessun sw lavora tutto in cache, ma non tutto il sw vive
di intenso traffico con la ram. Il beneficio è sempre presente,
ma giustifica gli sforzi?
Hai colto nel segno, Hammer è pensato per il mercato server
e poi mozzato per proporlo in quello consumer.
Il caso Ultrasparc è emblematico, il memory integrato serve
a gestire meglio un'applicazione server.
Ciao.
Alberto.

      SMT.
Sembrerebbe la soluzione ideale ma......
ma non sembra che la soluzione Intel sia in questi termini,
ovvero mi pare che si voglia bypassare la ottimazione del
codice in senso SMT, delegando tutto a una logica cablata
del processore che operi sulle istruzioni della trace cache.
In questo modo si ovvierebbe alla mancanza di sw adatto e
ai problemi di coabitazione in cache. Penso che sia il
microprogramma a farla da padrone, scegliendo opportunamente
gli spezzoni di codice allo scopo di non mettere in crisi la
gerarchia di memoria; insomma una organizzazione ''intelligente''
del lavoro. Inoltre la limitata capacità della trace sembra
una soluzione ponderata, dovuta in primis ai limiti della capacità
di organizzazione in senso HT della cpu, in secondo luogo alla
necessità di ridurre le latenze al minimo, curando la velocità di
svuotamento e riempimento dei dati verso la L2.
Forse è questo il motivo del mancato aumento della trace nel
North, la logica di controllo non riesce a organizzare più di
tot istruzioni a ciclo alle elevate frequenze del P4.
E' probabile che nel Prescott si sia curato questo aspetto.
Boh..................?
Ciao.
Alberto.

 p4 quindi non necessita del smt.
Beh certamente tornerebbe utile per aumentare l'efficienza, il
problema dello svuotamento della pipe è sempre presente,
anche se meno grave. Mi pare che EV8 prevedesse SMT
in una qualche incarnazione....................
Ciao.
Alberto.

 ma giustifica gli sforzi?
Si, ma gli Hammer oltre al memory controller integrato
hanno altre feature che aiutano a tener alte le prestazioni.
Es: gli stadi aggiuntivi sulle pipeline servono anche per
     aumentare la media delle istruzioni eseguite per ciclo
     (questo torna utile nella roba che esegue calcoli intensivi).
Se poi lo si sfrutta in modo a 64bit (come faranno *certamente*
tutti quelli che usano Linux) i registri extra daranno un ulteriore
spinta alle prestazioni.
Sembra una cosa "banale" ma ogni registro in piu si traduce
in un accesso in meno alla memoria nei loop interni
del codice "intensivo", questo a parita di banda e di sistema
di gestione load/store si traduce in un aumento tangibile
di prestazioni.
Prova a compilare codice che fa calcoli pesanti con e senza
ottimizzazioni su registri e vedrai che la cosa si nota
pure con gli x86 (che sono tra le cpu con maggior penuria
di registri interni "di uso generale").
L. Micheletto

cache e il traffico bus non giustifica tali sofisticherie. Ovvio
mah, il tempo delle demo da 4kb e' passato - oggi se un'applicazione
non ha un memory-footprint da 32mb non sono contenti, fosse anche
pong.
Sotto Wxp basta il primo accesso al kernel a trasharti la cache, tutto
sommato...


in una qualche incarnazione....................
ev8 afaik no (per dire il vero di dati su come sia effettivamente
strutturato il core esecutivo ce ne sono pochi, quasi tutta la
documentazione in giro parla del nuovo bus seriale e dei bus memoria
integrati...) - il predecessore di Power4 usava smt, IBM poi ha deciso
che fosse piu' pratico andare per il multicore-on-die visto che ci
rientravano con i transistors...
in genere il smt per l'appunto e' una soluzione che permette di avere
alcuni dei benefici del smp riducendo il conto dei transistor totali -
se puoi permetterti di andare in smp pero' e' ovviamente piu'
efficiente.
questo in una situazione con isa altamente efficiente (per quanto
riguarda il "costo" in transistor/potenza) - il caso degli x86 rimane
come sempre particolare con la sua orrida risposta al salire del
parallelismo interno e si tentano ancora tutte le vie possibili per
migliorarne l'efficienza, Intel ha avuto l'idea del smt con
megapipeline, Amd ha scelto un'altra strada (hemm, ancora _quale_ non
e' che sia poi tanto chiaro, ma dati i risultati _qualcosa_ hanno
sicuramente fatto ^___^;;).
e' una questione di bilanciamento risorse/potenza, ovviamente - e'
impossibile dire quale sia la strada "perfetta" e anche soltanto dire
quale sia la "migliore" si sbatte i denti sul fatto che in realta'
delle strategie interne se ne sa' poco perfino a posteriori (intel
avrebbe potuto introdurre smt efficiente gia' al rilascio del p4 se
non avesse dirottato le risorse verso itanium oppure e' il contrario,
l'abbandono del p4 come piattaforma high-end e il buttarsi su qualcosa
di azzardato come itanium e' dipeso proprio dall'incapacita' dei
tecnici intel di trasformare tante ottime idee in silicio con le
tecnologie disponibili all'epoca? da che dipendono realmente tutti i
ritardi di amd? ecc...)


 E' probabile che nel Prescott si sia curato questo aspetto.
Piu che altro, il Prescott e' stato rifatto da capo a piedi
rispetto a Northwood e Willamette, questo permette di fare
con calma cambiamenti radicali (visto che intanto se ci sono
problemi se ne puo ritardare l'uscita e spingere ancora
piu in su di frequenza i Northwood).
L. Micheletto

 rientravano con i transistors...
E che ne diresti di una soluzione dual core con multi treading,
non sembra la soluzione ideale? si avrebbero entrambi i benefici,
anche se forse si complicherebbe la baracca......
Ciao.
Alberto.

 sommato...
A certo.......
Insomma quì ognuno ha scelto la sua strada, Intel punta sulla
cache, Amd vede di sveltire il rapporto con la ram di sistema.
Dato che ad ogni raddoppio della cache si riduce il traffico bus
del 30%, si saranno fatti i loro conti........
Vedremo quale soluzione arroventerà meno la cpu :-).
Ciao.
Alberto.

 Piu che altro, il Prescott e' stato rifatto da capo a piedi
E' sperabile, anche se ho i miei dubbi. Per me continueranno
a puntare tutto sulla caratteristica più prosaica della cpu (GHZ).
Effettivamente sarei curioso di sapere quale è stata l'idea
di base del P4, prima cioè della sua uscita forzata; sembra si
siano sprecate tante tante idee e tante tante ore di progettazione :-(,
o forse, semplicemente, si voleva l'impossibile.
Ciao.
Alberto.

cache, Amd vede di sveltire il rapporto con la ram di sistema.
le latenze sul bus intel ha fatto gia' il possibile per ridurle al
minimo, purtroppo il progetto di base (gtl) e' decisamente vetusto ed
originariamente pensato per target totalmente diversi  - hanno deciso
di non tagliare i ponti con il passato e per quanto lo abbiano
strizzato al limite piu' di tanto non ci possono fare...
la cache serve a tutti - piu' e' alto l'ipc e piu' dati gli devi
pompare (altrimenti hai la pipe in stallo e sono dolori...), vedrai
che opteron a 512kb durera' poco sul mercato high-end (il motivo
dietro questo modello e' condividere il die con claw desktop - penso
proprio  che sara' lo stesso identico processore ma con i bus ht e ram
extra non collegati nel die... in questo modo giocano sulla produzione
in grandissimi volumi per abbattere i costi).
le versioni piu' prestazionali (a budget estremo...) salirano
rapidamente di L2 (anche perche' i dati a 64bit hanno un certo costo
di overhead in cache...).
quanto al modello della L1 e' piu' intimamente connesso ala soluzione
scelta per pipeline ed unita' esecutive, bisogna considerare tutto in
blocco - il livello di pre-decode della trace cache e' indubbiamente
un colpo di genio ma richiede latenze incredibilmente basse, e' molto
difficile da implementare in maniera corretta (vedi i primi P4 1.5ghz
prima revisione che stallavano continuamente...) dubito che amd si
lanci in quella direzione, i tempi tecnici per implementarla senza
errori sarebbero troppo lunghi (anche se a .09u le cose si fanno molto
piu' semplici... vedremo.)


anche se forse si complicherebbe la baracca......
beh, rimane sempre una questione di equilibrio... potrebbe essere
perfetto oppure potrebbe essere piu' pratico risparmiare transistor
sul smt ed incrementare le cache... le possibilita' sono infinite.
certo che se cerchi di immaginarti il diagramma di una cosina del
genere viene fuori un piccolo gioiello... :-)
humm... piu' o meno approposito, hai visto che genere di giocattolini
stanno tirando fuori nell'embedded di recente? stavo studiandomi il
nuovo IMAP usato negli ultimi palm... un core Arm 9xx + un DSP
avanzato TI interconnessi fra di loro con un casino di cludge intorno
(controller wireless, controller lcd avanzato ecc...).
questo in .15.... 
in .09 ci infilano l'intero computer in quei cosi... ^____^


nuovo IMAP usato negli ultimi palm... un core Arm 9xx + un DSP
..sigh, l'eta'... Omap 1510 - non sto parlando di protocolli di posta
avanzati... ^____^;;
