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.

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!

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

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

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.

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

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 :D
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.

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

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

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

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

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

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

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

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

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

:D :D

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

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

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ì".. ;)

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!

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

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

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

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.

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. :confused:

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.

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

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.

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!

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?

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.

:banned:

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.

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?

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

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.

Qualcuno sa se Windows Server 2003 soffre del medesimo problema?

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 :(

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

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 :D) che espongano in maniera più completa ed accurata i concetti da me accennati :P

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

www.arstechnica.com

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 :D

Ho mal di testa :muro: e quindi aggiungerò solo qualcosina...

Originariamente inviato da Mac666
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àGià delle vere celle di memoria, velocissime, all'interno del processore, per uso immediato.
C'è da dire che un tempo i registri delle CPU avevano ciascuno un compito specifico: uno veniva usato per fare le somme, un altro per "contare", un altro ancora per il resto della divisione e così via. Oggi le cose si sono mantenute parzialmente così nei processori x86, ma per la maggior parte dei compiti ci sono 8 registri "general purpose" (*AX, *BX, *CX, *DX, *SI, *DI, *BP, *SP, anche se in effetti *SP è meglio non toccarlo).
Le estensioni a 64 bit AMD64 e EM64T aggiungono altri 8 registri general purpose, chiamati R9, ..., R16, che danno un certo incremento prestazionale.

non essendo addentro alla cosa posso supporre che siano gruppi di transistor...E che altro? :D

Per la pipeline provo a dare una spiegazione io.
La pipeline multistadio fu dapprima implementata nei primi Pentium (1993) e questo segnò l'inizio dell'architettura superscalare per i processori x86.
Il concetto di una pipeline multistadio può essere assimilato a quello di una catena di montaggio. L'esecuzione di un'istruzione viene scissa in più compiti minori, ed ognuno di questi viene eseguito nei vari stadi che compongono la pipeline, attraverso cui l'istruzione passa sequenzialmente. Chiaramente, non è necessario che un'istruzione venga eseguita dall'inizio alla fine perché si cominci a processare le successive, ed ecco che si può cominciare a decodificare le altre.
Il vantaggio? Più gli stadi sono brevi, meno ci impiega il processore a completarli, e questo consente di salire meglio di frequenza. Detto in parole molto povere! :muro:

La prima è il precarimento dell'istruzione nei registri (se non ricordo male)Nei registri non viene caricata alcuna istruzione. O almeno, non in quelli che dicevamo prima! ;)

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.Si tratta appunto del cosiddetto branch prediction algorithm. In sostanza, il processore tiene memoria di quali istruzioni sono state caricate precedentemente una volta che raggiunge un'istruzione condizionale già incontrata prima: in questo modo (ed è questa la "predizione") il processore ipotizza quali istruzioni caricare e le carica. Se invece la predizione risulta sbagliata, si tratta del branch missing che comporta lo svuotamento della pipeline.
Il branch prediction ovviamente dà il suo meglio nel caso di istruzioni in ciclo.

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))I videogiochi vanno bene, ma vuoi mettere davvero in croce i P4? :) Guardati qualche bench con Matlab o Mathematica. O con qualche compilatore software. Può capitare che il P4 sia il 40% più lento di un Athlon64 "pari grado".

C'è un altro problema che riguarda le pipeline lunghe: l'OOE (Out of Order Execution)... in sostanza può capitare che un'istruzione venga finita di eseguire prima di un'altra... ommadonna! :muro:

Adesso aspettiamo l'intervento di quei pazzoidi degli ingegneri (informatici od elettronici che siano :D)Certamente c'è chi saprà far di meglio, io sono solo un matematico! :)
Col mal di testa! :muro:

Originariamente inviato da leoneazzurro
Un bel Service pack 3 (Intel Edition) e tutto torna a posto :D

in questo caso Ecstrim Ediscion allora :asd:

:D

Non riesco a capire una cosa.

Se dal punto di vista di una dual-cpu con ht posso capire che non si possa a livello hw decidere l' ordine delle cpu (fisiche e logiche), da un punto di vista dual-core, quindi dove l' assegnazione é fissa, non sarebbe più semplice organizzare la cosa via hardware, dentro la cpu stessa, fare cioé cpu1-cpu2-cpu1ht-cpu2ht ?

L'assegnazione di un thread ad un certa CPU lo decide sempre e solo lo scheduler...

Si, questo l' avevo capito (scusatemi se son duro di comprendonio) quel che non capisco é la logica che ha lo scheduler, cioé da dove prende l' ordine delle cpu.

Attualmente se ho capito é come se venissero assegnati come ordine questi: (ammettendo anche cpu=core)

1 - cpu1ht1
2 - cpu1ht2
3 - cpu2ht1
4 - cpu2ht2

Se invece proprio a livello hw avessimo

1 - cpu1ht1
2 - cpu2ht1
3 - cpu1ht2
4 - cpu2ht2

sarebbe risolto il problema. Quel che voglio dire, é che a livello di controller (immagino, sono digiuno di molti concetti) della cpu venga assegnato quell' ordine, che poi viene utilizzato dallo scheduler per smistare i thread.

Secondo me in questo modo il problema nn può essere risolto, come ho scritto nel post precedente! Quando si danno in pasto ad un p4 con ht attivato 2 thread, questi nn vengono eseguiti in realtà contemporaneamente, bensì tramite tecniche di register renaming si passa dall'esecuzione di uno a quella dell'altro ogni qual volta vi sia da attendere un qualche tipo di fault da una memoria o altri conflitti. Quindi se vengono assegnati due grossi thread di calcolo al un singolo core le prestazioni saranno scarse in confronto all'esecuzione su core diversi... questo indipendentemente dall'"ordine" delle cpu dentro lo scheduler, semplicemente egli nn sa cosa il thread debba eseguire (come è giusto che sia, altrimenti si porterebbe l'ht a livello di codice cosa non bella)

Originariamente inviato da Superboy
questo indipendentemente dall'"ordine" delle cpu dentro lo scheduler, semplicemente egli nn sa cosa il thread debba eseguire (come è giusto che sia, altrimenti si porterebbe l'ht a livello di codice cosa non bella)
E' chiaro questo...ma già assegnare le CPU in ordine diverso potrebbe aiutare... Comunque l'HT a livello di codice già esiste...vedi le SSE3...

Secondo me è inutile assegnare le cpu in ordine diverso
per i motivi scritti prima: non c'è determinismo nell'assegnamento di un thread ad una unità di esecuzione più performante o meno!
Nelle SSE3 ci sono 2 istruzioni per la gestione dei thread Monitor e MWAIT: servono solo per ottimizzare consumi e prestazioni nei casi in cui un thread si deve sospendere in attesa di un qualsiasi evento (es spin-wait) non sono indispensabili :)

ora non ho modo di controllare i reply e di informarmi perchè starò offline per alcuni giorni.
comunque ringrazio coloro che mi hanno (forse) risposto ;)
ci si sente prossimamente e statemi bene :)

Qualche errore macroscopico:
La prima cpu pipelined x86 è stata il 386 (pipe di 4 stage).
Il concetto di cpu superscalare invece è tutt'altra cosa: esistono all'interno dello stesso core più path di esecuzione delle istruzioni, quindi più pipeline lavorano affiancate. La prima cpu x86 superscalare è stata il Pentium, con un parallelismo pari a due (anche se il secondo path nn è in grado di eseguire il set completo di istruzioni)

non vorrei sbagliarmi ma quindi il P4 con 4 cpu logiche non potra essere sfruttato a pieno con widnows xp perche è stato progettato solo per 2 cpu al massimo?
se è cosi non rispondo.
e sull' uso di queste cpu su linux si sa qualcosa?

Originariamente inviato da 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 ;)
Nei sei sicuro? Per quale ragione il mio Windows XP Sp2 gestirebbe fino 31 CPU?
La prova?
Tasto destro sulla barra applicazioni - Task Manager - Processi - Scegliere una qualunque riga - Tasto destro - Imposta affinità...
Quanti processori vedi? Io 31, di cui solo due selezionabili (possiedo un P4 2800 HT).

Originariamente inviato da Superboy
La prima cpu pipelined x86 è stata il 386 (pipe di 4 stage).
Hai ragione, ho fatto un po' di confusione. Resta il fatto che il Pentium è il primo processore superscalare x86.

Originariamente inviato da midian
non vorrei sbagliarmi ma quindi il P4 con 4 cpu logiche non potra essere sfruttato a pieno con widnows xp perche è stato progettato solo per 2 cpu al massimo?
se è cosi non rispondo.
e sull' uso di queste cpu su linux si sa qualcosa?
Non è questo il motivo... Anzi, la spiegazione sta proprio nella tecnologia Hyper Threading... Due core logici appartenenti allo stesso core fisico se impegnati con un thread molto pesante ciascuno hanno prestazioni nettamente peggiori degli stessi due thread inseriti ogni timeslice all'interno di un unico core fisico (come succede adesso con un processore single core)... Infatti è successo in passato di avere benchmark in cui l'attivazione di HT portasse ad un deterioramento delle prestazioni (% intorno al 3-5%, ma pur sempre rilevante)...

L'utilizzo che se ne fa nei server è solitamente con thread relativamente leggeri, vedi server web o server database in cui fanno da collo di bottiglia il disco fisso e la ram...

L'unica possibilità sarebbe di tentare uno scheduling in base alla percentuale di occupazione storica dell'intera CPU... Quindi non solo si dovrebbe tenere conto di quali core appartengono alla stessa CPU, ma anche tenersi una statistica, forse un po' troppo complessa per lo scheduler... In caso un CPU, ad esempio, risulti occupata oltre il 90% negli ultimi 300ms allora verrà allocato un solo thread in un solo core logico...

Originariamente inviato da Superboy
Nelle SSE3 ci sono 2 istruzioni per la gestione dei thread Monitor e MWAIT: servono solo per ottimizzare consumi e prestazioni nei casi in cui un thread si deve sospendere in attesa di un qualsiasi evento (es spin-wait) non sono indispensabili :)
Sì, ma non solo, si può anche utilizzare per sincronizzare i thread in una CPU con HT... Ad esempio supponendo di avere una sola CPU con 2 core logici, impostando la schedulazione di ogni thread su una determinata CPU (il che si può fare) si potrebbero mettere all'interno di regioni critiche le parti di codice che generano un grande carico sulla CPU...in questo modo di fatto si riesce a controllare che due parti pesanti di codice non vadano in esecuzione contemporaneamente...

purtroppo temevo che non si trattasse solo di un accelerazione hw allo spinloc ma venisse abusato in questo modo. Ma se così fosse, se si utilizzasse un meccanismo di lock quando concettualmente nn c'è una regione critica ma solo un "lavoro pesante" sarebbe una vera e propria porcata! Gli unici benefici di un codice si fatto sarebbero quelli di nn strozzare una cpu single core con ht, penalizzando tutto il resto del mondo! e se mi permetti questo fa proprio orrore !!!

Originariamente inviato da MaxArt
Hai ragione, ho fatto un po' di confusione. Resta il fatto che il Pentium è il primo processore superscalare x86.

Originariamente inviato da MaxArt
La pipeline multistadio fu dapprima implementata nei primi Pentium (1993) e questo segnò l'inizio dell'architettura superscalare per i processori x86.

Si certo, e nel post da cui mi hai quotato ho spiegato anche il perchè...
Cmq il concetto di pipeline è totalmente indipendente da quello di cpu superscalare, quindi nn segna l'inizio di nulla :P

Non credo che sia un bug del kernel di Windows (come di qualunque altro s.o.): il problema è intrinsecamente dovuto all'HT e al fatto che le due CPU logiche non hanno le stesse risorse. Questo è stato detto e mi sembra ovvio.

La soluzione potrebbe essere quella di permettere agli applicativi SMP di scegliere liberamente quanti e quali CPU utilizzare.

Lasciare sullo scheduler quest'onere (selezionando, ad esempio, prima le cpu pari e poi quelle dispari) può sembrare una buona soluzione, ma sicuramente non risolve il problema in generale.
Ad esempio, per alcune applicazioni può essere meglio far eseguire due thread all'interno della CPU fisica anziché su due CPU fisiche diverse, perché condividono buona parte delle risorse.

x MaxArt: fino a una ventina d'anni fa buona parte dei processori aveva un registro in cui veniva caricata l'istruzione da eseguire, o i primi byte... ;)

Originariamente inviato da Superboy
e se mi permetti questo fa proprio orrore !!!
Certo, ma volendo si può prevedere qualsiasi caso...sia questo che altri con altri quantitativi di core fisici e logici...

Originariamente inviato da cdimauro
x MaxArt: fino a una ventina d'anni fa buona parte dei processori aveva un registro in cui veniva caricata l'istruzione da eseguire, o i primi byte... ;) Io ho giusto detto che non si tratta di uno dei registri GP che si diceva (e neppure i registri puntatori, o FLAGS).
Mi potresti approfondire questo punto?

Diciamo che era simile ad una pipeline a due stadi...mentre si eseguiva l'istruzione corrente si caricava quella successiva in un registro e se ne faceva la fase di fetch... La così detta prefetch...

Originariamente inviato da MaxArt
Io ho giusto detto che non si tratta di uno dei registri GP che si diceva (e neppure i registri puntatori, o FLAGS).
Infatti non lo sono.
Mi potresti approfondire questo punto?
Alcuni vecchi processori avevano un registro in cui veniva caricata l'istruzione da venir eseguita, per poi essere decodificata ed eseguita. Si trattava più che altro di una "comodità", per semplificare l'implementazione e ridurre il microcodice.
Se non ricordo male lo Z-80 aveva un registro come questo.

Poi, come diceva cionci, esistevano anche dei buffer (quindi non proprio dei registri) che veniva usati per memorizzare un certo numero di byte relativi all'istruzione corrente, ed eventualmente a quelle seguenti, per implementare una prima (rozza, ma funzionale) forma di pipelining.