Dual Core e HyperThreading: un possibile bug

[Redazione di Hardware Upg]

Link alla notizia: http://news.hwupgrade.it/14179.html

Alcune analisi con processori Xeon DP hanno evidenziato un possibile problema del sistema operativo Windows XP, nella gestione di sistemi biprocessore con tecnologia HyperThreading attivata

Click sul link per visualizzare la notizia.

[Sig. Stroboscopico]

Se non altro il tempo per risolvere questo eventuale bug non manca di certo.

Quindi probabilmente lo stesso problema ci potrebbe essere anche con Xp 64 bit, no?
Strano che non l'abbiano provato... gli Xeon dual covrebbero avere le istruzioni per il 64 bit, vero?

Ciao!

[sirus]

imho questo problema non si verificherebbe con windows 2003 server che gestisce fino a 4 cpu...
xp è nato per gestirne 2 e quindi credo che con 4 core (seppur logici) il sistema non riesca a rispondere correttamente

[Dumah Brazorf]

Concordo, XP non è stato pensato in questa ottica, ha tutte le scusanti per questo "bug".
Ciao.

[ultimate_sayan]

Quando è uscito WinXP di certo il dual core non pareva essere una realtà così vicina... ci sta benissimo che il sistema non risulti adeguato a questo tipo di tecnologia. Spero che Microsoft possa rimediare agli errori del passato (Win2000) e rilasci un fix che permetta l'ottimizzazione per 4cpu. Sono fiducioso visto che WinXP dovrà durare ancora molto tempo e sia Intel che AMD (ma soprattutto la prima) premeranno per fare in modo che questo avvenga.

[Nemios]

Beh, l'articolo dice che lo stesso bug era presente in Win2000. Se si riferisce anche a Win2000 Server non ci sono molte scusanti, fino a poco tempo fa era l'S.O. di riferimento per i server di casa MS...

[MaxArt]

Originariamente inviato da sirus
imho questo problema non si verificherebbe con windows 2003 server che gestisce fino a 4 cpu...

Ci metto la mano sul fuoco che capiterà anche col 2003 Server
Il fatto è insito nel kernel, che non fa distinzioni tra CPU fisiche e logiche, quindi quando ci sono solo due thread da eseguire vengono mandati alle CPU logiche di una sola CPU fisica, facendo sì che il sistema in quegli istanti si comporti come un comune single core con HT.

[Rubberick]

Fatto sta che la microsoft si dovrebbe impegnare con tutti gli stramiliardi che ha a mettere mass programmatori a sistemare tutto cio' che c'e' da sistemare...

[F1R3BL4D3]

Bhe io all'IDF avevo visto uno screen con fino a 16 processori attivi (con HT chiaramente) su win....bho...

[Necromachine]

Comunque è un problema del SO, non della CPU. Insomma, con una piccola patch x winzozzXP il problema si potrebbe risolvere tranquillamente !!

[soft_karma]

Tranquilli, trattandosi di intel la microsoft aggiornerà quanto prima il proprio Sistema.

[sirus]

Il fatto è insito nel kernel, che non fa distinzioni tra CPU fisiche e logiche, quindi quando ci sono solo due thread da eseguire vengono mandati alle CPU logiche di una sola CPU fisica, facendo sì che il sistema in quegli istanti si comporti come un comune single core con HT.

mi vedi completamente d'accordo con la tua afferamazione, il problema non è tanto dell'architettura dual core di intel ma del kernel del so...
tuttavia credo che questa avverrebbe anche con kernel linux e unix e il motivo credo sia semplice...le cpu fisiche sono la numero 0 e la 2 utilizzando HT e il so per distribuire i thread va in ordine (ponendo che tt le cpu siano libere) e fornisce lavoro prima alla cpu 0 (fisica) e poi alla cpu 1 (logica).
la soluzione più logica sarebbe (durante il processo di installazione) mappare le due cpu fisiche come numeri 0 e 1 le due cpu logiche come 2 e 3.
tuttavia non so quanto questo possa essere fattibile sicuramente i programmatori di win e linux potranno trovare una soluzione a questo problema

[tiMo]

Non credo sia una questione semplice risolvere questo problema.
Ricordo che sul medesimo sito è apparso un articolo ove si ipotizza che la superiorità di AMD64 su codice a 64 bit sia da imputarsi in parte a questioni di compilazione. Tempo fa usci' una notizia ove mostravano come in alcuni bench legati al compilatore Intel Fortran AMD64 batteva Itanium (o lo Xeon, non ricordo) anche in presenza di ottimizzazioni per cpu Intel.
Ergo, la questione programmazione è tutt'altro che secondaria e lo sarà a maggior ragione in futuro visto che andremo incontro a cpu dual core.
IMHO
tiMo

[B|4KWH|T3]

X MaxArt:

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).

[Superboy]

Il problema non è assolutamente del SO, ma bensì del progetto p4: per sopperire alle mostruose latenze derivanti dalla lunghissima pipeline si son inventati un modo per riempirle ovvero HT. Purtroppo il so "crede" di avere sotto unità di esecuzione idempotenti ma questo non è vero proprio per questo trucco di intel. Dubito dei risultati che potrà ottenere una patch allo scheduler in quanto egli non sa se il thread da eseguire sarà abbastanza peasnte da beneficiare di un core "fresco" oppure soltanto un thread senza grossi carichi che sarebbe meglio far girare sul secondo core logico...

[PhoEniX-VooDoo]

Questa è meglio della capra che compa sopra la panca...

lo scheduler di Windows XP Professional manda in esecuzione un task su un Core logico del primo Core fisico, e il secondo task non sul primo Core logico del secondo Core fisico, ma sul secondo Core logico del primo Core fisico

[sirus]

Non credo sia una questione semplice risolvere questo problema.
Ricordo che sul medesimo sito è apparso un articolo ove si ipotizza che la superiorità di AMD64 su codice a 64 bit sia da imputarsi in parte a questioni di compilazione. Tempo fa usci' una notizia ove mostravano come in alcuni bench legati al compilatore Intel Fortran AMD64 batteva Itanium (o lo Xeon, non ricordo) anche in presenza di ottimizzazioni per cpu Intel.
Ergo, la questione programmazione è tutt'altro che secondaria e lo sarà a maggior raggione in futuro visto che andremo incontro a cpu dual core.
IMHO
tiMo

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

[sirus]

x PhoEnix-VooDoo
se leggi il mio post a inizio pagina ti spiego il perchè funziona cos'

SO

Il problema non è assolutamente del SO, ma bensì del progetto p4: per sopperire alle mostruose latenze derivanti dalla lunghissima pipeline si son inventati un modo per riempirle ovvero HT. Purtroppo il so "crede" di avere sotto unità di esecuzione idempotenti ma questo non è vero proprio per questo trucco di intel. Dubito dei risultati che potrà ottenere una patch allo scheduler in quanto egli non sa se il thread da eseguire sarà abbastanza peasnte da beneficiare di un core "fresco" oppure soltanto un thread senza grossi carichi che sarebbe meglio far girare sul secondo core logico...

se leggi il mio post a inizio pagina ho spiegato il motivo per cui il problema è il so ... cmq credo che non sia tanto un problema di schedeuler delle applicazioni...è necessario dare dei "livelli di priorità diversi" (scusate l'espressione ma non mi è venuto nulla di meglio) e distinguere tra core fisico (reale) e core logico

[max84]

poi è risaputo che le implementazioni dei 64bit di intel e amd sono impari...mille volte meglio quella di amd

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

[Firedraw]

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!