OpenCL nel Trading - pagina 2

[MetaQuotes]

OpenCL 1.2: Panoramica di alto livello

OpenCL 1.2: Panoramica di alto livello

La conferenza fornisce una panoramica di alto livello di OpenCL 1.2, dello standard e dei modelli al suo interno.

Questa lezione fornisce una solida base per apprendere il calcolo eterogeneo, OpenCL C e come scrivere software ad alte prestazioni con OpenCL.

[MetaQuotes]

OpenCL 1.2: OpenCL C

OpenCL 1.2: OpenCL C

In questo video su OpenCL 1.2: OpenCL C, il relatore introduce OpenCL C come una modifica di C progettata per la programmazione dei dispositivi, con alcune differenze fondamentali, come le dimensioni fisse dei caratteri e la possibilità di funzioni incorporate. Discutono di regioni di memoria, vettori, strutture e kernel e di come ottenere codice vettorializzato. Sottolineano l'importanza dell'uso della memoria locale e costante e consigliano cautela quando si usano le estensioni. Il relatore sottolinea l'importanza di comprendere la struttura di base e il funzionamento di OpenCL C per prestazioni ottimali e incoraggia gli spettatori a continuare a conoscere OpenCL e i suoi modelli associati.

• 00:00:00 In questa sezione, il video introduce OpenCL C come linguaggio principale per la programmazione dei dispositivi OpenCL. OpenCL C è una modifica del linguaggio di programmazione C destinata ai dispositivi, ma ci sono alcune differenze rispetto al tradizionale C99 che includono l'assenza di puntatori di funzione e ricorsione, nonché la possibilità di incorporare le chiamate di funzione. Nonostante alcune di queste differenze, OpenCL C non è un sottoinsieme di C in quanto ha alcune funzionalità che non sono presenti in C99. Questa sezione copre alcune importanti nozioni di base come regioni di memoria, operazioni vettoriali, strutture, funzioni e kernel e l'obiettivo è fornire un background sufficiente in modo che i visualizzatori possano iniziare a utilizzare OpenCL in modo efficiente.
  
  
• 00:05:00 In questa sezione vengono discusse le differenze tra OpenCL C e C. OpenCL C fornisce una rappresentazione concreta per interi con segno utilizzando il complemento a due, mentre C non lo specifica. I tipi OpenCL C hanno dimensioni fisse, inclusi i tipi vettoriali e immagine, che non sono presenti o sono implementati in modo meno elegante in C. Inoltre, OpenCL C definisce le dimensioni per i tipi integrali come char, short, int e long, nonché i relativi e versioni non firmate. È importante tenere presente che i tipi di host e dispositivo differiscono in OpenCL C e che è necessario utilizzare middleware o librerie per garantire il corretto trasferimento dei dati tra di loro.
  
  
• 00:10:00 In questa sezione, il relatore discute il modello di memoria OpenCL C e come vengono utilizzate le parole chiave per specificare regioni di memoria come privata, costante, locale e globale. In OpenCL C, è importante sapere dove si trova la memoria poiché alcuni tipi non possono essere comunicati tra l'host e il dispositivo. Il relatore introduce anche il concetto di vettori e discute diversi approcci per ottenere un buon codice vettorializzato per le operazioni che avvengono all'interno del processore. Non è consentito spostare un puntatore da una regione di memoria a un'altra, ma è possibile copiare da uno spazio di memoria a un altro.
  
  
• 00:15:00 In questa sezione, il relatore discute le varie opzioni disponibili per la vettorializzazione del codice e mette in evidenza OpenCL C come un modo naturale ed efficiente per ottenere la vettorializzazione. I tipi di vettore in OpenCL C sono cittadini di prima classe e sono direttamente accessibili agli utenti. Le operazioni a livello di componenti tra vettori implicano l'utilizzo di un operatore generale che può essere addizione, sottrazione, moltiplicazione o qualsiasi altro operatore relazionale. Tuttavia, gli operatori relazionali possono creare confusione quando si confrontano i vettori poiché il risultato è un vettore con un'operazione booleana eseguita a livello di componenti, quindi gli utenti devono essere consapevoli di questo. Infine, le operazioni di mixaggio tra scalari e vettori non sono definite, quindi gli utenti devono prestare attenzione quando eseguono tali operazioni.
  
  
• 00:20:00 In questa sezione, l'istruttore discute le operazioni sui vettori e l'indirizzamento in OpenCL C. I vettori possono operare su vettori o scalari, che verranno riempiti fino alla dimensione del vettore, ed è possibile accedere ai componenti di un vettore utilizzando il punto notazione con il numero del componente specifico rappresentato in esadecimale. L'istruttore osserva che la domanda di livello superiore è perché utilizzare i tipi vettoriali OpenCL e spiega che l'utilizzo dei vettori consente una comunicazione chiara delle operazioni vettoriali tra il programmatore e il compilatore e può portare a prestazioni migliori poiché il compilatore può ottimizzare meglio le operazioni vettoriali . Infine, l'istruttore afferma che OpenCL C supporta anche l'utilizzo di strutture e unioni per aggregare i dati.
  
  
• 00:25:00 In questa sezione, il relatore discute l'uso delle strutture OpenCL C e l'importanza di prestare attenzione allo scambio di dati tra l'host e il dispositivo. Consigliano di evitare l'uso delle strutture OpenCL C perché possono causare problemi di prestazioni ed è difficile ottenere il layout binario corretto durante la copia dei dati. L'oratore procede a parlare di funzioni e di come siano solo normali funzioni C senza nulla di speciale, tranne che la ricorsione è vietata. Menzionano anche che lo spazio di memoria privato è implicito negli argomenti, il che può causare problemi quando si gestiscono allo stesso modo diverse regioni di memoria. Infine, il relatore descrive i kernel come punti di ingresso per l'esecuzione del dispositivo e spiega come gli argomenti del kernel sono puntatori a qualcosa di globale o semplicemente a valori che vengono copiati.
  
  
• 00:30:00 In questa sezione, l'oratore presenta un programma OpenCL C che somma due array insieme e memorizza i risultati nelle stesse posizioni in termini di componenti. Il programma utilizza get_global_ID e altre funzioni pertinenti per accedere alla dimensione globale del lavoro, alla dimensione del gruppo di lavoro e all'offset globale. Il relatore sottolinea l'importanza di utilizzare la memoria locale quando possibile per ottenere le massime prestazioni e fornisce un modo per dichiarare la memoria locale fornendo un parametro nell'elenco degli argomenti. Il relatore consiglia inoltre di utilizzare il "tipo DEP" per facilitare la programmazione.
  
  
• 00:35:00 In questa sezione, il relatore discute l'uso della memoria locale e costante nei kernel OpenCL C. La memoria locale viene utilizzata per archiviare i dati condivisi tra tutti gli elementi di lavoro in un gruppo di lavoro, mentre la memoria costante è una memoria di sola lettura condivisa anche tra tutti gli elementi di lavoro. È importante notare che i kernel non possono allocare memoria da soli e che più kernel non possono cooperare tra loro. L'oratore menziona anche che ci sono attributi in OpenCL C che possono essere usati per ottimizzare la vettorizzazione e trasmettere informazioni al compilatore.
  
  
• 00:40:00 In questa sezione, il relatore spiega l'importanza della dimensione richiesta del gruppo di lavoro per ottimizzare le prestazioni nei kernel. Menziona l'uso di ottimizzazioni speciali da parte del compilatore quando la dimensione del gruppo di lavoro è fissa. L'oratore parla brevemente del supporto delle immagini di OpenCL, che non gli interessa molto poiché si concentra sull'informatica generica. Inoltre, cita le funzioni OpenCL C integrate che sono come una libreria standard, comprese le funzioni degli elementi di lavoro, le funzioni matematiche, le funzioni intere e le funzioni geometriche. La sincronizzazione è un argomento complesso nel modello di programmazione OpenCL C poiché è progettato per le prestazioni e sono fornite operazioni atomiche e parallelismo. Infine, il relatore menziona le estensioni di OpenCL che è possibile utilizzare una volta compresa la struttura di base e il funzionamento di OpenCL C.
  
  
• 00:45:00 In questa sezione, l'oratore consiglia cautela quando si usano le estensioni in OpenCL 1.2, nonostante le funzionalità extra che forniscono. Avverte che non sono ancora completamente integrati nelle specifiche e potrebbero essere rimossi o causare il blocco del fornitore. Tuttavia, riconosce anche che alcune estensioni possono essere utili e incoraggia gli spettatori a esaminare le estensioni disponibili. In conclusione, il relatore invita gli spettatori a continuare a conoscere OpenCL ei suoi modelli associati e offre i suoi servizi come consulente per coloro che cercano consigli sulla progettazione di programmi OpenCL efficienti.

[MetaQuotes]

Architettura della GPU OpenCL

Architettura della GPU OpenCL

Questo video approfondisce l'architettura delle GPU nel contesto della programmazione OpenCL. Il relatore spiega le differenze tra l'architettura GPU OpenCL e l'architettura GPU generale, il concetto di fronte d'onda come unità più piccola di un gruppo di lavoro, i problemi di I/O di memoria e latenza nascosta e i fattori che influenzano l'occupazione e gli accessi alla memoria coalescente. Viene inoltre sottolineata l'importanza di progettare algoritmi e strutture di dati tenendo conto degli accessi alla memoria coalescente, nonché la necessità di misurare le prestazioni della GPU. L'oratore incoraggia gli spettatori a contattarlo per assistenza nell'utilizzo della tecnologia per prestazioni ottimali senza bisogno di una conoscenza approfondita dei processi sottostanti.

• 00:00:00 In questa sezione, il relatore introduce l'argomento dell'architettura GPU e la sua importanza nella programmazione OpenCL. Mentre molte persone credono che OpenCL sia solo per GPU, l'oratore sottolinea che anche le CPU hanno istruzioni SIMD che utilizzano concetti simili. Viene anche discussa la motivazione alla base dell'utilizzo delle GPU per l'elaborazione generica: è stata una scoperta accidentale derivante dallo sviluppo delle GPU per l'elaborazione della grafica. Il relatore mette in guardia contro l'affidamento ai dipartimenti di marketing per comprendere l'architettura e sottolinea che una profonda comprensione dell'architettura è necessaria per un uso efficiente di OpenCL.
  
  
• 00:05:00 In questa sezione, il relatore discute la questione delle vistose tecniche di marketing utilizzate per promuovere le GPU che spesso non forniscono informazioni utili o rilevanti agli sviluppatori. Viene quindi introdotta l'architettura GPU OpenCL, che differisce dall'architettura GPU generale in quanto si concentra specificamente su come OpenCL la vede. Gli spazi di memoria costante e globale esistono fisicamente in una GPU e la memoria locale e privata sono implementate nell'hardware e condivise con tutti gli elementi di elaborazione. Il modello di esecuzione della GPU è caratterizzato dall'avere puntatori di istruzioni bloccati insieme tra gli elementi di elaborazione. Viene fornito un esempio di quattro elementi di elaborazione che eseguono la stessa istruzione di aggiunta, che può essere considerata come un quattro con l'istruzione SIMD.
  
  
• 00:10:00 In questa sezione, l'oratore spiega il concetto di fronte d'onda, che è l'unità più piccola di un gruppo di lavoro che esegue insieme. Il fronte d'onda viene creato fissando il puntatore dell'istruzione per gli elementi di lavoro in un gruppo di lavoro da bloccare insieme e tutti gli elementi di elaborazione all'interno di un fronte d'onda devono eseguire le stesse operazioni, anche quando si tratta di dati diversi. Tuttavia, ciò crea problemi durante l'esecuzione di istruzioni condizionali in cui gli elementi di lavoro all'interno di un fronte d'onda prendono percorsi diversi, causando divergenze. Per risolvere questo problema, OpenCL ha una funzione integrata chiamata "select", che compila in un'unica istruzione del processore per un'esecuzione condizionale efficiente.
  
  
• 00:15:00 In questa sezione, l'oratore parla del costo dell'I/O della memoria e di quanto sia lento. Spiegano un esperimento mentale di un singolo elemento di elaborazione che esegue un'istruzione al secondo e il tempo necessario per gli accessi globali per valori a 32 e 64 bit, con quest'ultimo che impiega il doppio del tempo. Tuttavia, l'I/O della memoria è costante, quindi per ottenere prestazioni migliori, è possibile aumentare la complessità delle operazioni per pagare l'operazione di memoria. Ciò è dimostrato attraverso un esempio di esecuzione di un milione di operazioni e raggiungimento del 100% di efficienza ALU. Anche se questo potrebbe non essere pratico, è utile in alcune applicazioni come il mining di criptovaluta o la crittografia.
  
  
• 00:20:00 In questa sezione, il relatore discute il problema della latenza della memoria e come influisce sulle prestazioni delle GPU. Con l'obiettivo di raggiungere il 100% di utilizzo ridotto e mantenere occupati gli elementi di elaborazione, l'intuizione è di sovraccaricare l'unità di calcolo con i gruppi di lavoro. Riempiendo il pool di lavoro con più gruppi di lavoro, la CPU può eseguire istruzioni da questi gruppi in un ordine particolare per un numero fisso di cicli o fino a una richiesta di memoria. L'obiettivo è nascondere le grandi latenze della memoria globale e mantenere gli elementi di elaborazione occupati con gruppi di lavoro fino all'arrivo della memoria.
  
  
• 00:25:00 In questa sezione, il relatore spiega il concetto di latenza nascosta, che è la chiave per ottenere buone prestazioni nella programmazione GPU. L'occultamento della latenza è il processo di pianificazione di calcoli utili tra recuperi di memoria a lunga latenza in modo che le operazioni di memoria appaiano libere. Questo viene fatto attraverso il bilanciamento del carico e la gestione del fronte d'onda. L'unità di calcolo ha un pool di lavoro costituito da fronti d'onda pronti e bloccati in cui il puntatore dell'istruzione è bloccato. Il numero di fronti d'onda nel pool influisce sull'utilizzo dell'unità di calcolo, con un numero maggiore che la tiene sempre occupata. Lo scheduler globale invia i gruppi di lavoro non elaborati alle unità di calcolo, con lo scheduler del lavoro che ha un numero massimo fisso di fronti d'onda. Il punto chiave è che l'accesso alla memoria può essere completamente nascosto se viene scritto un buon codice.
  
  
• 00:30:00 In questa sezione viene introdotto e spiegato il concetto di occupazione come misura del numero di fronti d'onda che possono essere eseguiti rispetto al numero totale che possono essere eseguiti. Viene dimostrato il calcolo dell'occupazione e viene sottolineata la sua importanza nella progettazione di kernel più veloci. Il fattore limitante dell'occupazione è identificato nella memoria privata e locale, condivisa tra tutti gli elementi di elaborazione. Viene spiegato che l'intreccio di istruzioni ALU con istruzioni I/O è fondamentale per nascondere la latenza e che avere un numero sufficiente di istruzioni ALU può migliorare l'occupazione, rendendo così i kernel più veloci.
  
  
• 00:35:00 In questa sezione, il relatore discute il compromesso tra l'uso delle risorse per oggetto di lavoro nella programmazione OpenCL e il numero risultante di fronti d'onda che possono risiedere su un'unità di calcolo. Maggiore è il numero di risorse utilizzate per elemento di lavoro, minore è il numero di fronti d'onda che possono risiedere su un'unità di calcolo, con conseguente minore occultamento della latenza. Al contrario, l'utilizzo di meno risorse si traduce in più fronti d'onda e in un maggiore occultamento della latenza. Il relatore fornisce un esempio di calcolo per determinare il numero massimo di fronti d'onda in base alla memoria privata e alle dimensioni della memoria locale, nonché il numero fisso di elementi di lavoro per fronte d'onda. Il relatore spiega anche il concetto di canali di memoria che influenzano l'accesso diretto delle unità di calcolo alla memoria globale.
  
  
• 00:40:00 In questa sezione, il relatore discute la memoria globale nell'architettura GPU OpenCL e come funziona fisicamente per prestazioni migliori. La memoria è suddivisa in sottoinsiemi, ciascuno accessibile da un canale specifico, quindi le richieste di memoria possono essere serializzate e limitare le prestazioni quando tutte le unità di calcolo accedono a un canale di memoria. L'hardware offre una soluzione attraverso modelli di accesso efficienti di elementi di lavoro adiacenti che accedono alla memoria adiacente, chiamati accessi di memoria coalescenti, che raggiungono le massime prestazioni ma molti modelli di accesso possono limitare il parallelismo e causare una ricerca nelle prestazioni. I benchmark informativi sono fondamentali per sapere cosa è generalmente veloce o lento nell'hardware reale. Gli elementi di lavoro che caricano i valori adiacenti sono molto veloci, mentre il caricamento casuale è molto lento, ma l'occultamento della latenza aiuta a migliorare l'utilizzo complessivo.
  
  
• 00:45:00 In questa sezione, il relatore spiega l'importanza di progettare algoritmi e strutture di dati tenendo conto degli accessi alla memoria coalescente. Utilizzando fatti e compromessi di alto livello, gli sviluppatori possono limitare l'accesso casuale alla memoria e influenzare i loro progetti in modo da avere quante più istruzioni ALU possibili per consentire l'occultamento della latenza. L'oratore spiega anche che esistono canali di memoria e che alcuni schemi di accesso alla memoria possono migliorare le prestazioni. Inoltre, il relatore accenna alle prossime discussioni sulla programmazione parallela, comprese le operazioni atomiche e la cooperazione tra elementi di lavoro e la misurazione delle prestazioni della GPU. L'oratore sta attualmente cercando sponsorizzazioni per lavori futuri su OpenCL.
  
  
• 00:50:00 In questa sezione, il relatore conclude lo screencast sull'architettura GPU OpenCL incoraggiando gli spettatori a contattarlo per ricevere assistenza nell'utilizzo della tecnologia per prestazioni ottimali senza richiedere una comprensione approfondita dei processi sottostanti.

[MetaQuotes]

Episodio 1 - Introduzione a OpenCL

Episodio 1 - Introduzione a OpenCL

In questa video introduzione a OpenCL, David Gohara spiega come OpenCL è progettato per consentire un accesso facile ed efficiente alle risorse di elaborazione su diversi dispositivi e hardware, consentendo il calcolo ad alte prestazioni con una gamma di applicazioni, tra cui l'elaborazione di immagini e video, il calcolo scientifico, imaging medico e scopi finanziari. OpenCL è una tecnologia standard aperta indipendente dal dispositivo, particolarmente efficiente per le attività parallele di dati. Il relatore dimostra la potenza della tecnologia OpenCL nel ridurre i tempi di calcolo per i calcoli numerici e ne evidenzia il potenziale per la ricerca scientifica e l'uso generale. Inoltre, gli spettatori sono incoraggiati a unirsi alla comunità online per gli scienziati che utilizzano Mac, l'organizzazione di ricerca Mac e a supportare la comunità acquistando articoli dal negozio Amazon collegato al loro sito web.

• 00:00:00 In questa sezione, David Gohara introduce il concetto di OpenCL e le sue specifiche, che è un linguaggio di calcolo aperto inizialmente proposto da Apple nel 2008. OpenCL è progettato per attività di calcolo parallelo che richiedono molta potenza di calcolo e si concentra su utilizzando più core per migliorare le prestazioni piuttosto che aumentare la velocità di clock. Il gruppo Khronos mantiene la specifica OpenCL, il che significa che chiunque possa usarla deve averla implementata da qualcuno. Il fattore critico è che OpenCL è una tecnologia standard aperta progettata per sfruttare la potenza di calcolo per migliorare le prestazioni di calcolo.
  
  
• 00:05:00 In questa sezione, il relatore introduce OpenCL e il suo design per consentire l'accesso a tutte le risorse dei vari dispositivi e hardware di un computer per supportare calcoli paralleli generici, a differenza di DSP dedicati o applicazioni solo grafiche. È progettato per essere indipendente dal dispositivo e garantisce la portabilità del codice tra le implementazioni. Qualsiasi hardware può diventare un dispositivo OpenCL se soddisfa i requisiti minimi della specifica, inclusi CPU, GPU, chip DSP e processori incorporati. OpenCL fornisce API pulite e semplici per l'accesso a diversi dispositivi e l'esecuzione di elaborazione ad alte prestazioni con supporto del linguaggio c99, tipi di dati aggiuntivi, funzioni e qualificatori integrati e framework di gestione dei thread per gestire le attività sotto il cofano senza problemi. L'obiettivo principale di OpenCL è quello di essere un framework efficiente, leggero e facile da usare che non monopolizzi le risorse di sistema.
  
  
• 00:10:00 In questa sezione, il relatore sottolinea l'importanza di OpenCL nel fornire linee guida per la progettazione di nuovo hardware mentre le persone sviluppano nuovi chip o componenti hardware. OpenCL garantisce inoltre determinati valori di accuratezza e consente un'ampia gamma di applicazioni, tra cui calcolo scientifico, elaborazione di immagini e video, imaging medico e scopi finanziari. Il relatore spiega che OpenCL è progettato per il calcolo parallelo dei dati ed è particolarmente efficiente per le attività parallele dei dati, come prendere il valore assoluto di singoli pezzi di dati e sfocare le immagini utilizzando un filtro a scatola calcolando la somma e la media di un insieme di pixel in una scatola.
  
  
• 00:15:00 In questa sezione, il relatore spiega come funzionano i calcoli paralleli dei dati, in particolare con l'elaborazione delle immagini come esempio. Ogni casella di valori di pixel viene letta dall'immagine e scritta in un buffer di dati separato, consentendo di svolgere un lavoro indipendente senza preoccuparsi della sincronizzazione. OpenCL è inoltre progettato per funzionare insieme a OpenGL, che è un linguaggio di programmazione grafica in grado di condividere dati con OpenCL, rendendo possibile eseguire scricchiolii di numeri complessi e visualizzazioni con un sovraccarico di prestazioni ridotto. Tuttavia, OpenCL non è adatto per problemi sequenziali, calcoli che richiedono punti di sincronizzazione costanti o limitazioni dipendenti dal dispositivo.
  
  
• 00:20:00 In questa sezione, il relatore introduce OpenCL e spiega come è progettato per sfruttare la potenza di calcolo nei computer in modo semplice e portabile. Cita CUDA e come sia una potente interfaccia di programmazione per eseguire calcoli su schede grafiche, ma non è indipendente dal dispositivo e funziona solo su hardware NVIDIA. Tuttavia, l'oratore spiega che gli utenti possono utilizzare sia CUDA che OpenCL e che sono praticamente gli stessi quando si tratta di kernel. Inoltre, il relatore spiega che OpenCL è già implementato in Mac OS 10 Snow Leopard e viene fornito come framework di sistema. Inoltre, sia Nvidia che AMD stanno lavorando alle proprie implementazioni di OpenCL, che potrebbero fornire l'accesso ad altri sistemi operativi e piattaforme.
  
  
• 00:25:00 In questa sezione, il relatore discute la prevalenza di GPU compatibili con OpenCL nelle schede attualmente in commercio, in particolare nei prodotti Apple come l'iMac da 24 pollici e alcuni modelli di MacBook Pro. Nota che tutte le schede Nvidia sono compatibili con OpenCL, con una stima di 1-2 milioni di schede spedite a settimana. Il relatore spiega come OpenCL si inserisce nel framework di Apple, poiché è strettamente legato a OpenGL e ad altre tecnologie grafiche e multimediali. Spiega inoltre perché le GPU sono ideali per il calcolo dei numeri, vantando un'elevata scalabilità e parallelismo dei dati. Nonostante ciò, esistono limitazioni nel trasferimento dei dati dalla parte principale del computer alla scheda grafica, poiché il bus PCI è molto più lento della memoria sulla scheda grafica stessa.
  
  
• 00:30:00 In questa sezione, il relatore discute alcuni fattori da considerare quando si utilizzano GPU con OpenCL, tra cui la spesa computazionale del problema, la gestione degli errori e il debug e requisiti specifici di organizzazione dei dati. Il relatore elogia OpenCL per essere una specifica aperta che consente un facile accesso ai dispositivi ed è portabile su sistemi operativi e piattaforme hardware. L'oratore mostra quindi come spostare il codice dall'esecuzione sulla CPU all'esecuzione sulla GPU utilizzando un esempio tratto dal loro programma che valuta le proprietà elettrostatiche delle molecole biologiche.
  
  
• 00:35:00 In questa sezione, il relatore introduce la potenza della tecnologia OpenCL, che consente un utilizzo efficiente delle risorse computazionali nei calcoli numerici. La dimostrazione mostra un calcolo del problema del valore limite su una singola CPU, che richiede circa 60 secondi per essere completato. Quando viene eseguito su 16 thread, il tempo di calcolo si riduce a 4,8 secondi. L'oratore mostra quindi lo stesso calcolo su una GPU e il tempo di calcolo ridotto a circa 180 millisecondi. I risultati ottenuti dalla GPU sono identici a quelli ottenuti dalla CPU, e il codice utilizzato in entrambi i calcoli è quasi lo stesso, con lievi modifiche per prestazioni migliori. La dimostrazione evidenzia le entusiasmanti possibilità che la tecnologia OpenCL offre alla scienza e all'uso generale.
  
  
• 00:40:00 In questa sezione del video, l'oratore suggerisce alcune cose agli spettatori. In primo luogo, parla della comunità online per gli scienziati che usano Mac, chiamata Mac research org, e incoraggia gli spettatori a unirsi. In secondo luogo, cita altre due utili serie di tutorial, Cocoa for Scientists e X Grid Tutorials, anch'esse disponibili sul loro sito web. Infine, chiede agli spettatori di aiutare la comunità acquistando articoli dal negozio Amazon collegato al loro sito Web in quanto aiuterebbe con i costi di manutenzione di server, hardware e altre spese.

[MetaQuotes]

Episodio 2 - Fondamenti di OpenCL

Episodio 2 - Fondamenti di OpenCL

Questo video introduce il linguaggio di programmazione OpenCL e spiega le basi di come usarlo. Copre argomenti come i diversi tipi di memoria disponibili per un sistema informatico, come allocare le risorse e come creare ed eseguire un kernel.

• 00:00:00 Il primo podcast di questa serie ha introdotto OpenCL e discusso le basi dell'utilizzo di una CPU e una GPU per elaborare i dati. Questo podcast copre l'elenco delle schede grafiche supportate per l'utilizzo di OpenCL, oltre a spiegare perché le CPU sono più efficaci nel nascondere le latenze della memoria.
  
  
• 00:05:00 OpenCL è una piattaforma per accelerare i calcoli su CPU e GPU. Gli oggetti che comprendono OpenCL includono dispositivi di calcolo, oggetti di memoria e oggetti eseguibili. I gruppi di dispositivi sono una struttura comune per raggruppare più dispositivi di elaborazione.
  
  
• 00:10:00 Questo video copre le differenze tra CPU e GPU, con particolare attenzione agli oggetti di memoria OpenCL. I tre tipi di oggetti di memoria OpenCL sono array, immagini ed eseguibili. Il video illustra anche come creare e utilizzare i kernel OpenCL.
  
  
• 00:15:00 OpenCL è un potente linguaggio di programmazione utilizzato per la grafica e il calcolo parallelo. OpenCL consente di compilare il codice in fase di esecuzione o precompilato e gli elementi di lavoro sono raggruppati in gruppi di lavoro.
  
  
• 00:20:00 OpenCL è una potente API multipiattaforma per il GPU Computing. Il video OpenCL Fundamentals discute i concetti di intervalli ND e dimensioni dei gruppi di lavoro e come sono correlati in 2 e 3 dimensioni.
  
  
• 00:25:00 Questo video illustra le basi di OpenCL, inclusi i diversi tipi di tipi di immagine disponibili, l'esecuzione del kernel, la gestione della memoria e gli spazi degli indirizzi.
  
  
• 00:30:00 In questo video, l'autore spiega i diversi tipi di memoria disponibili per un sistema informatico, tra cui la memoria globale, la memoria costante, la memoria locale e la memoria privata. La memoria globale è il tipo di memoria più grande e più importante, mentre la memoria privata è per i dati a livello di kernel.
  
  
• 00:35:00 In questo video vengono spiegati i passaggi di base dell'utilizzo di OpenCL, inclusa l'inizializzazione di OpenCL, l'allocazione delle risorse e la creazione e l'esecuzione di un kernel.
  
  
• 00:40:00 In questo video vengono discusse le basi di OpenCL. Il primo passaggio è l'allocazione, quindi viene scritto il codice per inviare i dati alla scheda grafica. Il passaggio successivo è la creazione del programma e del kernel, in cui OpenCL viene utilizzato per creare un programma e un kernel specifico. Infine, il programma viene eseguito.
  
  
• 00:45:00 In questo video, l'autore spiega i passaggi necessari per creare un kernel in OpenCL. Copre i concetti di base di OpenCL, come le dimensioni e gli elementi di lavoro, e spiega come accodare ed eseguire un kernel. Fornisce anche una breve panoramica delle specifiche Khronos OpenCL e il video di Barbara, che è altamente raccomandato.|
  
  
• 00:50:00 In questo episodio, l'host copre le basi di OpenCL, incluso come creare un semplice programma e come utilizzare la libreria di runtime OpenCL.

[MetaQuotes]

Episodio 3 - Creazione di un progetto OpenCL

Episodio 3 - Creazione di un progetto OpenCL

Questo video fornisce una panoramica completa delle domande e dei dubbi comuni relativi a OpenCL. Gli argomenti trattati includono l'aritmetica a doppia precisione, la programmazione orientata agli oggetti, le dimensioni globali e dei gruppi di lavoro e i problemi scientifici che possono essere risolti con OpenCL. Il relatore sottolinea l'importanza di selezionare attentamente le dimensioni dei gruppi di lavoro globali e locali, nonché di modificare gli algoritmi e le strutture dei dati per adattarli alle preferenze di layout dei dati della GPU. Il relatore fornisce anche un esempio di base di codifica in OpenCL e spiega come i kernel possono essere caricati ed eseguiti in un programma. Altri argomenti inclusi sono la gestione di numeri elevati, l'allocazione della memoria e la gestione della coda dei comandi. Il video si conclude con riferimenti a risorse aggiuntive per gli utenti interessati alla moltiplicazione vettoriale di matrici sparse e all'aritmetica di precisione mista.

• 00:00:00 In questa sezione tratteremo alcune domande comuni su OpenCL, tra cui l'aritmetica a doppia precisione, la programmazione orientata agli oggetti, le dimensioni globali e dei gruppi di lavoro e i problemi scientifici che puoi risolvere con OpenCL. La doppia precisione nelle specifiche OpenCL è facoltativa e il supporto dipende sia dall'hardware che dall'implementazione. Se si dispone di hardware che supporta la doppia precisione, è possibile utilizzare un pragma prima di emettere istruzioni per i calcoli a doppia precisione, ma in caso contrario, il comportamento non è definito e potrebbe causare vari problemi. La programmazione orientata agli oggetti può essere utilizzata insieme a OpenCL, ma è importante tenere a mente i limiti del modello di programmazione basato su C di OpenCL. Quando si scelgono le dimensioni globali e del gruppo di lavoro, è importante considerare le caratteristiche dell'algoritmo e il
  dispositivo specifico su cui stai lavorando. Infine, discuteremo i tipi di problemi scientifici che puoi risolvere con OpenCL e quando potrebbe essere una scelta appropriata per le tue esigenze.
  
  
• 00:05:00 In questa sezione, il relatore discute l'aritmetica a doppia precisione e il suo impatto sulle prestazioni delle GPU. Mentre le operazioni in virgola mobile a precisione singola possono fornire circa 1.000 gigaflop al secondo, le operazioni in virgola mobile a doppia precisione possono fornire solo circa 90 gigaflop al secondo sulle GPU, con un calo delle prestazioni di un ordine di grandezza. L'oratore suggerisce di utilizzare l'aritmetica a precisione mista e di emulare l'aritmetica a precisione più elevata su dispositivi che non la supportano se è necessaria la doppia precisione. Inoltre, il relatore osserva che OpenCL non supporta il passaggio di oggetti complessi nel kernel e quindi, in linguaggi come C++ e Objective C, i metodi possono chiamare le routine OpenCL ma non possono passare alcun oggetto istanziato nel kernel. È possibile utilizzare strutture create da tipi intrinseci del linguaggio C o di qualsiasi estensione supportata da OpenCL, ma in OpenCL non è supportato alcun orientamento agli oggetti di livello superiore.
  
  
• 00:10:00 In questa sezione, il relatore discute le dimensioni del gruppo di lavoro e come determinare quale dovrebbe essere la dimensione del gruppo di lavoro locale, in particolare su una GPU. La dimensione del gruppo di lavoro locale deve essere inferiore alla dimensione del gruppo di lavoro globale e deve dividersi equamente in essa. Su una CPU, tuttavia, la dimensione del gruppo di lavoro locale deve sempre essere una perché i punti di sincronizzazione su una CPU per implementare la comunicazione del gruppo di lavoro sono estremamente costosi. Il relatore raccomanda che le dimensioni globali e locali dei gruppi di lavoro non debbano mai essere inferiori alle dimensioni di un warp su hardware NVIDIA o di un fronte d'onda su hardware ATI. Inoltre, sono preferibili potenze di 2 o numeri pari e, a volte, un po' di lavoro extra, come riempire i calcoli con zeri extra, può valere la pena per ottenere una potenza di 2 dimensioni del gruppo di lavoro locale. Nell'implementazione Snow Leopard OpenCL, la dimensione massima del gruppo di lavoro locale è in genere di circa 512 e il numero massimo di thread che possono essere eseguiti su un singolo SM su hardware NVIDIA è di circa 780-784.
  
  
• 00:15:00 In questa sezione del video, il relatore discute le dimensioni dei gruppi di lavoro e come potrebbe non esserci alcun vantaggio aggiuntivo dall'utilizzo di troppi thread. Toccano anche il concetto di dimensionare i problemi in una, due o tre dimensioni e come questo sia utile per alcuni problemi scientifici. Viene menzionata la risolvibilità di alcuni problemi scientifici sulle GPU e, sebbene possa dipendere da implementazioni e strutture di dati specifiche, è possibile eseguire operazioni come FFT, simulazioni Monte Carlo ed equazioni alle derivate parziali in modo molto efficiente sulle GPU. Infine, il video affronta la necessità di modificare algoritmi e strutture di dati per soddisfare le preferenze di layout dei dati della GPU e sottolinea il fatto che i calcoli non devono essere eseguiti in un singolo kernel o in una chiamata in coda.
  
  
• 00:20:00 In questa sezione, il relatore discute la possibilità di suddividere un calcolo in più kernel o di mettere in coda le chiamate in OpenCL, sebbene ciò possa comportare un minore calo delle prestazioni. Lo spiega usando l'esempio di un algoritmo a gradiente coniugato, sottolineando che sebbene possa essere possibile combinare passaggi successivi nell'algoritmo quando si lavora su una CPU, è leggermente diverso quando si ha a che fare con una GPU. L'oratore sottolinea che le operazioni della GPU devono essere invocate esplicitamente per ogni singolo passaggio. Suggerisce di eseguire prima cicli multipli di minimizzazione del gradiente coniugato, seguiti da un controllo per determinare se è stata raggiunta la convergenza desiderata. Sottolinea l'importanza di eseguire quanto più lavoro possibile senza interruzioni e porta l'esempio della dinamica molecolare e dell'elettrostatica come altri problemi che richiedono considerazioni simili. Infine, passa a un esempio OpenCL, osservando che si tratta di un semplice esempio solo per familiarizzare il pubblico con lo strumento OpenCL e il codice reale.
  
  
• 00:25:00 In questa sezione, il relatore discute alcune funzioni chiave del progetto OpenCL che sono state brevemente menzionate nelle puntate precedenti. La prima funzione è CL get device IDs, che identifica il tipo di dispositivo che stai cercando, inclusi CPU, GPU, dispositivi di accelerazione come FPGA e altro. Una volta identificati i dispositivi, è possibile utilizzare le informazioni sul dispositivo CL per comprenderne le proprietà, ad esempio il fornitore, la dimensione della memoria globale, il numero massimo di elementi di lavoro e le estensioni supportate come la doppia precisione. Dopo aver creato il tuo programma, potresti voler controllare il registro di compilazione per errori, poiché non puoi compilare kernel al di fuori di OpenCL. Il registro di compilazione può dirti cosa è andato storto, come un errore di sintassi o un tipo di dati errato, e controllare le opzioni e lo stato di compilazione.
  
  
• 00:30:00 In questa sezione, il relatore spiega i diversi tipi di buffer di memoria in OpenCL, tra cui sola lettura e lettura/scrittura, oltre a fare riferimento alla memoria sull'host. Suggerisce che potrebbe essere utile mettere in coda le scritture per una maggiore efficienza, utilizzando la funzione del buffer di scrittura CL e Q, che può essere bloccante o non bloccante. L'oratore tocca anche brevemente l'esecuzione dei kernel, l'impostazione degli argomenti del kernel e l'utilizzo delle dimensioni di lavoro globali e locali. L'implementazione di OpenCL può decidere automaticamente una dimensione di lavoro locale e il relatore osserva che questo processo ha funzionato in modo ottimale nei suoi esperimenti precedenti.
  
  
• 00:35:00 In questa sezione, il relatore discute alcuni aspetti della regolazione della dimensione del lavoro locale sulla GPU sperimentando il suo valore in base a specifiche funzionalità del kernel, come l'utilizzo della memoria condivisa. Per quanto riguarda la lettura dei risultati, CL true o CL false significa che si tratta di una lettura bloccante o che il programma non attende l'arrivo dei risultati. Le letture bloccanti sono più comunemente utilizzate per garantire il recupero accurato dei risultati prima di essere utilizzate per altri scopi. L'oratore passa quindi a Xcode, descrivendo il progetto come un progetto Xcode standard in cui Open CL è l'unico framework richiesto. Analizza il codice sorgente e il kernel OpenCL, annotandolo per la massima chiarezza. Il kernel è un kernel ADD, che è semplicistico; tuttavia, serve solo a scopo illustrativo. L'oratore successivamente si tuffa in funzioni come le informazioni sul dispositivo e il contesto e l'impostazione della coda dei comandi.
  
  
• 00:40:00 In questa sezione, il video illustra come i kernel OpenCL possono essere caricati in un programma come file esterno o come stringa C. Sebbene possa essere più pulito caricare i kernel come file esterni, il codice può essere più difficile da eseguire il debug in caso di errori. D'altra parte, caricare i kernel come stringhe C rende più difficile per gli utenti visualizzare il codice e ci sono alcune opzioni per proteggere il codice del kernel. Inoltre, il video esplora i vantaggi e gli svantaggi della precompilazione dei programmi rispetto alla compilazione just in time. Sebbene la precompilazione possa nascondere il codice del kernel, l'esecuzione di un programma su hardware diverso potrebbe richiedere ottimizzazioni diverse che non sono possibili tramite la precompilazione. Nel complesso, il video sottolinea che ci sono pro e contro per entrambe le opzioni e che i programmatori devono valutare attentamente le loro esigenze quando scelgono un metodo.
  
  
• 00:45:00 In questa sezione, l'oratore spiega il processo di associazione del codice al kernel CL per invocare e richiamare kernel come un kernel Saxby o ADD. Viene anche coperta l'allocazione della memoria, con la creazione di buffer di input e di contenuto, in cui il primo sarà solo a scopo di lettura, mentre il secondo memorizzerà i risultati e avrà accesso in lettura-scrittura. Una volta impostati gli argomenti del kernel, inizia l'esecuzione, con la dimensione globale del lavoro impostata sul numero di elementi da elaborare, che vengono visualizzati su uno schermo una volta che il controllo viene restituito al programma principale. La necessità di un'attenta gestione della coda dei comandi è essenziale, con il relatore che spiega l'importanza di terminare la coda prima di procedere con i rilasci di memoria. Nel complesso, la funzione presentata ha funzionato, fornendo un valore di input previsto di 32 su tutta la linea.
  
  
• 00:50:00 In questa sezione, il relatore discute su come gestire grandi numeri nel progetto OpenCL e ricorda agli utenti di prestare attenzione alla memoria disponibile e di disattivare le stampe durante l'iterazione di array di grandi dimensioni per evitare il sovraccarico della stampa. Il relatore incoraggia inoltre gli utenti a dare un'occhiata a un documento sulla moltiplicazione vettoriale a matrice sparsa sulle GPU e un'altra presentazione sull'aritmetica a precisione mista. Quindi conclude il podcast invitando domande e sottolineando che il prossimo episodio riguarderà probabilmente il layout dei dati, gli orditi e l'accesso alla memoria.

[MetaQuotes]

Episodio 4 - Disposizione e accesso alla memoria

Episodio 4 - Disposizione e accesso alla memoria

Questo episodio del tutorial si concentra sul layout e sull'accesso alla memoria, che sono essenziali per massimizzare le prestazioni della GPU. Il podcast copre l'architettura della GPU, i cluster di elaborazione dei thread e il coalescenza della memoria, spiegando come ottimizzare l'uso della GPU ed eseguire in modo efficiente calcoli paralleli. Il relatore affronta anche i problemi di accesso ai dati e di indicizzazione che possono causare conflitti, raccomandando l'uso della memoria condivisa e delle letture coalescenti per migliorare le prestazioni. Nel complesso, il video sottolinea l'importanza di comprendere le funzioni specificate da OpenCL e i tipi di dati intrinseci per garantire la compatibilità e offre risorse per un ulteriore apprendimento.

• 00:00:00 In questa sezione del tutorial, l'attenzione è rivolta al layout e all'accesso alla memoria. La comprensione di questi concetti è essenziale per massimizzare le prestazioni delle GPU, che richiedono la disposizione e l'accesso ai dati in un modo specifico. Il podcast si concentra sulla prospettiva della GPU, poiché le CPU sono più indulgenti nell'accesso ai dati, sebbene l'ottimizzazione del codice per le GPU possa anche giovare alle prestazioni della CPU. Inoltre, il podcast copre alcune operazioni generali e affronta domande sulle chiamate di funzione all'interno dei kernel e sull'uso della finitura CL nei precedenti esempi di codice sorgente. Il podcast sottolinea l'importanza di utilizzare solo funzioni specificate da OpenCL e tipi di dati intrinseci per garantire la compatibilità.
  
  
• 00:05:00 In questa sezione, l'oratore discute l'uso di funzioni come Rand o stampa nelle funzioni del kernel sulla CPU. Sebbene sia possibile utilizzare queste funzioni per scopi di debug, non è garantito che funzionino su implementazioni diverse e potrebbero non essere portabili. I kernel possono chiamare funzioni purché possano essere compilati in fase di esecuzione come parte del sorgente del programma contenente tutti i kernel. L'oratore spiega anche CL finish, che è un metodo per fare in modo che la CPU blocchi la sua esecuzione fino a quando tutte le funzioni all'interno della coda dei comandi non sono tornate. Sebbene possa essere utile per il temporizzazione del codice, provoca l'arresto dell'applicazione fino al completamento di tutte le attività, quindi dovrebbe essere utilizzato solo quando assolutamente necessario.
  
  
• 00:10:00 In questa sezione, il relatore discute l'architettura della GPU, concentrandosi in particolare sull'hardware NVIDIA, e su come utilizza i cluster di elaborazione dei thread per eseguire il calcolo. Ogni scheda grafica ha 10 di questi cluster, ciascuno contenente 30 multiprocessori di streaming, che a loro volta contengono otto processori di streaming, due unità funzionali speciali, un'unità a doppia precisione e memoria locale condivisa. Comprendendo questi raggruppamenti, gli sviluppatori possono ottimizzare l'uso della GPU ed eseguire in modo efficiente calcoli paralleli. Il relatore utilizza la terminologia NVIDIA e incoraggia gli ascoltatori a tenere presente la relazione tra thread, elementi di lavoro, blocchi di thread e gruppi di lavoro, che sono tutti aspetti importanti della programmazione OpenCL.
  
  
• 00:15:00 In questa sezione, il relatore discute le diverse terminologie utilizzate per i processori di streaming, come processori scalari, processori di shading o core. Il numero di core in una scheda grafica si riferisce al numero di processori di streaming per multiprocessore di streaming. Il relatore sottolinea che un core su una GPU non equivale a un core su una CPU, e Nvidia li pensa separatamente. La discussione copre anche unità di funzioni speciali per la gestione di funzioni trascendentali, unità a doppia precisione per eseguire aritmetica in virgola mobile a doppia precisione e memoria condivisa della memoria locale utilizzata per condividere dati tra processori di streaming e blocchi di thread in esecuzione sulla GPU. Il cluster di elaborazione dei thread è suddiviso in 10 controller che servono tre diversi SM, con ogni SM contenente otto processori di streaming in grado di eseguire otto blocchi di thread contemporaneamente.
  
  
• 00:20:00 In questa sezione viene introdotto il concetto di warp nella programmazione GPU, che sono unità organizzative costituite da 32 thread che operano in sincronia l'uno con l'altro. Solo i thread nello stesso blocco di thread possono condividere i dati tra loro utilizzando la memoria locale condivisa. Gli orditi sono ulteriormente suddivisi in mezzi orditi, che consistono in 16 thread, a causa dei requisiti hardware. Le GPU sono in grado di gestire molti thread ed è importante avere thread aggiuntivi in esecuzione contemporaneamente per nascondere la latenza della memoria e altri ritardi. Le GPU dispongono di hardware dedicato per la gestione dei thread, consentendo un rapido cambio di contesto. Maggiore è il numero di thread, meglio è e si consiglia di aumentare leggermente le dimensioni dei gruppi di thread per utilizzare tutti i thread in un ordito e migliorare le prestazioni.
  
  
• 00:25:00 In questa sezione, l'istruttore spiega che il caricamento dei dati nella memoria locale implica il caricamento di 16 elementi, che equivalgono a 64 byte, con ciascun thread responsabile del caricamento di quattro byte. L'istruttore spiega anche la programmazione delle istruzioni e il concetto di divergenza, in cui metà dei thread immette un blocco di codice e l'altra metà attende che la prima metà finisca prima di eseguire il proprio. Ciò può causare la serializzazione e partizionare il numero di thread che possono funzionare contemporaneamente. La memoria locale è suddivisa in voci di 4 byte, con ciascuna voce indirizzata in uno dei 16 banchi. Se un mezzo warp di 16 thread accede a banchi individuali, può evitare conflitti tra banchi e accedere alla memoria condivisa alla stessa velocità del file di registro.
  
  
• 00:30:00 In questa sezione, il video discute la coalescenza della memoria e come i thread in un gruppo di lavoro possono caricare in modo cooperativo i dati nella memoria condivisa attraverso la coalescenza della memoria, facendo in modo che le posizioni della memoria condivisa registrino efficacemente i file. La discussione passa quindi al concetto di allineamento della memoria relativo alla memoria globale e all'inserimento dei dati nella memoria locale. Carichi disallineati, carichi permutati e carichi parziali sono tutti problematici in quanto impediscono all'hardware di rilevare un carico unito, con conseguente serializzazione dei singoli carichi nei registri. Per evitare ciò, si consiglia di caricare tutti i dati nella memoria condivisa anche se non è necessario per ottenere un carico coalescente allineato.
  
  
• 00:35:00 In questa sezione, il relatore discute il layout della memoria e l'accesso per la programmazione CUDA. Spiegano che i carichi allineati, in particolare i carichi coalescenti, sono il modo più veloce per ottenere dati dalla memoria globale nella memoria locale o nei registri. Spiegano inoltre che la memoria è divisa in banchi per consentire a più thread di accedervi contemporaneamente, ma l'accesso allo stesso banco può provocare un conflitto tra banchi, che porta alla serializzazione dei dati e a prestazioni ridotte. Inoltre, il relatore osserva che un'eccezione ai conflitti bancari si verifica quando tutti i thread accedono a un singolo banco, il che comporta la trasmissione dei dati e nessun conflitto o serializzazione.
  
  
• 00:40:00 In questa sezione del video, l'istruttore parla del layout della memoria e dell'accesso nelle applicazioni multi-thread. Spiega che i conflitti si verificano quando più thread accedono alla stessa banca per la stessa informazione, con conseguente calo delle prestazioni. Usa la trasposizione della matrice come esempio per illustrare i vantaggi dell'utilizzo della memoria condivisa per le prestazioni e l'importanza di leggere e scrivere nella memoria in modo unito per evitare penalizzazioni delle prestazioni. L'istruttore spiega che in genere viene utilizzato un mezzo-curvatura e consiglia di utilizzare schemi di layout della memoria che evitino conflitti per prestazioni ottimali.
  
  
• 00:45:00 In questa sezione, il relatore affronta il problema dell'inversione degli indici o dello scambio di indici nella memoria della GPU e di come ciò si traduca in una delle due opzioni: accesso alla memoria non unito o uno dei due deve essere unco. Per superare questo problema, i dati vengono letti dalla memoria globale utilizzando una lettura coalescente e archiviati nella memoria condivisa in modo coalescente. La memoria condivisa è veloce e una volta che i dati sono presenti e supponendo che non ci siano due thread che accedono alla stessa informazione, ogni thread può accedere rapidamente al suo unico pezzo di dati. I thread caricano i dati di cui hanno bisogno per trasporre in modo cooperativo e assumono la proprietà di quel pezzo di dati mentre lo scrivono nella memoria globale un grosso pezzo, con conseguenti miglioramenti delle prestazioni per l'accesso ai dati dentro e fuori la GPU.
  
  
• 00:50:00 In questa sezione, il video discute l'uso della trasposizione della matrice sulla GPU e l'importanza di combinare la memoria condivisa con l'unione della memoria e l'allineamento dei dati. La versione ottimizzata è disponibile sul sito web di Apple come progetto Xcode chiamato matrix transpose. Il video spiega che se la falcata è 16 e ci sono 16 banchi, ogni elemento 0, 16, 32, ecc. sarà servito dal banco 0 portando a potenziali conflitti bancari. Per risolvere questo problema e ottenere una trasposizione della matrice ad alte prestazioni, la memoria locale dovrebbe essere riempita di un elemento, risultando in 17 valori caricati. Il video suggerisce che questi concetti sono concetti fondamentali e, una volta compresi, lo spettatore sarà al 95% nell'ottimizzazione delle prestazioni della GPU.
  
  
• 00:55:00 In questa sezione, il relatore promuove il sito Web di Mac Research e le risorse disponibili, che vanno dai tutorial ai tutorial degli esperti e alle discussioni della community. L'accesso al sito Web è gratuito e include informazioni su OpenCL e altre risorse per sviluppatori. L'oratore menziona anche che esiste un negozio Amazon associato al sito Web e incoraggia gli utenti ad acquistare prodotti attraverso di esso per supportare Mac Research. Il relatore conclude affermando che il prossimo video si concentrerà su un esempio del mondo reale con ottimizzazioni del codice e del kernel.

[MetaQuotes]

Episodio 5 - Domande e risposte

Episodio 5 - Domande e risposte

In questo video, l'host risponde a domande sulle GPU e sulla programmazione OpenCL. Spiegano la struttura organizzativa delle GPU, inclusi core, multiprocessori di streaming e altre unità. Anche il concetto di conflitti bancari e memoria locale è trattato in dettaglio, con un esempio di trasposizione di matrici utilizzato per dimostrare come possono verificarsi conflitti bancari. L'oratore fornisce soluzioni per evitare conflitti bancari, incluso il riempimento dell'array di dati locali e la lettura di diversi elementi serviti da banche diverse. Infine, il relatore promuove le risorse sul sito Web di ricerca Mac e promette di fornire un esempio reale con tecniche di ottimizzazione nella prossima sessione.

• 00:00:00 In questa sezione, l'ospite della serie di video OpenCL ha affrontato alcune domande e ha risposto. La prima domanda riguardava la terminologia e il layout della GPU e l'host ha utilizzato una diapositiva Nvidia per illustrare la struttura organizzativa della GPU, inclusi i dieci cluster di elaborazione dei thread e tre multiprocessori di streaming per cluster di elaborazione dei thread. La seconda domanda riguardava i conflitti bancari, che sono stati brevemente accennati nella puntata precedente. Il conduttore ha fornito una spiegazione più dettagliata, concentrandosi su un esempio specifico di trasposizione di matrici e sulle condizioni che possono portare a conflitti bancari. L'episodio si è concluso con un ringraziamento al provider di hosting, Matias, per l'ottimo servizio.|
  
  
• 00:05:00 In questa sezione, il video spiega il concetto di core o processori scalari nelle GPU. Questi core eseguono principalmente operazioni ALU e FPU, ma la loro funzionalità è diversa dai core presenti nelle CPU. Ogni multiprocessore di streaming nell'architettura della serie 10 ha otto core o processori di streaming e ci sono 240 core in totale, che costituiscono la potenza di elaborazione della GPU. Le GPU hanno altre unità come unità a doppia precisione e unità con funzioni speciali, tra le altre. Il video copre anche i conflitti bancari e la memoria locale e il modo in cui influiscono sull'accesso alla memoria nella memoria locale, portando a conflitti bancari. La spiegazione aiuta a chiarire la confusione riguardo alla diversa terminologia utilizzata per CPU e GPU.
  
  
• 00:10:00 In questa sezione, l'oratore spiega il concetto di memoria locale sull'hardware corrente, che è suddiviso in 16 banchi, ognuno dei quali è lungo un kilobyte. L'oratore spiega che successive parole a 32 bit vengono assegnate a banchi successivi e due o più accessi simultanei allo stesso banco determinano la serializzazione dell'accesso alla memoria, che viene definita conflitto di banchi. Tuttavia, l'oratore osserva che se tutti i thread in un half-warp accedono esattamente allo stesso banco o entrata, non si verifica un conflitto bancario e c'è una gestione speciale per quella situazione. Il relatore passa quindi ad affrontare il motivo per cui si verificherebbero conflitti bancari nell'esempio di trasposizione della matrice presentato in precedenza, discutendo la permutazione lungo la diagonale e i carichi coalescenti.
  
  
• 00:15:00 In questa sezione, il relatore discute il problema del conflitto di banca che può sorgere quando viene eseguita una trasposizione di matrice attraverso l'esempio di un ordito, che consiste di 32 fili, divisi in due metà. Ogni thread in un half warp è assegnato a un banco e, idealmente, ogni thread dovrebbe leggere e scrivere su un banco specifico. Tuttavia, quando viene eseguita una trasposizione di matrice, i thread in diverse metà dell'ordito verranno letti dallo stesso banco, causando conflitti tra banchi. Il relatore spiega questo problema attraverso uno schema e fornisce una spiegazione dettagliata con l'esempio dell'assegnazione di elementi alle banche.
  
  
• 00:20:00 In questa sezione, il relatore discute su come aggirare i conflitti bancari quando si ha a che fare con array e memoria condivisa in CUDA. Riempiendo l'array di dati locali, con un valore extra che non viene mai utilizzato, la memoria condivisa viene effettivamente aumentata e questo evita i conflitti di banca. Ora tutti gli elementi di dati vengono letti dalla memoria globale coalescente e allineata ma scrivono nella memoria locale non allineata che non comporta alcuna penalità. Questo processo consente a ciascun thread di eseguire l'offset di uno e di leggere elementi successivi senza tutta la serializzazione sullo stesso banco, il che aumenta le prestazioni. La trasmissione è consentita se i thread tentavano di leggere gli stessi dati, ma durante la lettura di elementi diversi si verifica la serializzazione.
  
  
• 00:25:00 In questa sezione, il relatore discute di come la soluzione ai conflitti bancari implichi la lettura di diversi elementi che sono serviti da banche diverse, piuttosto che dalla stessa. Il problema principale che causa conflitti bancari nell'esempio specifico della trasposizione della matrice è l'accesso a un offset uguale alla dimensione del banco che è anche uguale alla metà della dimensione dell'ordito. Il relatore evidenzia anche varie risorse disponibili sul sito Web di ricerca Mac, tra cui la serie di German Cormac sulla scrittura di applicazioni Cocoa e la serie di seminari online di Nvidia sull'utilizzo di CUDA e OpenCL per la programmazione GPU. Il relatore promette di fornire un esempio del mondo reale nella prossima sessione che riunirà tutto, comprese le tecniche di ottimizzazione come l'utilizzo di memory pad locale e condiviso.

[MetaQuotes]

Episodio 6 - Ottimizzazione del kernel della memoria condivisa

Episodio 6 - Ottimizzazione del kernel della memoria condivisa

Il video discute l'ottimizzazione del kernel della memoria condivisa, in particolare nel contesto di un codice utilizzato per comprendere le proprietà elettrostatiche delle molecole biologiche. L'uso di punti di sincronizzazione e la comunicazione tra elementi di lavoro in un gruppo di lavoro sono fondamentali per eseguire calcoli complessi affinché il programma funzioni in modo efficace. Inoltre, la memoria condivisa, lavorando in modo cooperativo e portando molti dati, consente un accesso più rapido ai dati di sola lettura e aumenta le prestazioni dei calcoli, supportando velocità di accesso più elevate. Il relatore sottolinea inoltre l'importanza di evitare calcoli di trattamento inefficienti sul confine di una griglia e l'importanza del corretto utilizzo dei punti di sincronizzazione, delle barriere e della memoria condivisa. Infine, sottolinea le sfumature dell'esecuzione di OpenCL e fornisce consigli sull'ottimizzazione del sistema per l'utilizzo della GPU, con la dimostrazione eseguita su un Mac.

• 00:00:00 In questa sezione, il relatore discute l'ottimizzazione del kernel della memoria condivisa e fornisce un esempio di come sfruttare la memoria condivisa in un codice reale. Spiega che la memoria condivisa consente un accesso più rapido ai dati di sola lettura, che possono accelerare le prestazioni dei calcoli. Il codice di esempio, derivato da un programma utilizzato per comprendere le proprietà elettrostatiche delle molecole biologiche, evidenzia l'uso di punti di sincronizzazione e la comunicazione tra elementi di lavoro in un gruppo di lavoro per eseguire calcoli complessi. L'obiettivo generale è mostrare come sfruttare le caratteristiche dell'hardware per aumentare le prestazioni e l'efficienza.
  
  
• 00:05:00 In questa sezione, il relatore discute l'importanza di trattare in modo efficiente il calcolo sul bordo di una griglia, che è concettualmente applicabile a tutti i tipi di problemi. Il calcolo comporta il calcolo del contributo di tutti gli atomi nel modello a ciascun punto della griglia, che può essere eseguito utilizzando un approccio incentrato sulla griglia o un approccio incentrato sull'atomo. Sebbene l'approccio incentrato sull'atomo funzioni bene nel calcolo seriale, può essere inefficiente in un ambiente parallelo a causa della sovrascrittura dei valori. Pertanto, l'approccio incentrato sulla griglia è un approccio migliore in quanto ogni punto della griglia leggerà solo i dati, rendendo più facile l'ottimizzazione per le GPU in quanto non hanno accesso a blocchi e riduzioni. L'oratore afferma inoltre che in questo calcolo mostreranno le differenze di prestazioni tra CPU e GPU.
  
  
• 00:10:00 In questa sezione vengono discussi la memoria condivisa e l'approccio incentrato sulla griglia. Si dice che durante il calcolo, il valore del punto della griglia viene modificato, ma deve solo avere un'istantanea o una copia dei valori per tutti questi punti della griglia. Utilizzando la GPU, i punti della griglia possono lavorare in modo cooperativo per portare molti dati, il che aumenta le prestazioni della velocità di accesso ai dati. Questo approccio non richiede blocchi e tutti i punti della griglia quando il calcolo è completo saranno completamente aggiornati, il che evita che i punti della griglia calpestino altri valori. La parte centrale del codice è effettivamente la stessa e l'iterazione della griglia diventa il secondo intervallo, che è uguale al numero di punti della griglia. Viene inoltre introdotto il concetto di memoria condivisa, che consente ai thread di portare i dati in aree più ampie, consentendo a tutti di accedere ai dati il più rapidamente possibile.
  
  
• 00:15:00 In questa sezione, il relatore introduce la memoria condivisa e spiega come funziona. La memoria condivisa ha un limite di 16 kilobyte di spazio utilizzabile per SM, che i processori scalari devono condividere. In genere, il problema non viene affrontato a livello byte per byte ma utilizza float o int, il che significa che generalmente ci sono meno elementi utilizzabili nella memoria condivisa. L'oratore spiega che hanno allocato un blocco di memoria condivisa cinque volte la dimensione locale (64 elementi), dando loro un blocco di 1280 byte che verrà utilizzato per gruppo di lavoro, con ogni gruppo di lavoro largo 64 elementi. Elaborano che suddividono questo blocco in cinque raggruppamenti e forniscono istruzioni su come indicizzare questi dati utilizzando gli offset.
  
  
• 00:20:00 In questa sezione del video, il relatore spiega un metodo per ottimizzare i kernel della memoria condivisa. Spiega che il codice ha una misura di sicurezza in atto per regolare la dimensione locale degli atomi se il numero totale di atomi non è un multiplo della dimensione locale. L'oratore sottolinea che c'è un bug di prestazioni nel codice e sfida gli spettatori a trovarlo. Il codice è suddiviso in due raggruppamenti, dove il primo è un catch-all per garantire che tutto vada bene e il secondo è un'operazione di copia che utilizza la memoria condivisa. L'hardware rileva che tutti i thread accedono ai dati dalla memoria globale con indirizzi sequenziali ed esegue un caricamento completo in memoria, che colpisce la prima barriera. L'oratore discute quindi la necessità di una barriera e mostra una diapositiva che illustra il processo attraverso il quale le mezze deformazioni servono il carico dalla memoria condivisa.
  
  
• 00:25:00 In questa sezione viene discussa l'importanza dell'utilizzo delle barriere nell'ottimizzazione del kernel. È necessaria una barriera per garantire che tutti i dati necessari vengano caricati nella memoria condivisa prima che qualsiasi elemento di lavoro in un gruppo di lavoro possa passare alla fase successiva. Senza barriere, i valori ottenuti saranno errati. Il codice per il calcolo viene eseguito in lockstep, tuttavia, evita i conflitti bancari consentendo la trasmissione quando tutti i thread in un gruppo di lavoro accedono allo stesso elemento nella memoria condivisa. La barriera aiuta anche a prevenire la sovrascrittura dei dati nella memoria condivisa, assicurando che tutti i warp finiscano i loro calcoli prima che i nuovi dati vengano scritti nella memoria condivisa. Viene mostrata anche la dimostrazione del progetto Xcode e del suo funzionamento per fornire una migliore comprensione dei concetti discussi.
  
  
• 00:30:00 In questa sezione del video, il relatore discute gli strumenti e le configurazioni necessarie per ottimizzare le prestazioni del kernel. Il relatore menziona l'utilizzo di LLVM GCC 4.2 clang 1.0 con OpenMP per il supporto OpenMP e la garanzia che le ottimizzazioni regolari siano attivate. Il video passa quindi ai calcoli principali, inclusa la generazione e il riempimento della memoria, il calcolo scalare e l'esecuzione del calcolo scalare della CPU in parallelo con OpenMP. Infine, viene presentato il calcolo ottimizzato della GPU, insieme a un processo di pulizia. Il video include anche frammenti di codice per routine di utilità come la stampa di informazioni sul dispositivo e informazioni sull'interrogazione dei problemi dei file del kernel.
  
  
• 00:35:00 In questa sezione, l'oratore spiega i passaggi coinvolti nella configurazione del kernel per il programma mdh, che include l'allocazione della memoria per la memoria condivisa e la memoria che scriverà i dati. La dimensione globale del lavoro è uguale al numero di punti della griglia regolati e la dimensione del lavoro locale è 64. L'oratore afferma che la dimensione del gruppo di lavoro è una questione di tentativi ed errori e OpenCL può dare una raccomandazione su ciò che pensa sia un buon lavoro dimensione del gruppo. Tuttavia, giocando con diverse dimensioni del gruppo di lavoro, l'oratore ha scoperto che 64 funzionava meglio. Il relatore osserva che sebbene l'impostazione di OpenCL possa richiedere più lavoro rispetto a OpenMP, i miglioramenti delle prestazioni nel codice GPU ottimizzato rendono utile continuare a utilizzare le GPU.
  
  
• 00:40:00 In questa sezione, l'oratore esegue calcoli scalari sulla CPU e mostra che ci vogliono 32 secondi, ma su 16 CPU ci vogliono circa 25 secondi, dimostrando una velocità 10 volte superiore. Quando viene eseguito sulla GPU, impiega 1,2 secondi, 20 volte più veloce rispetto a una singola CPU. Inoltre, i numeri ottenuti dai calcoli della CPU e della GPU erano identici, dimostrando che vale la pena ottimizzare il codice per la GPU. L'oratore avverte gli utenti di fare attenzione quando si eseguono esempi su un sistema con una sola scheda grafica poiché potrebbe sembrare bloccato a causa della mancanza di interruzione preventiva su una scheda grafica.
  
  
• 00:45:00 In questa sezione, il relatore discute alcuni potenziali problemi che possono verificarsi durante l'esecuzione di OpenCL e consiglia agli utenti di essere cauti. Raccomanda di avere due schede grafiche, se possibile, e di assegnarne una al display e l'altra alla gestione di OpenCL. L'oratore osserva inoltre che se il sistema si impantana, gli utenti possono accedere tramite SSH e terminare il processo per riprendere il controllo. Ricorda agli utenti che tutte le informazioni sono disponibili sul sito Web di ricerca Mac, dove possono anche iscriversi al podcast e supportare l'organizzazione senza scopo di lucro tramite un negozio Amazon. Infine, incoraggia gli ascoltatori a visitare il sito Web del gruppo Chronos, che fornisce preziose risorse sulle specifiche OpenCL.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 1. Introduzione al calcolo parallelo ed eterogeneo

1-Introduzione al calcolo parallelo ed eterogeneo

Il relatore in questo video di YouTube fornisce una panoramica del calcolo parallelo ed eterogeneo, che prevede la combinazione di più componenti di elaborazione come CPU e GPU in un unico sistema. Vengono discussi i vantaggi dei sistemi legati alla fusione su un chip, che semplificano il modello di programmazione per il calcolo parallelo ed eterogeneo e consentono prestazioni elevate riducendo al contempo la complessità. Il relatore discute anche diversi approcci come il parallelismo dei dati e il parallelismo delle attività, i linguaggi di programmazione per i modelli di programmazione parallela e i compromessi tra GPU MDS e CPU Intel.

Il video copre i recenti sviluppi nel calcolo parallelo ed eterogeneo, con particolare attenzione alle nuove architetture come Sandy Bridge di Intel. Tuttavia, attualmente non esiste una soluzione chiara alla questione del modello di programmazione. AMD e Intel stanno guidando i progressi, ma si prevede che il campo continuerà a progredire nel tempo.

• 00:00:00 In questa sezione del video, Benedict Gaster, un architetto che si occupa di programmazione presso AMD, fornisce una panoramica dell'elaborazione eterogenea e della sua importanza nella programmazione parallela. Spiega la terminologia utilizzata nel calcolo parallelo, come parallelismo e concorrenza, prima di discutere gli aspetti hardware e software del calcolo eterogeneo. Osserva che AMD si sta muovendo verso architetture basate sulla fusione in cui la GPU e la CPU si trovano sullo stesso silicio e fornisce alcune informazioni sulla loro visione per la programmazione parallela. Inoltre, indica che OpenCL è simile a CUDA e che è un linguaggio parallelo di dati progettato per funzionare in modo efficiente su GPU.
  
  
• 00:05:00 In questa sezione, il relatore discute il concetto di parallelismo nell'informatica, in cui parti di un calcolo sono indipendenti e possono essere eseguite contemporaneamente per aumentare le prestazioni. Ciò è in contrasto con la concorrenza, che è un'astrazione di programmazione che consente la comunicazione tra processi o thread che potrebbero potenzialmente abilitare il parallelismo, ma non è un requisito. Viene introdotto anche il calcolo eterogeneo come sistema composto da due o più motori di calcolo con differenze strutturali significative. L'oratore osserva che le GPU sono un esempio di tali motori, con la mancanza di grandi cache che rappresentano una notevole differenza rispetto alle CPU.
  
  
• 00:10:00 In questa sezione, il relatore introduce l'idea del calcolo parallelo ed eterogeneo, che comporta la combinazione di più componenti di elaborazione, come CPU e GPU, in un unico sistema unificato. Mentre le CPU sono buone a bassa latenza, la GPU è ideale per i processi paralleli di dati. La sfida è gestire insieme i costi e le prestazioni di questi componenti, soprattutto perché il tradizionale bus PCIe crea un collo di bottiglia tra di loro. La soluzione è integrare i componenti su un singolo die di silicio con memoria condivisa. Sebbene i compilatori possano facilitare un certo parallelismo, l'oratore sostiene modelli di programmazione parallela espliciti per raggiungerlo pienamente.
  
  
• 00:15:00 In questa sezione, il relatore spiega l'evoluzione delle architetture informatiche dai processori single-core ai processori multi-core, e ora nell'era eterogenea con le GPU. Mentre le architetture in stile SMP sono diventate difficili a causa di problemi di alimentazione e scalabilità, le GPU offrono un parallelismo dei dati ampio ed efficiente dal punto di vista energetico con un abbondante parallelismo dei dati, rendendole adatte per il calcolo ad alte prestazioni. Tuttavia, i modelli di programmazione e le spese generali di comunicazione presentano ancora delle sfide ed è necessaria una combinazione di elaborazione CPU e GPU per prestazioni ottimali delle applicazioni.
  
  
• 00:20:00 In questa sezione, il relatore discute l'evoluzione della larghezza di banda e della memoria nei dispositivi GPU, riconoscendo che la larghezza di banda della memoria sta aumentando ma non alla stessa velocità dei flop. Sostiene che mentre la GPU può realizzare molto di ciò che può ottenere una CPU, c'è ancora bisogno di un approccio equilibrato poiché la CPU x86 possiede l'universo software e non tutte le applicazioni emergeranno improvvisamente come applicazioni parallele. La GPU è ancora un punto di svolta, ma è necessario riunire i due dispositivi per ottenere i principali vantaggi senza sacrificarsi a vicenda.
  
  
• 00:25:00 In questa sezione, il relatore discute i vantaggi dei sistemi legati alla fusione su un chip (SoC) e come integrano diversi tipi di dispositivi in un singolo chip fornendo il meglio di entrambi i mondi. Viene introdotto anche il PC basato su APU fusion, in cui la GPU fusion viene spostata all'interno di un singolo die, consentendo un aumento significativo della larghezza di banda della memoria tra CPU e GPU. La GPU e la CPU di fusione condividono la stessa memoria di sistema, unendo i due dispositivi insieme. Il relatore affronta anche domande sui linguaggi di programmazione puramente funzionali, sulla loro influenza sui linguaggi esistenti e sull'utilizzo delle GPU per gestire le attività della CPU.
  
  
• 00:30:00 In questa sezione, il relatore discute il potenziale delle future GPU di fusione per semplificare il modello di programmazione per il calcolo parallelo ed eterogeneo e consentire prestazioni elevate riducendo al contempo la complessità. Sebbene possano esserci compromessi in termini di larghezza di banda e latenza della memoria, le GPU di fusione offrono capacità di elaborazione in fattori di forma mobile con memoria condivisa per CPU e GPU, eliminando la necessità di più copie e migliorando le prestazioni. La scalabilità dell'architettura la rende adatta a una vasta gamma di piattaforme, dal mobile al data center, e mentre la prima generazione di APU potrebbe non risolvere completamente il problema dei gigaflop per larghezza di banda di memoria, rimane il potenziale futuro per semplificare la programmazione e ottenere prestazioni elevate promettente.
  
  
• 00:35:00 In questa sezione, il relatore parla di come il software in un mondo eterogeneo influisce sulla programmazione. Il futuro è parallelo, il che significa che la programmazione dovrà adattarsi al parallelismo, che ha numerose risposte diverse. Esiste una varietà di linguaggi disponibili per i modelli di programmazione parallela, come quelli che utilizzano API di thread a grana grossa o quelli che si concentrano sulle astrazioni. Il relatore osserva inoltre che il parallelismo nella programmazione deriva dalla scomposizione delle attività e dalla scomposizione dei dati e che i modelli e i tempi di esecuzione basati sulle attività dovranno disporre di queste funzionalità per creare dipendenze tra le attività, comunicare tra loro ed eseguire il bilanciamento del carico per velocizzare calcolo. La maggior parte degli esempi di questi oggi sono per la CPU, offerti da aziende come Intel e Apple, mentre la recente rete Microsoft per il runtime è la più importante per le prospettive del linguaggio gestito.
  
  
• 00:40:00 In questa sezione, il relatore discute diversi approcci al calcolo parallelo, concentrandosi in particolare sul parallelismo dei dati e sul parallelismo delle attività. Il parallelismo dei dati implica il lavoro su elementi indipendenti in parallelo, come i sistemi di particelle in un gioco, mentre il parallelismo delle attività implica lavori indipendenti che devono comunicare tra loro. Il relatore menziona i linguaggi più diffusi per questi approcci, tra cui OpenCL, CUDA e OpenMP. Il relatore suggerisce inoltre che una combinazione di questi due approcci, nota come parallelismo intrecciato, potrebbe diventare il modello di programmazione emergente del futuro. Il relatore sottolinea la necessità di fondere questi diversi modelli per portare il parallelismo alla programmazione mainstream.
  
  
• 00:45:00 In questa sezione, il relatore discute se OpenCL può essere utilizzato per programmare le CPU e, sebbene sia possibile avere la portabilità della lingua di origine, la portabilità delle prestazioni è un problema. Ad esempio, un gran numero di thread su una GPU ha senso mentre su una CPU, avere un solo thread in esecuzione su un core è più efficace. Inoltre, gli strumenti di debug per le GPU stanno migliorando ma possono ancora essere complicati, e mentre è abbastanza fattibile che il core GPU su un'APU possa gestire tutte le attività GPGPU mentre la GPU discreta gestisce la grafica, la distribuzione esatta è difficile da prevedere.
  
  
• 00:50:00 In questa sezione, il relatore risponde a diverse domande relative al calcolo parallelo ed eterogeneo. Una delle domande è se OpenCL può essere utilizzato su GPU Nvidia. L'oratore conferma che Nvidia supporta OpenCL e che può funzionare su tutte le GPU della stessa famiglia di CUDA. Un'altra domanda è quanto sia diversa la GPU di fusione dalla GPU discreta, e la risposta è che sono molto simili, ma ci sono lievi differenze a seconda del processore e del design del silicio. L'oratore menziona anche che esiste un'estensione OpenCL per CPU e GPU di memoria condivisa, che consente zero copie tra i due. Alla domanda sull'emergere di OpenCL nello spazio mobile, il relatore conferma che tutti i principali fornitori sono coinvolti nello sviluppo di OpenCL per lo spazio mobile e l'implementazione sarà presto disponibile. Infine, il relatore confronta Fusion con Intel Sandy Bridge e afferma che sono simili nei progetti SOC e nei sistemi forti ed eterogenei.
  
  
• 00:55:00 In questa sezione, l'oratore discute i compromessi tra GPU MDS e CPU Intel e menziona che entrambi hanno i loro vantaggi. Toccano anche i modelli di programmazione e il modo in cui sia CUDA che OpenCL hanno il supporto della CPU. Il relatore prosegue parlando di applicazioni che potrebbero trarre vantaggio da questa tecnologia, come il data mining, l'elaborazione delle immagini e l'accelerazione di sistemi basati sulla fisica e sull'intelligenza artificiale. Menzionano anche che le tradizionali applicazioni di supercalcolo potrebbero trarre vantaggio dall'accelerazione di operazioni come la moltiplicazione di matrici. Il relatore conclude affermando la propria convinzione nell'emergere di questi sistemi eterogenei e su come daranno forma al futuro dell'informatica.
  
  
• 01:00:00 In questa sezione, il relatore discute i progressi compiuti nel calcolo parallelo ed eterogeneo, in particolare in termini di nuove architetture come Sandy Bridge di Intel. Tuttavia, manca ancora una risposta completa alla domanda sul modello di programmazione. Aziende come AMD e Intel hanno aperto la strada, ma si prevede che i progressi continueranno a essere fatti nel tempo.