View Single Post
Old 27-04-2008, 13:31   #1
gugoXX
Senior Member
 
L'Avatar di gugoXX
 
Iscritto dal: May 2004
Cittā: Londra (Torino)
Messaggi: 3692
[C#] - Prove di parallelismo

Un pelino di storia, giusto per inquadrare i ragionamenti che recentemente si stanno sentendo nel nostro ambiente.
A chi non piace la storia puo' saltare l'intro...

Praticamente tutti, anche i non addetti ai lavori, conoscono la famosa legge di Moore, legge empirica secondo la quale le prestazioni dei microprocessori vengono raddoppiate ogni 18 mesi.
Il trend non si e' ancora fermato, ha dato un solo accenno alla diminuzione recentemente.
Ma mentre una volta per aumentare le prestazioni di un microprocessore era sufficiente riuscire a trovare una sorgente piu' pura di silicio, ed alzare la frequenza del clock, oggi si e' raggiunto quello che e' il limite commerciale ragionevole dei transistor al silicio, che non sembra essere piu' conveniente sopra i 4GHz. Sono gia' parecchi anni infatti che nuotiamo attorno a queste frequenze.
Aumentare semplicemente la frequenza di clock ha l'indubbio vantaggio che tutto il sistema si muove in modo quasi direttamente proporzionale, senza alcun bisogno di cambiare essenzialmente i programmi.

Le prestazioni sono pero' continuate ad aumentare, anche grazie alla semplificazione degli algoritmi hardware, piu' stadi di pipeline e miglior controllo di mutua dipendenza delle singole istruzioni macchina, con la possibilita' di eseguire piu' istruzioni per colpo di clock.
Questi accorgimenti, cresciuti e migliorati con il tempo (il prefetch p.es. c'era gia' sull 8086), non richiedono una riscrittura del software. A parte alcuni minimi accorgimenti, solitamente risolti a livello di compilatore, per lo svincolo delle dipendenze delle istruzioni macchina, i sofware scritti beneficiano in modo automatico ogni volta che un nuovo processore riesce a migliorare questi espedienti.
Anche qui pero' siamo giunti a limiti molto spinti. E' improbabile che all'interno di un core si riesca a beneficiare dell'aggiunta di nuove pipeline. Il pentium 1 e' stato il primo ad introdurre 2 pipline. Il pentium 3 ha introdotto 3 pipeline. Sono state introdotte pipeline indipendenti per il coprocessore matematico e per le istruzioni MMX e simili. Contando pero' che la maggior parte delle operazioni macchina sono svolte tra i normali registri (interi), e che e' difficile trovare sequenze di 4 microistruzioni assolutamente indipendenti, ne consegue che difficilmente si supereranno 4 pipeline per per le istruzioni che coinvolgono la computazione tra interi.

Piu' recentemente e' iniziata la migrazione di piu' core all'interno di ogni microprocessore. Commercialmente si e' a 4, ma le roadmap parlano chiaro. Il futuro per restare nella legge di Moore e' li'. Aggregare piu' core all'interno del singolo microprocessore. Si parla gia' di 20 core, e alcune prove/studi sono state fatte dalla Intel con piu' di 1000 core.
Qui pero' abbiamo un problema. I programmi che sono stati scritti senza accortezze particolari, non potranno beneficiare dell'introduzione di nuovi core. Un minimo di vantaggio ci sara' comunque. Il core dedicato per il singolo processo utente potra' agire indisturbato, senza time-sharing con gli altri processi in esecuzione (Sistema operativo, etc.). Ma e' un effetto minore.
Occorre scrivere sofware che possano muoversi e beneficiare direttamente della presenza di nuovi core.

Scrivere sofware multiprocesso e' una normalmente una pena.
Meglio, adattare un algoritmo tipicamente sequenziale, scritto in un linguaggio imperativo, in modo da sfruttare i core presenti e' difficile e scomodo.
Il piu' delle volte ne risulta un codice "spaghetti" che poco ha a che fare con l'algoritmo stesso. Il tutto e' quasi sempre illeggibile e poco manutenibile.
Sono uscite parecchie librerie atte ad aiutare la programmazione parallela, alcune semplici, alcune complesse.
Facendo tesoro dell'idea secondo la quale il paradigma di programmazione naturale per la programmazione parallela e' quello funzionale, ultimamente si stanno vedendo parecchi sforzi concentrati in questa direzione.
Consiglio mio e' quello di iniziare a studiare, per chi ancora non l'avesse fatto, la programmazione funzionale, per non trovarsi tagliati fuori dal mercato.
Nelle ultime 4 settimane gli annunci relativi alla programmazione funzionale qui a Londra sono aumentati tantissimo.

Io personalmente la programmazione funzionale non l'avevo mai affrontata prima di ottobre 2007. Mi ci sono avvicinato gradualmente. La settimana scorsa ho provato a fare il salto verso la funzionale parallela, e devo dire che sono rimasto stupefatto della semplicita'.
Per chi conosce concetti come Thread, BackgroundWorker, semafori, segnali, Mutex, etc. e tutto quanto serve di contorno per la gestione di una programmazione parallela con linguaggi imperativi non potra' che apprezzare la semplicita'.
__________________
Se pensi che il tuo codice sia troppo complesso da capire senza commenti, e' segno che molto probabilmente il tuo codice e' semplicemente mal scritto.
E se pensi di avere bisogno di un nuovo commento, significa che ti manca almeno un test.
gugoXX č offline   Rispondi citando il messaggio o parte di esso