Il nostro futuro è indubbiamente parallelo. I fabbricanti di Cpu fanno capire che c’è un gradino tecnologico davanti a noi, che rende più difficile continuare a alzare la frequenza del core e invita a cercare soluzioni nel parallelismo.Nel frattempo Nvidia ha aperto le porte del calcolo massicciamente parallelo con CUDA e Apple segue a ruota promettendo OpenCL fra i contenuti di Snow Leopard.
CUDA ha già dato segnali di vita interessanti da quando ne abbiamo parlato: abbiamo osservato almeno un prodotto che fa uso di CUDA in un settore in cui ce lo aspettavamo: l’audio professionale. Il plugin Vst Nebula 3 di Acustica Audio può usare la scheda grafica per simulare reverberi e altri processori digitali che normalmente associamo a un Dsp.
L’annuncio di Apple è interessante: OpenCL dovrebbe essere una libreria di funzioni, e prevedibilmente estensioni del compilatore, per l’orchestrazione di un calcolo parallelo fra il processore on board e il processore grafico.
La particolarità della realizzazione di Apple è che non si limiterà a supportare solo le unità grafiche Nvidia, ma realisticamente tutte quelle esistenti nella linea Apple, dalle Intel 950 dei Macbook alle Ati 2600 e Nvidia 8800 e 5600 dei Mac Pro.
Nemmeno Intel sta con le mani in mano. La sezione per gli sviluppatori del sito di Intel è ricca di informazioni e compilatori sperimentali per imparare a sfruttare il parallelismo delle Cpu multicore.
Le potenzialità di calcolo a disposizione del grande pubblico saranno quelle che solo la Nasa o il National Center for Supercomputing Applications potevano sognare qualche anno fa. Più di un centinaio di Giga Flops, secondo la manualistica Nvidia.
Ricordiamo che l’architettura della Gpu è radicalmente diversa da quella del processore principale. Le Gpu hanno poca cache e molte unità di elaborazione. In termini di area occupata sul chip il raffronto è quello che vediamo nella figura presa dal manuale di programmazione di Nvidia.
L’architettura è Simd (Single Instruction Multiple Data), cioè in parole povere in ogni istante le unità di elaborazione stanno eseguendo lo stesso programma su dati diversi, cioè in posti diversi della stessa matrice. Quello che serve per testurizzare le pareti di una stanza in un videogioco può anche servire per ricodificare un video o applicare il reverbero a un campione audio.
Due sono gli spunti per la riflessione che ci sentiamo di proporre così a caldo.
In primo luogo, i limiti fisici dell’incremento di clock non sono così lontani. Secondo Einstein un segnale non può propagarsi più velocemente della velocità della luce, che è trecentomila chilometri al secondo.
Per tradurre in metri moltiplichiamo per mille: sono trecento milioni di metri. Moltiplichiamo ancora per mille per avere i millimetri: trecento miliardi. Sembrano tanti, ma nel tempo che un orologio a un GHz, cioè un miliardo di Hz, batte un colpo, abbiamo fatto trecento millimetri, cioè la luce attraversa un foglio A4 o il cabinet di un PC durante un colpo di clock, mezzo foglio a due GHz e così via. Il limite relativistico non è lontanissimo, quindi è meglio esplorare il parallelismo oltre a puntare sull’incremento del clock.
Il secondo spunto nasce dal fatto che sfruttare il parallelismo è diverso da sfruttare un clock più veloce. Nel secondo caso non occorre fare niente, nel primo occorre saper spezzare un problema in sottoproblemi in modo tale da riuscire a tenere sempre occupate tutte le risorse di calcolo, altrimenti il nostro sistema parallelo diventa inefficiente come un ufficio in cui un singolo sequestra tutto il carico di lavoro senza riuscire a dividerlo. Questo potrebbe significare che i giorni dei programmatori stanno per tornare.
In ogni caso, il nostro prossimo universo parallelo non sarà un flop, ma parecchi gigaflop.