Dual Core e HyperThreading: un possibile bug

[MaxArt]

Ho mal di testa 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?

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!

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!

Adesso aspettiamo l'intervento di quei pazzoidi degli ingegneri (informatici od elettronici che siano )

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

[DioBrando]

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

in questo caso Ecstrim Ediscion allora

[street]

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 ?

[cionci]

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

[street]

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.

[Superboy]

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)

[cionci]

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

[Superboy]

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

[max84]

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

[Superboy]

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)

[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?

[corgiov]

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

[MaxArt]

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.

[cionci]

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

[cionci]

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

[Superboy]

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

[Superboy]

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

[cdimauro]

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

[cionci]

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

[MaxArt]

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?