Dietro le quinte con AMD, continua
TH: Quanto entusiasmo hai trovato nella comunità degli sviluppatori? Sono venuti da voi dicendovi "Aiutateci con l'OpenCL"?
AL: Francamente usare qualcosa come OpenCL non è semplice, ma ho provato a infrangere la barriera psicologica. Le persone iniziano a usare OpenCL e spesso non ottengono le prestazioni sperate (poiché non è semplice) e così pensano che non funzioni. Pensano sia solamente una sparata di marketing e non lo usano.
Il mio obiettivo è abbattere le barriere e mostrare che ci sono molti benefici. Il modo in cui farlo è un'altra questione. Il problema è che non è esattamente C, anche se non è molto differente; è una questione di mentalità. Bisogna capire che si ha a che fare con problemi altamente paralleli. Sostanzialmente il problema è far comprendere alle persone come far lavorare 32 o 64 thread paralleli sincroni, e questo impedisce un'adozione ampia e semplice.
Inoltre ci sono problemi con l'architettura, e preoccupazioni a livello di prestazioni di sistema, perché bisogna spostare i dati dalla CPU o dal sistema alla GPU per ottenere le migliori prestazioni: tale movimento prima di tutto causa resistenza (negli sviluppatori, NdR), e secondariamente riduce le prestazioni.
Il punto è l'efficienza con cui si spostano i dati, e noi spieghiamo come farlo, anche senza un'efficienza ottimale. Il futuro ci darà una memoria completamente unificata come parte dell'HSA, e sarà fisicamente unita alle nostre APU, ma non sulle nostre schede video discrete.
Consideriamo poi che per avere le migliori prestazioni bisogna usare una memoria specializzata o un bus dedicato, ma non molti lo sanno quando cominciano a sviluppare con OpenCL. Così fanno delle semplificazioni e sentono che non possono o non dovrebbero differenziare le architetture CPU da quelle GPU. Purtroppo o per fortuna (è difficile da dire) OpenCL funziona su entrambe, ma non c'è garanzia che le prestazioni di CPU e GPU saranno uguali. Bisogna programmare sapendo che si sta scrivendo codice per la GPU e non la CPU, per far rendere al meglio OpenCL sulla GPU.
Clicca per ingrandire
TH: In poche parole, qual è la vostra missione? Che messaggio volete dare agli sviluppatori?
AL: La prima cosa da capire è che bisogna spostare i dati, e poi che la programmazione dev'essere molto parallelizzata. E terzo, comprendere che l'ottimizzazione si raggiunge con il calcolo parallelo. Bisogna conoscere l'architettura su cui si programma: è questo è l'aiuto che diamo agli sviluppatori, e sta iniziando a dare i suoi frutti. Abbiamo fatto un sondaggio tra gli sviluppatori in diverse parti del mondo che ha mostrato come l'OpenCL stia guadagnando consensi.
TH: parliamo delle APU nel contesto del calcolo mobile e del consumo. Le regole degli algoritmi di risparmio energetico sono cambiate? Un'APU entra in throttle in modo differente a seconda del tipo di alimentazione?
AL: Sulla CPU ho paura che le cose non cambino. La memoria e la gestione energetica del sistema sono molto sofisticate e a volte dipende dal sistema di classificazione, che ha la maggior parte dei diritti di ridurre l'attività. La nostra GPU è piuttosto flessibile e adattabile, e la sua attività a volte affligge persino la gestione delle prestazioni. L'hardware tenterà di consumare il meno possibile se non è sotto una pressione ragionevole: fondamentalmente rallenta se stesso quando non ha abbastanza lavoro da fare. Non posso dire che sia il massimo, ma proveremo a renderlo il più efficiente possibile dal punto di vista energetico.
Clicca per ingrandire