Dual Core e HyperThreading: un possibile bug

[sirus]

perchè? senza andare troppo sul tecnico ma senza rispondere con un "perchè sì"..

il motivo è banale, gli athlon64 sono nati con la "ciruiteria" integrata per supportare i 64bit, mentre i p4 (prescott) non sono nati per essere proci a 64bit ma a 32bit...l'introduzione dei 64bit di intel è stata una mossa per tentare di arginare il fenomeno AMD64
poi se cerchi bench su internet noterai che in ambiente 64bit la differenza già presente tra athlon64 e p4 diventa quasi una voragine...
e non parlo di soli bench come 3dmark o spi ma parlo anche di compilazione che imho è uno dei parametri più importanti per verificare la bontà di una architettura

[sirus]

intel mi sa che prima o poi pagherà la sua strategia di fare pipeline lunghissime per aumentare i mhz.. è una architettura con un equilibrio precario e soffre un po' di innerzia! Anzi fin'ora se l'è cavata bene grazie all'HT... spero per lei che si risolva pure questa!

intel ha già fermato la corsa ai mhz e con le prossime architutture avremo delle cpu più simili ai pm con pipe + corte, frequenze + basse ma efficienza nettamente superiore (parlando di soli calcoli i pm sono quei proci che a 2.6ghz fanno 28" al pi )

[^TiGeRShArK^]

parlando di soli calcoli ke entrano interamente nella cache L2 di 2 MB a BASSISSIMA latenza.......
Nelle applicazioni normali a parità di frequenza i Pentium M non hanno un comportamento poi tanto dissimile rispetto agli A64...... pekkato ke questi ultimi scalino assai meglio in frequenza......

[MiKeLezZ]

Da quello che ho capito il problema non è tra il "funzionare" o il "non funzionare" ma è tra il "funzionare benino" e il "funzionare molto bene".
Speriamo esca questa patch, in ogni caso questo ci tange poco visto che 4 core non sono ancora previsti per l'utenza media desktop.

[MaxArt]

Originariamente inviato da B|4KWH|T3
Non penso proprio, o altrimenti il problema avrebbe dovuto già manifestarsi con la piattaforme Xeon a 2 processori (che poi è esattamente quanto hanno fatto gli autori dell'articolo per verificare il bug su windows XP).

Ma infatti si è manifestato su piattaforme dual Xeon! Non capisco che vuoi dire, scusa.

[leoneazzurro]

Originariamente inviato da MiKeLezZ
Da quello che ho capito il problema non è tra il "funzionare" o il "non funzionare" ma è tra il "funzionare benino" e il "funzionare molto bene".
Speriamo esca questa patch, in ogni caso questo ci tange poco visto che 4 core non sono ancora previsti per l'utenza media desktop.

Beh, direi che il problema è che proprio funziona decisamente male, non "benino" (in pratica con 2 thread invece di sfruttare 2 processori ne sfrutto uno solo, anche se con HT). Se la cosa si ripetesse sulla versione server, non sarebbe una cosa buona: in pratica potrebbe essere meglio disabilitare l'HT.

Comunque ritengo che diversamente dall'altra volta, in questo caso MS farà uscire qualche patch.

[ilkarro]

Sinceramente non avevo mai sentito parlare di questo problema, eppure i sistemi Dual Xeon DP con HT (2 core fisici 4 core logici) non sono di certo usciti ieri. Appena mi arriva l'alimentatore eseguo anche io qualche test analogo, sono molto curioso

[leoneazzurro]

Originariamente inviato da ilkarro
Sinceramente non avevo mai sentito parlare di questo problema, eppure i sistemi Dual Xeon DP con HT (2 core fisici 4 core logici) non sono di certo usciti ieri. Appena mi arriva l'alimentatore eseguo anche io qualche test analogo, sono molto curioso

E' possibile allora che la cosa sia limitata a Win XP desktop, nel qual caso però le future CPU Dual Core EE sarebbero comunque penalizzate.

[Superboy]

So come vengono gestite le cpu virtuali o meno all'interno dello scheduler di linux, il fatto è che è errato porgere al so delle risorse virtualmente idempotenti quando in realtà non lo sono! quindi sopperire a questa "asimmetricità" con una patch sw mi sembra solo un accrocchio per il motivo espresso nel mio post precedente! ht è destinato a morire con il progetto P4 per i motivi espressi sempre sopra!
Una patch dello scheduler non porterebbe ad un corretto sfruttamento delle risorse inoltre introdurrebbe inutile overhead nei processori che non necessitano di questo accorgimento!

[MaxArt]

Originariamente inviato da Superboy
ht è destinato a morire con il progetto P4 per i motivi espressi sempre sopra!

Finché esisteranno processori con pipeline così lunghe l'HT avrà ragion d'essere, IMHO.

Una patch dello scheduler non porterebbe ad un corretto sfruttamento delle risorse inoltre introdurrebbe inutile overhead nei processori che non necessitano di questo accorgimento!

Vuoi dire che questo difetto ce l'ha TMPGEnc o cosa?

[tiMo]

Originariamente inviato da sirus
sicuramente si trattava di xeon dato che gli itanium si basano su una architettura completamente diversa
poi è risaputo che le implementazioni dei 64bit di intel e amd sono impari...mille volte meglio quella di amd

E' appunto proprio quello che avevo affermato anche se implicitamente visto che non è questo il tema del thread. Il supporto nativo ai 64 bit di AMD permette di ottenere prestazioni superiori anche con un compilatore Intel ottimizzato per le proprie cpu. Il fatto si commenta da solo e IMO porta implicazioni ben piu' rilevanti del semplice considerare il dato come un semplice bench fra i tanti possibili.
Tornando in Thread, pare che Intel si trovi indietro anche rispetto all'integrazione della piattforma EMT64 con il prossimo venturo WinXP64.

[Superboy]

Pipeline da 20 a 30 statdi sono solo nel progetto P4 se lui muore se le porta con se visto che la strata intrappresa è il parallelismo multicore...
Non mi riferisco a nessun applicativo, non ne ho mai nominati. Lo scheduler è quella porzione di codice che si preoccupa di ordinare secondo un certo criterio la coda dei processi.

[MaxArt]

Originariamente inviato da Superboy
Non mi riferisco a nessun applicativo, non ne ho mai nominati. Lo scheduler è quella porzione di codice che si preoccupa di ordinare secondo un certo criterio la coda dei processi.

E perché una riorganizzazione dello scheduler dovrebbe portare detrimenti ad altri processori?

[cionci]

Originariamente inviato da MaxArt
E perché una riorganizzazione dello scheduler dovrebbe portare detrimenti ad altri processori?

Infatti basta che se il 2 ed il 3 sono liberi il thread venga assegnato al 3...

[DioBrando]

Originariamente inviato da leoneazzurro
Beh, direi che il problema è che proprio funziona decisamente male, non "benino" (in pratica con 2 thread invece di sfruttare 2 processori ne sfrutto uno solo, anche se con HT). Se la cosa si ripetesse sulla versione server, non sarebbe una cosa buona: in pratica potrebbe essere meglio disabilitare l'HT.

Comunque ritengo che diversamente dall'altra volta, in questo caso MS farà uscire qualche patch.

n credo sia sufficiente l'uscita di qlc patch per sistemare il problema...se è così grave come sembra ( e legando la causa al kernel, lo è), servirebbe forse la riscrittura di una parte importante del sorgente...


cmq sn d'accordo con te, i futuri Dual Core EE ne sarebbero penalizzati, anzi, verrebbe meno la loro presenza stessa dato che la differenza sostanziale con i "fratelli minori" stà proprio nella presenza dell'HT.

[ilkarro]

Qualcuno sa se Windows Server 2003 soffre del medesimo problema?

[max84]

da sirus
il motivo è banale, gli athlon64 sono nati con la "ciruiteria" integrata per supportare i 64bit, mentre i p4 (prescott) non sono nati per essere proci a 64bit ma a 32bit...l'introduzione dei 64bit di intel è stata una mossa per tentare di arginare il fenomeno AMD64
poi se cerchi bench su internet noterai che in ambiente 64bit la differenza già presente tra athlon64 e p4 diventa quasi una voragine...
e non parlo di soli bench come 3dmark o spi ma parlo anche di compilazione che imho è uno dei parametri più importanti per verificare la bontà di una architettura

intel ha già fermato la corsa ai mhz e con le prossime architutture avremo delle cpu più simili ai pm con pipe + corte, frequenze + basse ma efficienza nettamente superiore (parlando di soli calcoli i pm sono quei proci che a 2.6ghz fanno 28" al pi )

be però ora mi viene da chiedermi come funzionano davvero le pipeline, intendo: ma che sono? ed i registri, di cui si parla spesso, che "cosa" sono? righe di codice? ciruiti appositi?
vorrei andare al principio delle cose ma le mie conoscenze (com vedi in tale campo equivalenti al nulla) non me lo permettono

[Mac666]

Provo a dare una risposta dal basso delle mie (dis)conoscenze

La cpu per eseguire istruzioni e processare dati deve averli disponibili al suo interno, ed i registri fungono proprio da "contenitori" per le istruzioni/dati che la cpu elaborerà; non essendo addentro alla cosa posso supporre che siano gruppi di transistor che in qualche modo permettono di mantenere le informazioni (sotto forma di corrente) al loro interno.
Da quel che mi ricordo nell'8086 c'erano vari registri a 16 bit, da cui la capacità elaborativa parallela della cpu; gli Athlon64 odierni hanno registri interni a 64 bit e suppongo anche il bus di collegamento con le altre periferiche.
Questo a grandi linee quello che fanno i registri.
Per quanto riguarda invece la pipeline, definiamo prima le due operazioni basilari che un processore effettua per l'esecuzione di un'istruzione:

-FETCH
-EXECUTE

La prima è il precarimento dell'istruzione nei registri (se non ricordo male), mentre la seconda è l'effettiva esecuzione della stessa da parte della cpu.

Ora il concetto alla base della pipeline è molto semplice, perchè aspettare la fine dell'esecuzione dell'istruzione corrente prima di caricare la successiva?
Se noi precarichiamo l'istruzione che dovrà essere eseguita successivamente quando la cpu sta eseguendo l'istruzione corrente possiamo risparmiare tempo.
Questo è il concetto che ha portato allo sviluppo di pipeline sempre più lunghe.
Sorge però un problema rilevante.
Perchè, se nel caso di programmi sequenziali la prossima istruzione da eseguire sarà sempre conosciuta con esattezza, lo stesso potrebbe non accadere (ed anzi spessissimo è così) nel caso di programmi condizionali che prevedano salti all'interno del codice a seconda del verificarsi o meno di talune condizioni.
Per sfruttare la pipeline anche con questi particolari programmi sono stati sviluppati algoritmi di predizione che permettono di conoscere con una certa sicurezza quale sarà l'istruzione successiva da eseguire e quindi da caricare all'interno del processore.

Il problema è che per quanto precise possano essere queste previsioni quando il numero di errori predittivi diventa elevato (ad esempio con programmi altamente condizionali come possono essere, suppongo, i videogames (correggettemi se sbaglio)), l'utilizzo di una pipeline così profonda come quella implementata da Intel porta a tempi di svuotamento e ricaricamento della stessa molto più elevati rispetto a quello necessario ad esempio sui processori AMD che prevedono una pipeline più snella.

Questo è anche uno dei motivi per il quale i processori Intel sono più performanti in quei compiti piuttosto "lineari", come può essere ad esempio la riproduzione di un flusso multimediale.

Spero di averti aiutato
Adesso aspettiamo l'intervento di quei pazzoidi degli ingegneri (informatici od elettronici che siano ) che espongano in maniera più completa ed accurata i concetti da me accennati :P

[leoneazzurro]

Magari un giretto su Arstechnica non fa male a chi ne vuole capire di più:

www.arstechnica.com

[leoneazzurro]

Originariamente inviato da DioBrando
n credo sia sufficiente l'uscita di qlc patch per sistemare il problema...se è così grave come sembra ( e legando la causa al kernel, lo è), servirebbe forse la riscrittura di una parte importante del sorgente...

Un bel Service pack 3 (Intel Edition) e tutto torna a posto