Newsgroup: it.comp.programmare.win32
Titolo: Multithread su 4 core 8 thread

Qualcuno di voi che usa una CPU quad-core 8 thread ha mai scritto un 
programma con 8 o pi� thread per verificare se la velocit� di esecuzione 
rispetto al single-thread aumenta di 8 volte?
 
Grazie
Cristiano

 Grazie Cristiano
 
Sì, provato anche con molti più flussi.
 
E non è detto che con 8 thread paralleli la velocità di esecuzione sia 8 
volte tanto.
Ci sono molte variabili in gioco che possono portare variazioni drastiche 
(fino al blocco dell'applicazione) con cause sia interne che esterne al 
programma.
 
Per farla semplice, cosa fa il programma?
 
Se questo dovesse generare informazioni dal nulla e buttarle nel nulla, 8 
thread arriverebbero a generare 8 volte le informazioni generate da un 
singolo thread (è come avere 8 programmi separati).
Se questo programma deve prendere i dati da una fonte comune e buttarli 
in una destinazione comune, dovrebbero gestire l'accesso concorrente alle 
risorse condivise, il che porterebbe ad avere dei momenti in cui uno o più 
thread sono in attesa del proprio turno.
Più generalmente, se esistono risorse condivise, si applica il secondo 
caso.
Una gestione non corretta delle risorse condivise (o delle priorità di 
esecuzione) porta a situazioni di visibile degradazione o anche di 
deadlock dove due o più entità sono in mutua attesa.
 
Altro fattore fondamentale è riassumibile con una frase che viene (o 
dovrebbe) essere insegnata agli ingenieri gestionali: se una donna impiega 
9 mesi per fare un bambino, 9 donne non impiegano 1 mese per fare un 
bambino. (tipico esempio di lavoro non parallelizzabile)
Quindi non sempre l'approccio parallelo è applicabile o applicabile con 
vantaggi.
In taluni casi, un algoritmo che gira mono-thread necessita di pesanti 
modifche (finanche alla riprogettazione) per poter essere eseguito in un 
contesto parallelo.
 
E tutto questo parlando di fattori interni.
 
Come fattori esterni, ci sono diverse cose che possono mettere i bastoni 
tra le ruote.
Intanto sei su un sistema operativo che fa delle cose. Quindi se hai 8 cpu 
a disposizione, alcune possono anche essere impegnate per fare altro.
Potresti avere delle politiche di risparmio energetico che modificano la 
velocità dei processori in base a carico di lavoro e temperature, 
potresti avere dei rallentamenti dovuti a letture e scritture su disco, o 
scambio dati con la rete, e molto altro ancora.
 
Comunque il punto fondamentale è che un multithread progettato male può 
essere molto inefficente, e avere prestazioni peggiori di un single 
thread progettato bene. Ed è semplice progettare male un multithread.
Quindi conviene sempre chiederti: ma ti serve realmente?
 
PSK


 
 
Aggiungo oltre a quanto giï¿œ detto che core e thread sono cose molto 
diverse.
I core fisici possono effettivamente arrivare a moltiplicare il lavoro 
che puï¿œ essere svolto completamente su altrettanti thread.
In situazioni ideali dove non ci sono latenze di I/O, dove non ci sono 
risorse comuni che implicano dei lock (e quindi delle attese) puoi 
arrivare a vedere che 4 thread su 4 core vanno effettivamente in 
parallelo impegnando il 100% dei core.
Ovviamente ï¿œ un limite non raggiungibile perchï¿œ almeno 1 dei core dovrï¿œ 
anche svolgere un po' di lavoro per conto del sistema operativo 
(scheduler, driver, altre app, etc.).
 
I thread invece (Intel lo chiama Hyperthreading) ï¿œ il tempo recuperato 
quando le istruzioni eseguite su un core implicano lo svuotamento della 
cache, delle istruzioni che sono state giï¿œ pronte in fetch e la branch 
prediction (istruzioni che la CPU ipotizza che possano essere eseguite 
nello step successivo).
Poichï¿œ occorre del tempo per perparare tutte quelle cose, nel frattempo 
i cicli clock del core vanno persi. Quei cicli vengono usati nelle CPU 
con hyperthreading per eseguire una pipeline parallela (preparata 
mentre il core faceva altro lavoro).
Ma questo tempo di esecuzione ï¿œ ricavato quando il core non ha nulla da 
fare e quindi non ï¿œ un core supplementare ma solo una piccola 
percentuale che ï¿œ molto variabile a seconda di quanto spesso cache e 
fetch vengono invalidate. Ricordo a memoria circa 10-20% rispetto ad un 
core fisico.
 
Perciï¿œ su su una Intel i7 con 4 core e 8 thread, potrai raggiungere uno 
speed-up massimo di circa 5 volte. Sono numeri poco significativi 
perchï¿œ a seconda del tipo di algoritmo che fai girare potresti avere 
numeri estremamente differenti.
 
Ultima cosa. Se hai bisogno di forte parallelizzazione ï¿œ uscita una 
libreria chiamata "AMP" di Microsoft che permette di spalmare i task di 
esecuzione (usando la PPL, Parallel Pattern Library) su core della CPU 
e anche della GPU in modo trasparente al codice che scrivi.
 
 
-- 
Raffaele Rialdi  
http://www.iamraf.net
 
Weblog: 
http://blogs.ugidotnet.org/raffaele
 
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
 
UGIdotNET - 
http://www.ugidotnet.org/
 
 
 

 Quindi conviene sempre chiederti: ma ti serve realmente?
 
Io faccio un uso smodato del multi-threading nei programmi che scrivo. 
E' che purtroppo mi devo accontentare del misero dual-core di 6 anni fa 
(una E6400), ma nonostante questo, i programmi in cui utilizzo il 
multi-thread li scrivo sempre in modo da arrivare ad un fattore 1,99...
L'idea di vedere quadruplicate le velocità di alcuni programmi di 
calcolo (rispetto al 2x con l'attuale dual-core), mi piacerebbe molto, 
ma sembra che le cose con l'HT non stiano così.
 
Cristiano

 anche della GPU in modo trasparente al codice che scrivi.
 
Vedendo il secondo listato del link:
http://msdn.microsoft.com/en-us/library/vstudio/hh265136.aspx
 
non sembrerebbe proprio trasparente trasparente. :-)
E' un codice molto simile a quello che si scrive usando CUDA.
 
Cristiano


 
Il vantaggio ï¿œ a reverse. Il codice che prepari per girare su GPU, cosï¿œ 
com'ï¿œ puoi girare su multicore nel caso la GPU sia satura o non 
presente.
Se ci pensi ha senso perchï¿œ la GPU ha requisiti piï¿œ restrittivi 
rispetto alla CPU sul tipo di codice che puï¿œ eseguire e questo 
giustifica quel piccolo set di keyword aggiuntive / proprietarie di 
VC++.
