Dual Core e HyperThreading: un possibile bug

x MaxArt

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.

Re: x MaxArt

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

Re: Re: x MaxArt

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

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?

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

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

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

www.arstechnica.com

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

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

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.

E che altro?

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!

Nei registri non viene caricata alcuna istruzione. O almeno, non in quelli che dicevamo prima!

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.

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!

Certamente c'è chi saprà far di meglio, io sono solo un matematico!
Col mal di testa!