HyperThreading sugli Athlon64 X2!

[MaxArt]

Scusate il titolo, in effetti è scorretto ma buono per acchiappare! ;)
http://www.x86-secret.com/?option=newsd&nid=870
Si tratta di una furbata di AMD, che inganna i programmi in esecuzione in modo che credano che sia presente l'HyperThreading Technology nel processore (cosa che invece ovviamente non è vera), per far sì che i programmi che inizialmente non prevedevano l'uso di due CPU fisiche ma comunque di due CPU logiche si avvantaggino lo stesso della presenza del doppio core. Leggete l'articolo per altre informazioni.
Mi chiedo ora se gli Athlon64 X2 non implementino tutte le funzionalità di gestione dell'HyperThreading, come le istruzioni MONITOR e MWAIT delle SSE3, che negli ultimi processori single core (Venice, San Diego, Palermo) non sono state implementate.

[checo]

scusa l'ignoranza ma ci sono applicazioni singole che richiedono o sono ottimizzate per hypertreading e allo stesso tempo non lo sono per un dual cpu?

[MaxArt]

Mah, guarda, sono perplesso anche io, ma il commento nella pagina linkata dovrebbe confermare questa congettura...

[jappilas]

scusa l'ignoranza ma ci sono applicazioni singole che richiedono o sono ottimizzate per hypertreading e allo stesso tempo non lo sono per un dual cpu?
beh sì non sono da escludere
dipende da che funzioni si usano per implementare i thread nel proprio programma, e quindi dall' implementazione della thread library...
come vedevo poco tempo fa esistono thread library (e il discorso vale SPECIALMENTE sotto linux perchè sotto win le mfc la fanno parecchio da padrone) che esplicitamente eseguono e sincronizzano i thread su una stessa cpu, serializzandoli in un unico processo... questo perchè i thread verrebbero gestiti internamente, dalla library con cui è linkato il processo a cui appartengono, e non dal kernel, il quale vede il processo come contenente un unico thread

ci si può chiedere quale sia l' utilità di sviluppare codice multithreaded qualora si sia a conoscenza di una limitazione di questo tipo...
intanto questo diventa limitante solo per sistemi multiprocessore, (ma anche su questi il kernel può comunque ripartire i processi -corrispondenti alle diverse applicazioni- tra le varie cpu presenti), perchè su sistemi uniprocessore, tutti i thread in memoria verrebbero comunque eseguiti dall' unica cpu del sistema

inoltre la programmazione multithread può comunque aiutare a mascherare le latenze e migliorare l' efficienza dell' utente ... i tempi di attesa percepiti sono meno influenti e fastidiosi se l' utente vede di poter fare "altro" nel frattempo invece di dover attendere o di restare bloccato in una finestra modale...

[cdimauro]

Mi chiedo ora se gli Athlon64 X2 non implementino tutte le funzionalità di gestione dell'HyperThreading, come le istruzioni MONITOR e MWAIT delle SSE3, che negli ultimi processori single core (Venice, San Diego, Palermo) non sono state implementate.
Dovrebbero essere implementate, ma senza alcun effetto (leggi: si comportano come delle NOP :D).

[capitan_crasy]

Per quale motivo AMD non ha mai introdotto anche lei l'HyperThreading nell'Athlon64 sigle core?

[MaxArt]

Per quale motivo AMD non ha mai introdotto anche lei l'HyperThreading nell'Athlon64 sigle core?E' stato spiegato più volte, ora non ti posso rispondere in dettaglio e ti invito a ricercare qualche post precedente. Per il momento ti dico che l'HyperThreading non è efficiente in processori con pipeline corte come quella degli Athlon. Anche i Pentium M non hanno HT. :)

[capitan_crasy]

E' stato spiegato più volte, ora non ti posso rispondere in dettaglio e ti invito a ricercare qualche post precedente. Per il momento ti dico che l'HyperThreading non è efficiente in processori con pipeline corte come quella degli Athlon. Anche i Pentium M non hanno HT. :)
ok trovato, in un certo senso mi hai risposto in un'altro post! ;)
Una pipeline da 12 stadi quando va in branch missing si svuota abbastanza in fretta, per cui l'HT perde di significato..

[zuLunis]

buco nell'acqua secondo me..

[OverClocK79®]

scusa
cosa intendi per buco nell'acqua? e cosa ti riferisci

BYEZZZZZZ

[Mason]

come vedevo poco tempo fa esistono thread library (e il discorso vale SPECIALMENTE sotto linux perchè sotto win le mfc la fanno parecchio da padrone) che esplicitamente eseguono e sincronizzano i thread su una stessa cpu, serializzandoli in un unico processo... questo perchè i thread verrebbero gestiti internamente, dalla library con cui è linkato il processo a cui appartengono, e non dal kernel, il quale vede il processo come contenente un unico thread


adesso come adesso si usa le nptl, totalmente in kernel space, naturalmente le api per accedere sono sempre le pthread, inoltre le glibc hanno anche delle thread library nel caso debbano girare su kernel che non abbiano i nptl

http://en.wikipedia.org/wiki/NPTL