di  -  giovedì 23 luglio 2009

Idle CPUSpesso in serata, dopo la classica giornata di lavoro, mi piace dedicare parte del mio tempo a chattare con amici che condividono con me la passione per l’informatica e la sua evoluzione tecnologica e nel corso di una delle più recenti chattate con il caro amico Gabriele (alias ATi7500) è emerso un argomento che reputo molto interessante. Il mio breve intervento di oggi, quindi, ha lo scopo di stimolare una riflessione sul fenomeno che vede il confine tra elaborazione hardware e software assottigliarsi. Innanzitutto direi che è il caso di definire cosa si intende per elaborazione hardware e software.

Quando uscirono le prime schede dedicate alla grafica tridimensionale in ambito consumer, parliamo dei primi anni 90, si iniziò ad utilizzare diffusamente la frase “grafica accelerata in hardware”. Ma cosa significavano esattamente queste tre parole?

Essenzialmente si parla di accelerazione in hardware quando si demanda ad un hardware specifico un’elaborazione che, altrimenti, avrebbe dovuto compiere il processore. Restando sempre nell’ambito della grafica tridimensionale, inizialmente i primi motori grafici 3D visualizzavano modelli a tre dimensioni facendo eseguire tutti i calcoli geometrici direttamente alla CPU di sistema.

Questo è possibile perché le CPU dei personal computer hanno un instruction set, cioè un set di istruzioni, ed un’architettura general purpose, in grado di eseguire un esteso numero di operazioni. La generalità delle CPU e la loro flessibilità consentono ad un programmatore software di scrivere tutte le istruzioni richieste per i fini più disparati, compresa l’elaborazione della grafica tridimensionale.

Al contrario un’operazione si definisce accelerata in hardware quando la sua elaborazione non è stata eseguita dalla CPU, ma da un hardware specificatamente sviluppato e progettato per assolvere ad un compito. Questo, tuttavia, non deve far intendere che nel caso dell’elaborazione in hardware chi sviluppa il software abbia meno lavoro da compiere.

In realtà dipendentemente dai casi, accade in maniera più o meno marcata che da un lato determinate funzionalità sono demandate all’hardware attraverso delle specifiche API di programmazione, mentre dall’altro deve essere fatta una programmazione specifica con quell’API, meno generale e, conseguentemente, più limitata.

L’evoluzione dell’informatica e, in particolare, delle sue applicazioni a vocazione multimediale (elaborazione della grafica tridimensionale, decodifica video, fisica, audio, ecc…) ha subito nel corso della sua evoluzione un percorso di generalizzazione da parte dei processori grafici e, seppur in maniera più lieve, di specializzazione da parte dei microprocessori.

Nel primo caso, infatti, le GPU a partire dall’introduzione dei vertex e pixel shader con le DirectX 8, hanno smesso di essere pezzi di silicio che eseguono solo poche e ben delineate operazioni, per diventare chip programmabili. Nel secondo caso, invece, fin dall’introduzione delle istruzioni multimediali MMX, proseguendo con i successivi set di istruzioni SIMD (Single Instruction Multiple Data), si è tentato di migliorare le prestazioni dei processori nei calcoli vettoriali, proprio quelli più comunemente eseguiti dai processori grafici.

Le strade intraprese sembrano essere destinate ad un incrocio se osserviamo attentamente diversi fattori. La programmabilità dei processori grafici è divenuta tale che ATI ed NVIDIA rispettivamente con le tecnologie Stream e CUDA, propongono modelli di programmazioni atti a sfruttare le GPU anche per compiti diversi dal calcolo della grafica tridimensionale.

I primi frutti in questa direzione si stanno già raccogliendo con applicazioni in vari ambiti (ricerca scientifica, transcodifica video, montaggio video, ritocco fotografico, ecc…) che già sono accelerate in hardware. Sempre a tal proposito la finalizzazione nel mese di Dicembre dello scorso anno di OpenCL 1.0, un’API per lo sviluppo di applicazioni orientate all’elaborazione, non potrà che favorire ulteriormente questo trend.

E per quanto riguarda le CPU? Intel non è rimasta di certo che le mani in mano e con il suo progetto Larrabee, basato su molteplici core simil-Pentium in parallelo, intende sfruttare l’attuale diffusione della programmazione su instruction set x86 per presentare un prodotto che, in teoria, sarà utilizzabile dalle applicazioni senza variare il modello di sviluppo software, a tutto vantaggio della rapidità di adozione.

A questo punto vi lancio un quesito: a fronte della strada tracciata da AMD, NVIDIA ed Intel, per quanto tempo ancora avrà senso distinguere l’elaborazione hardware da quella software?

8 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    filippo1974
     scrive: 

    Riporto qui un commento che avevo già lasciato in un altro vostro articolo, e nel quale dicevo che secondo me il confine tra HW e SW ha già iniziato a svanire.

    Da più parti ho letto che il crescente arricchimento delle GPU in direzione General Purpose ha fatto venire in mente a più di qualcuno l’idea di tornare ai motori grafici totalmente in “software” (uso volutamente le virgolette perché si tratterebbe di software distribuito, eseguito in CPU e in una -o più- GPU). Questo consentirebbe di svincolarsi totalmente dai modelli di pipeline proposti da OpenGL e DirectX, dando agli sviluppatori totale libertà di implementazione e quindi aprendo la strada, perlomeno in teoria, ad innovazioni tipo il Ray Tracing nei motori 3D dei giochi (possibilità al momento più accademica che altro, c’è un interessante articolo su Tom’s Hardware a questo proposito).

    Con le CPU da un lato che hanno crescenti capacità di stream processing (vedi le istruzioni SIMD in numero sempre crescente, dalle MMX alle SSE alle SSE2, SSE3, SSSE3 ecc.ecc.) e le GPU dall’altro che si trovano sempre più a loro agio anche in contesti General Purpose, il classico paradigma della CPU circondata da una moltitudine di ASIC sta lasciando il posto ad un più generico “cluster di processori”, alcuni dei quali più a loro agio degli altri in determinate tipologie di processamento ma tutti potenzialmente in grado di fare tutto.

    Ciao
    Filippo

  • # 2
    Giovanni
     scrive: 

    Interessante l’incrocio previsto tra cpu e gpu, avrei cmq da segnalare una svista un po’ grave… accelerazione, la doppia l è erroraccio di quelli proprio tipici :)
    Un saluto

  • # 3
    pabloski
     scrive: 

    e che dire allora della crescente diffusione degli fpga?

  • # 4
    pleg
     scrive: 

    Secondo me l’espressione “elaborazione hardware e software” e’ fuorviante (anche se la spiegazione data e’ chiara): e’ il confine tra CPU e GPU si sta assottigliando, cioe’ il confine tra diverse componenti hardware.

  • # 5
    pleg
     scrive: 

    @pabloski

    In che ambito? Non consumer, non dentro un desktop.

    Cmq, se interessa (se non la conosci gia’) dai un’occhiata alla Maxeler (azienda con base a Londra): per applicazione scientifiche/ingegneristiche intense (il loro cavallo di battaglia e’ l’elaborazione dati per le prospezioni geologiche per le compagnie petrolifere) propongono un sistema con migliaia di FPGA in cui la topologia dell’hardware e il software sono sviluppati contemporaneamente, specifici per ogni applicazione! Per certi ambiti, l’idea e’ molto interessante.

  • # 6
    Cesare Di Mauro
     scrive: 

    Per me la cosa più importante è la “computazione”. Che poi sia eseguita da una circuiteria fissa / dedicata, oppure da una più “generica” dipende dal contesto del problema da risolvere e dalla convenienza.

  • # 7
    floc
     scrive: 

    beh normalmente si definiva accelerazione hw quella effettuata tramite api specifiche, quella sw invece era tale se effettuata con api legacy compatibili con qualsiasi hw. A mio avviso e’ ancora viva questa distinzione, semplicemente essendo le api dedicate ad hw specifico molto piu’ utilizzate stiamo andando verso una accelerazione hw generalizzata… Tutto sta nello scegliere dove mettere il paletto per distinguere tra il “generalizzato” e lo “specifico :)

  • # 8
    j
     scrive: 

    beh normalmente si definiva accelerazione hw quella effettuata tramite api specifiche, quella sw invece era tale se effettuata con api legacy compatibili con qualsiasi hw.

    veramente, si parla di accelerazione (grafica) già molto prima delle schede acceleratrici voodooo e le altre
    all’ inizio degli anni 90, vennero introdotte nel mercato mainstream delle vga dotate di supporto hw per il riempimento, il blitting e il tracciamento di linee, e di sw che lo sfruttava sostituendosi alle librerie originali (in pratica, driver) principalmente per rendere più efficienti le GDI di windows 3.1

    peraltro, oggi sappiamo che una api è solo un’ interfaccia programmatica dietro a cui si possono trovare implementazioni hw o sw based o combinate, ma all’ epoca l’ idea che una api facesse nascere un nuovo mercato, quello delle periferiche attea ad accelerarla, fece storcere il naso a molti, perchè appariva come una conferma della “scarsezza” intrinseca di una API per di più proprietaria…

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.