Dual Core e HyperThreading: un possibile bug

Dual Core e HyperThreading: un possibile bug

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

di pubblicata il , alle 14:17 nel canale Processori
WindowsMicrosoft
 
I migliori sconti su Amazon oggi
-53%

Amazfit GTR 3, 46 mm, Smartwatch Orologio Intelligente Alexa Integrato, 150 modalità di Allenamento con GPS, AMOLED, Monitor del Sonno, 5 ATM Impermeabile, Durata Batteria di 21 Giorni, SpO2

149.90 69.90€ Compra ora
-40%

FRITZ!Repeater 600 Edition International, Ripetitore - Wi-Fi extender fino a 600 Mbit/s (2,4 GHz), Mesh, Access Point, Interfaccia in italiano

49.99 29.99€ Compra ora
-20%

DJI Neo, mini drone con fotocamera UHD 4K per adulti, 135g drone che vola da solo e ti segue, decollo dalla mano, tracciamento del soggetto, QuickShot, video stabilizzati, (senza radiocomando)

199.00 159.00€ Compra ora
61 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
sirus08 Marzo 2005, 17:05 #11
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
tiMo08 Marzo 2005, 18:00 #12
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|T308 Marzo 2005, 18:07 #13
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).
Superboy08 Marzo 2005, 19:23 #14

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...
PhoEniX-VooDoo08 Marzo 2005, 19:28 #15

Bellissima!!


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


sirus08 Marzo 2005, 19:31 #16
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
sirus08 Marzo 2005, 19:35 #17
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
max8408 Marzo 2005, 19:55 #18
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ì"..
Firedraw08 Marzo 2005, 20:09 #19
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!
sirus08 Marzo 2005, 21:13 #20
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
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^