Newsgroup: it.comp.programmare.win32
Titolo: Programmi per multicore

Salve,
volevo chiedervi una cosa: affinché un software sfrutti tutti i core della 
cpu, è sufficiente dotarsi di un compilatore che genera codice macchina a 
tale scopo o serve qualcos'altro?
Ad esempio, un semplice programma che esegue n cicli for, scritto con una 
vecchia versione di C++ Builder 3, sfrutterà solo uno dei core.
E' sufficiente ricompilare il programma con una versione più recente per far 
si che tutti i core vengano sfruttati?
Saluti 

 tale scopo o serve qualcos'altro?
Credo che le CPU multicore siano considerabili a tutti gli effetti come
sistemi SMP, e che quindi valgano le stesse considerazioni tipiche di
questi ultimi (l'OS deve supportare SMP e il codice deve suddividere i
calcoli su piů thread). Non credo che il compilatore c'entri piů di tanto.
-- 
emboliaschizoide.splinder.com

 tale scopo o serve qualcos'altro?
Purtroppo no, è lo sviluppatore che deve scrivere codice diverso e 
sfruttare quanto più è possibile degli altri core.
Per questo motivo MS ha creato tempo fa una nuova divisione del 
parallel computing 
(
http://msdn.microsoft.com/en-us/concurrency/default.aspx
) che si 
occupa di:
- creare librerie che astraggano le primitive del sistema operativo per 
la gestione dei thread
- creare i tool (presenti nella prossima versione di visual studio) per 
il debugging, il profiling etc.
Sul lato linguaggi:
- la commissione ISO C++ sta lavorando a C++0x (il prossimo standard) 
che fornirà nuovi strumenti nativi nel linguaggio per poter 
parallelizzare più facilmente un algoritmo. Un esempio per tutti: le 
lambda functions.
- Il team di VC++ sta implementando le normative che la commissione ha 
già approvato in via semi-definitiva.
- Il team di C# ha già introdotto le lambda e si pensa che ci sarà 
altro in futuro.
Sul lato sistema operativo:
- Windows 7 introduce il user-mode scheduler. L'UMS consente di gestire 
task paralleli in modo più efficente per evitare di subire 
penalizzazioni di performance dovute alle transizioni user-mode / 
kernel-mode. Le penalizzazioni si verificano quando ci sono molti 
thread che lo scheduler del sistema operativo deve gestire e crescono 
in funzione del numero di core presenti nel sistema (quando si usano 
librerie che sfruttano tutti i core).
Tra le librerie che vedremo nella prossima versione del Framework e di 
VC++ (nativo) ci sono:
- Il concurrency runtime (codice nativo) che usa in Win7 lo user mode 
scheduler e sul quale si appoggiano le PPL (Parallel Pattern Library)
- Le TPL (task parallel library) che fanno parte delle parallel 
extension del 
framework.net
 (conosciuto come PFX) che serve ovviamente 
ai linguaggi managed. Tra questi ci sono le estensioni parallele a 
Linq.
Entrambe le librerie espongono classi ad alto livello come i task, i 
futures, etc. etc.
I vantaggi sono principalmente quelli di ottimizzare automaticamente il 
numero di thread sulla base del numero di core presenti a runtime; e 
l'astrazione dalle API di base che rendono complessa la gestione (per 
esempio mutex, eventi e semafori per evitare race conditions, etc. 
etc.)
Infine ci sono già dei tools come "Chess" di Microsoft Research che 
servono a fare analisi statica del codice per capire dove possono 
essere i problemi in un algoritmo parallelo.
Tutto questo amaradan per poi avere un problema di fondo: l'algoritmo 
lo devi scrivere tu e ci sono dei casi in cui rendere un algoritmo 
parallelo non è affatto banale.
Ovviamente librerie e tool sono solo che benvenute :)
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 Per questo motivo MS ha creato tempo fa una nuova divisione del parallel 
...
Mi permetto di aggiungere a tutto quello che dice Raffaele che è come 
sempre molto preciso e puntuale, che esiste anche un'altra possibilità, 
peraltro implementata già DA vs2005 e che si chiama OpenMP.
Premetto che non conosco molto bene la cosa e che non l'ho mai usata, ma 
l'idea di fondo è che con OpenMP il compilatore fa quasi tutto quasi 
gratis: il programmatore si "limita" ad esprimere attraverso alcune 
direttive quali parti del codice vuole parallelizzare.
Ad esempio questo codice dovrebbe "splittare" il for su N thread (dove N 
è definibile in vari modi ma tendenzialmente dovrebbe essere minore o 
uguale al numero di cpu/core):
#pragma omp parallel for
     for (i=1; i<n; i++)
         b[i] = (a[i] + a[i-1]) / 2.0;
Per riferimenti:
http://openmp.org/wp/
e per l'implementazione MS:
http://msdn.microsoft.com/en-us/library/tt15eb9t.aspx
Beppe

 implementata già DA vs2005 e che si chiama OpenMP.
[...]
Giustissimo ...
aggiungo solo che è uno standard e quindi cross-compiler.
http://openmp.org
Io l'ho usata e per alcune cose molto tempo fa ed è abbastanza potente. 
Per esempio c'è la possibilità di dichiarare quali sono i parametri 
dello stack che devono essere protetti con delle critical section 
'automatiche'.
Per i for è molto potente ma appena esci dai casi più eclatanti 
comincia ad essere complessa.
Le nuove librerie in arrivo sono però decisamente più confortevoli e 
hanno un runtime che permette delle finezze non da poco come il "work 
stealing" che distribuisce dinamicamente il carico sui thread man mano 
si liberano.
Inoltre facendo uso di librerie il sorgente si riesce a tenere 
decisamente più pulito e anche il debugging/profiling sarà molto più 
confortevole.
