Grand Central Dispatch

Fino a non molti anni fa il percorso evoluzionistico dei processori è stato relativamente semplice ed indirizzato all’incremento delle prestazioni delle nuove generazioni di CPU semplicemente innalzandone la frequenza operativa. Un approccio lineare e conveniente: sintetizzando banalmente, i programmi sono infatti un insieme sequenziale di operazioni e, pertanto, maggiore è la frequenza operativa, maggiore è la velocità di esecuzione di un’operazione, minore è il tempo di esecuzione di un intero processo.

Lineare e conveniente fino a quando i materiali impiegati per la realizzazione delle CPU non hanno iniziato a mostrare i propri limiti fisici: innalzando via via le frequenze operative si spostavano di pari passo, verso l’alto, le temperature d’esercizio ed il consumo energetico, due elementi cruciali da dover tenere sotto controllo, in special modo in ambito mobile.

A fronte di questi ostacoli, è mutato l’approccio allo sviluppo delle CPU: non più un incremento prestazionale seguendo la “forza bruta”, ma ispirandosi al “collaborazionismo”, ovvero inserendo in un singolo microprocessore più core di elaborazione e potendo ottenere più potenza computazionale senza dover ricorrere all’incremento della frequenza operativa.

Quali sono le conseguenze di questo approccio? In primis una migliore efficienza ed una minore dissipazione termica. Sull’altro piatto della bilancia, però, vi è una importante differenza rispetto al mero incremento della frequenza operativa: con l’implementazione di più core, infatti, un programma scritto per una CPU single core non è in grado di trarre benefici diretti.

Per poter sfruttare la presenza di più core di elaborazione, gli applicativi necessitano infatti di essere riscritti: in altri termini per sfruttare al meglio un processore multi-core è necessario che il codice di programmazione sia altamente parallelizzato e che preveda, cioè, la possibilità che determinate sue parti possano essere eseguite contemporaneamente da più core differenti. La programmazione parallela, tuttavia, risulta essere particolarmente gravosa per gli sviluppatori. Oltre alla semplice suddivisione dei vari processi (task) in più parti (thread) eseguibili simultaneamente, lo sviluppatore dovrà assicurarsi, mediante tecniche opportune, di isolare i dati che potrebbero essere modificati da più thread simultaneamente ed implementare un sistema di gestione dei thread che mandi in esecuzione solamente un numero di thread pari al numero di core disponibili. Si evince, pertanto, che il complesso problema di gestione dei thread sia completamente sulle spalle del programmatore in primis e dell’applicativo in ultima analisi. Vi è però una variabile che non può in alcun modo essere controllata ne’ dallo sviluppatore, ne’ dal programma: se, infatti, sul sistema operativo è in esecuzione un’altra applicazione che sta impegnando i core della CPU, tutti gli sforzi di programmazione risulterebbero comunque vani, in quanto le risorse non potrebbero essere gestite in maniera ottimale.

Per venire incontro a questo genere di esigenze, porre una soluzione al problema e, in ultima analisi, consentire l’ottimale sfruttamento delle capacità computazionali dei processori multicore, Apple ha pensato di introdurre un sistema che consentisse di trasferire tutta la complessa gestione dei thread e la loro esecuzione dal livello dell’applicativo al livello del sistema operativo, Grand Central Dispatch, appunto.

Con Grand Central Dispatch (che abbrevieremo con GCD) gli sviluppatori hanno così modo di concentrarsi meglio sulla parallelizzazione del codice di programmazione, senza doversi occupare di come i thread verranno gestiti. Tutto ciò che gli sviluppatori devono fare è definire le differenti parti di lavoro (blocchi, blocks) che devono essere svolte dall’applicazione e definire un modo semplice che regoli l’interazione di queste parti tra loro (code, queues).

GCD si occuperà di analizzare le varie code, in modo tale da stabilire l’ordine con il quale i thread devono essere eseguiti e si occuperà di mandare in esecuzione un numero di thread pari al numero di core attualmente disponibili per la computazione. Tutta la gestione di thread e dati che nell’approccio tradizionale è a carico dell’applicazione, con GCD viene presa in carico dal sistema operativo, il quale si occuperà di armonizzare l’impiego delle risorse necessare all’esecuzione dell’applicativo con quelle necessarie per il funzionamento degli altri processi del sistema. Inoltre, dal momento che è il sistema operativo a decidere l’esecuzione dei thread sulla base delle risorse disponibili, anche su processori single-core il codice sarà eseguito sempre nella maniera più efficiente possibile.

GCD, segue

Le caratteristiche peculiari di GCD danno modo a programmatori e i sviluppatori di definire piccoli frammenti di lavoro che possono essere isolati e scorporati dal thread principale di un’applicazione, rendendola in questo modo più reattiva agli input dell’utente. Le applicazioni GCD-based permettono di ottenere una maggiore efficienza complessiva del sistema, grazie ad un codice complessivamente più contenuto, all’impiego di minor CPU time e memoria rispetto ai meccanismi tradizionali. La programmazione basata su GCD consente di realizzare applicativi in grado di scalare in maniera dinamica a seconda dell’hardware sul quale vengono eseguiti. Di norma, quando uno sviluppatore si trova nelle condizioni di dover lavorare all’ottimizzazione di un programma multithread, incorre nella necessità di conoscere i dettagli dell’hardware sul quale opera la specifica applicazione e, affinché l’ottimizzazione sia davvero tale, è inoltre necessario che nessun altro programma sia in esecuzione. Se tale scenario può essere anche abbastanza comune negli ambiti di supercomputing, ciò non avviene in contesto desktop, dove spesso più applicativi, di varia natura, sono contemporaneamente in esecuzione. GCD, ricoprendo il ruolo di “supervisore” delle attività, riesce ad ovviare a questo problema: il programmatore è infatti messo nelle condizioni di strutturare il codice di un applicativo in una maniera che permetta di identificare tutte le opportunità di parallelizzazione disponibile e lasciando che sia il sistema operativo, grazie a GCD, a decidere l’adeguato grado di parallelismo con il quale eseguire un’applicazione, sulla base della piattaforma hardware esistente e sulla base della richiesta computazionale delle altre applicazioni in esecuzione. Questo meccanismo consente pertanto alle applicazioni e al sistema operativo di scalare in maniera efficente da uno a molti processori senza che sia necessaria una regolazione manuale delle applicazioni. Grand Central Dispatch è in grado di apportare i benefici descritti sopra e al contempo permette di ridurre la complessità del codice che è necessario scrivere. Molti sviluppatori hanno constatato che l’adozione di GCD permette di migliorare in maniera sensibile la leggibilità del codice e, conseguentemente, la sua manutenzione e la correttezza del codice, precedentemente portato avanti con le tradizionali tecniche di programmazione multithreaded. Strumenti di sviluppo GCD Affinché gli sviluppatori possano sfruttare al meglio le caratteristiche di Grand Centra Dispatch, Apple mette a disposizione, direttamente all’interno del DVD di installazione di Snow Leopard, una serie di strumenti atti allo scopo come parte dell’ambiente di sviluppo Xcode. Nello specifico è possibile disporre di una serie di strumenti di analisi che consentono di verificare l’efficienza di codice scritto per GCD grazie ad un monitoraggio in tempo reale relativo all’uso di blocchi e code mentre l’applicazione è mandata in esecuzione. Più nel dettaglio, gli strumenti di analisi forniti all’interno di Xcode permettono di tenere traccia del numero di volte che un blocco è stato eseguito, della durata di esecuzione di una particolare istanza di blocco e la latenza di una determinata coda. OpenCL La seconda, importante, novità tecnologica implementata in Mac OS X 10.6 “Snow Leopard” è il supporto allo standard OpenCL, che consente di mettere a disposizione del sistema operativo e degli applicativi la potenza computazionale delle moderne GPU per calcoli ed impieghi che esulano dalla normale computazione grafica. Di Open CL abbiamo avuto modo di parlare più volte sulle pagine di Hardware Upgrade. Si tratta di uno standard aperto che comprende un linguaggio di programmazione, le relative API, e tutti gli elementi runtime necessari a supporto della programmazione. La base di partenza del linguaggio di programmazione dello standard OpenCL è lo standard C99, nato nel 1999 da una revisione e da una serie di operazioni di aggiornamento al fine di mantenere il linguaggio C di pari passo con l’evoluzione hardware. La qualità di immagine, il realismo grafico, le elevate risoluzioni sono possibili grazie alla capacità delle moderne GPU di calcolare parecchi milioni di pixel al secondo, ciascuno dei quali è, nei fatti, il risultato di una serie di operazioni matematiche più o meno complesse. Pertanto, da un punto di vista strettamente computazionale, le GPU sono in grado di effettuare operazioni al livello di supercomputer. Non solo: le GPU attuali sono in grado di processare più pixel simultaneamente poiché, a livello architetturale, sono processori altamente parallelizzati. E’ sulla base di queste considerazioni che nasce l’idea di impiegare i processori grafici come processori general-purpose. Ma come si è passati da una GPU esclusivamente dedicata al calcolo grafico ad una GPU capace di affrontare anche operazioni generiche? Il merito, forse inconsapevole, di questa evoluzione va all’introduzione dei graphic shader, ovvero una serie di istruzioni basilari che permettessero di riprogrammare gli elementi atti alla processazione dei pixel all’interno della GPU, più comunemente denominati pipeline. I graphic shader sono infatti nati per ovviare ad una limitazione delle precedenti generazioni di GPU, caratterizzate da pipeline non programmabili e, pertanto, in grado di computare solo attingendo a questo set fisso di istruzioni disponibili a livello hardware. Con il passare del tempo i graphic shader si sono via via evoluti, passando dall’essere semplici programmi scritti in linguaggio assembly, a programmi di più alto livello e di maggior complessità. Proprio per gestire la sempre più crescente complessità degli shader grafici, i progettisti di GPU hanno ritenuto indispensabile modificare l’architettura delle GPU, permettendo alle pipeline di supportare operazioni matematiche e logiche più generiche. AMD e NVIDIA, consci delle potenzialità delle nuove architetture grafiche, hanno iniziato a sviluppare una serie di linguaggi di programmazione proprietari in grado di semplificare l’approccio alla programmazione GPGPU (General Purpose GPU). Apple, di contro, ha intuito che uno standard aperto potesse meglio portare sul mercato le funzionalità delle nuove schede video e collaborando con Intel e le stesse AMD e NVIDIA ha sviluppato uno standard da proporre a Khronos Group. Nel giro pochi mesi OpenCL è divenuto ufficialmente uno standard aperto e, come tale, libero da canoni di concessione e multipiattaforma destinato in modo particolare alla programmazione parallela delle GPU di ultima e futura generazione. Quali sono, in ultima analisi, le ricadute pratiche del supporto ad una tecnologia GPGPU? Con la possibilità di eseguire un consistente volume di calcoli in parallelo, lo sfruttamento delle tecniche di programmazione messe a disposizione da OpenCL consente di incrementare significativamente la velocità e la risposta di una vasta gamma di applicazioni, a partire dai giochi sino a software di calcolo e analisi scientifica, passando per applicativi di stampo entertainment. Tra i campi di applicazione si possono citare gli applicativi per il riconoscimento del volto in realtime, soluzioni per la riduzione del rumore video, e la codifica/decodifica accelerata di materiale multimediale. E’ molto interessante notare come Apple abbia deciso di propendere per uno standard aperto quale Open CL per quanto riguarda la possibilità di fruire delle potenzialità del GPGPU: i sistemi Mac sono infatti equipaggiati con soluzioni grafiche di NVIDIA, che ha sviluppato il proprio standard di programmazione CUDA. Ancora una volta è evidente come Apple, pur appoggiandosi ad altre grandi realtà del settore, preferisca evitare di legarsi a doppio filo a qualsiasi di queste, perseguendo la proverbiale politica delle “mani libere”.