Newsgroup: it.comp.hardware.cpu
Titolo: Hyperthreading

nteressante questo articolo:
http://www.gamepc.com/reviews/printreview.asp?review=ppso&mscssid=&tp=
Lascio a voi i commenti...
-- 
Sidewinder  
---------------------------------------------------------------------
%DCL-MEM-BAD, bad memory
VMS-F-PDGERS, pudding between the ears
---------------------------------------------------------------------

]
» 
» Lascio a voi i commenti...
Cosa c'è da commentare?
O è stato fatto male o l'Hyperthreading non serve ad una mazza.
Sono più dell'avviso che gli 8kb di cache L1 siano totalmente saturati 
da una tecnologia del genere.
Chi era che diceva che con l'Hyperthreading Intel sarebbe stata 
irraggiungibile? Inizia con A...
Il test "CPU Benchmark - Hyper-Threading Support (SMT)" sia abilitato 
che disabilitato parla più di tutti... aggiungi quello per i filtri 
Photoshop...
Se dovessi acquistare una configurazione Dual Xeon solo per avere una 
compilazione del kernel più veloce (il che significa spendere 8 volte di 
più di un sistema con Athlon MP) sarebbe come dire che mando a quel 
paese tutta l'idea di GNU, Software Free per buttare i soldi in un 
processore.
Non se ne parla ;o)
-- 
+ > Piersandro Guerrera <-> PaRRoT <-> 
par...@edengames.net
  < +
+ > ICQ: 8372114 <--> Eden.Games - 
http://www.edengames.net
  < +
-> PGP Key Available - 
http://parrot.edengames.net/pgpkey.pub
 <-
+ > News Hardware and Games <---> 
http://news.edengames.net
  < +

 da una tecnologia del genere.
Probabile, in fin dei conti diventano, mediamente,
4KB per thread...
Comunque son un po' sorpreso dal fatto che alcuni
test risultano piu` lenti con HT enabled.
Insomma, spero che in intel abbiano fatto un po'
di prove prima di buttarsi su questa strada.
bye,
-- 
  Piergiorgio Sartor


Sulla carta l'HT era una idea interessante, ma sul campo e' venuto fuori
che non serve una ceppa...
E mi sa che ne passera di tempo per vedere del SW realmente ottimizzato
per HT.
-- 
Sidewinder  
---------------------------------------------------------------------
As of next Thursday, UNIX will be flushed in favor of TOPS-10.
Please update your programs.
---------------------------------------------------------------------

 per HT.
Forse non avrebbe neanche senso, penso che HT sia stato
pensato per non dover riscrivere il SW, altrimenti
(forse) un buon compilatore potrebbe sfruttare, magari
con qualche hint, meglio il pipeline.
HT, secondo me, e` stato pensato per compensare
l'inefficienza del lungo pipeline del P4, con
l'idea di non dover toccare il SW, se non per
il discorso MP, ovviamente.
In realta`, probabilmente, la cosa e` un po' piu`
complicata di quanto non si aspettassero.
Per esempio, in caso di conflitti sull'uso delle
risorse e relativi allineamenti delle istruzioni
successive... Questo potrebbe spiegare certi
crolli prestazionali.
bye,
-- 
  Piergiorgio Sartor

complicata di quanto non si aspettassero.
Mah.. onestamente a me sembrava molto di difficile 
attuazione.. ma non e' proprio il mio campo e stavo 
a vedere cosa sarebbe successo..
Imho , per una soluzione del genere, l'architettura va 
pensata ex novo e con priorita' assoluta alla "saturazione"
della pipe. 
Qui mi pare si sia pensato di usare i "buchi" (inevitabili)
di una pipe lunga per eseguire delle istruzioni....
Ovvero si e' adattata una idea all'esistente.. a volte
funziona , a volte meno :(
ciao r.d.

 con qualche hint, meglio il pipeline.
Uhmm.. Mi bazzica per la testa un pensiero... Non sarebbe stato
possibile per Intel realizzare delle SSE2 che sfruttassero l'HThread?
Voglio dire... L'HThread se non usato in software pensato appositamente
peggiora le prestazioni generali a causa di conflitti nell'utilizzo
delle risorse tra i 2 processi (questo perchè è stato progettato male il
metodo di implementazione di HThread IMHO) ma allora perchè non fare in
modo che le SSE2 si preoccupassero di sistemare questa feature nel
giusto modo? D'altra parte prima o poi le SH cominceranno a sviluppare
per SSE2, come mai non sono state sfruttate per permettere una cosa
simile? Non è proprio possibile oppure hanno preferito tenere nascosta
questa cosa all'inizio per problemi di implementazione e costo?
-- 
e-mail: dialtone#/N0SPAM\#@
aruba.it
     |Non vorrei piacere a tutti
togliere #N0SPAM# per inviare           |Avrei meno stima di me stesso
Powered by Debian Woody                 |Se piacessi a certa gente
On Linux 2.4.17 - WM 0.80.0             |

 questa cosa all'inizio per problemi di implementazione e costo?
Secondo me sono due storie separate, da un lato SSE2
per fornire prestazioni multimediali (o quello che e`)
piu` avanzate, con necessita` di riscrittura di codice,
forse solo di driver specifici, pero`.
Dall'altro HT per sfruttare meglio il pipeline _senza_
dover riscrivere il SW, ma solo avendo il supporto
nell'OS, cose che e` sempre piu` comune.
bye,
-- 
  Piergiorgio Sartor

Lascio a voi i commenti...
hehe, i bench mi pare parlino chiaro: quel processore ha gli stessi
problemi dei primi p4 1.5ghz - si surriscalda, scatta il limitatore e
rallenta... :-)
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

rallenta... :-)
forse sono stato troppo telegrafico, mi spiego meglio:
nei bench dove il smt dovrebbe dare benefici minimi c'e' un certo
incremento di prestazioni (addirittura e' piu' veloce sulla
compilazione linux in single-thread, cosa che normalmente mette in
crisi le macchine smp visto che la seconda cpu occupa banda ma non
contribuisce).
nei bench dove invece dovrebbe (anche se il smt fosse implementato
veramente da cani) dare dei benefici ingenti, da risultati _peggiori_
che con smt abilitato...
che attivare il smt avrebbe fatto balzare in alto consumi e
dissipazione termica lo sapevamo per certo, dei risultati del genere
si possono spiegare soltanto con il limitatore che si innesta quando
entrambe le pipelines smt sono pienamente a regime (e quindi il
processore genera il massimo del calore).


4KB per thread...
in teoria dovrebbe essere il contrario, ovvero il smt dovrebbe ridurre
drasticamente l'overhead dovuto da prefetch errati per passaggio ad
altro thread (visto quanto il p4 si appoggia ai vari "speculative
fetch" questi accadono molto piu' spesso dei miss)...


 fetch" questi accadono molto piu' spesso dei miss)...
In caso si MT SW.
Supponi, pero`, di avere due thread perfetti
in cache.
In questo caso ogni thread ha 4KB a disposizione.
Il ridicolo capita se hai due loop di 4KB + 1 byte...
bye,
-- 
piergiorgio

 processore genera il massimo del calore).
Spero dipenda da programmi che ottimizzati per le dimensioni
della cache producono un trashing massiccio su L1 ed L2 (visto che
con due thread "ottimizzati per sfruttare tutta la cache" in esecuzione
il working set raddoppia di ampiezza), se dipendesse veramente dal 
surriscaldamento prodotto dalle ALU c'e' da chiedersi chi possa aver dato 
l'OK al rilascio delle cpu con SMT attivato.
... oppure le cpu su cui era stato fatto il test avevano il dissipatore
montato da uno di quei tipi che "sconsigliano" gli AMD perche scaldano
troppo e danno problemi (a loro). >:-)
un Lorenzo che le leggi della fisica non perdonano

l'OK al rilascio delle cpu con SMT attivato.
Beh però in fondo a questo si può rimediare, se i thread non stanno in
cache è un guaio :-)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
Tessera #008 B.A.G., #000 DPPSJ, #013 B.A.T
"Il Grande Fratello? Non lo farei mai vedere ai miei figli."
(Giovanni Modina, direttore di Canale 5)