Heterogeneous Queuing: l'approccio di AMD alla programmazione di CPU e GPU

[digieffe]

Originariamente inviato da AleLinuxBSD

Mantengo alcune perplessità e dubbi sull'argomento derivanti dal fatto che l'approccio indicato per migliorare l'efficienza di elaborazione si baserà su driver che aggirano il SO in maniera ancora più pesante di quanto già avviene oggi giorno.

Spe...

Dalla presentazione amd risulta che non si passerà dai drivers per questo tipo di utilizzo, né dal s.o. ma l'applicazione parlerà direttamente con la gpu, la quale in modo hardware (e non software) analizzerà i task presentati dall'applicazione e li eseguirà (come se fosse una un altra cpu), da ciò ne consegue meno carico...

Penso anche che l'approccio che presenterà Nvidia con maxwell anche se diverso debba in un modo o nell'altro rientrare in questi canoni.


@Paul Guru: approfitto di questo post per ricordarti che attendo una risposta.

[AleLinuxBSD]

Penso che la tua interpretazione sia scorretta dato che deve per forza esistere un layer software su cui le applicazioni vanno a pescare per comunicare in via privilegiata con il resto del sistema.
Che poi certe funzionalità siano gestite direttamente in hardware piuttosto che in software conta relativamente poco rispetto alle potenziali problematiche di sicurezza e di stabilità che sono in grado di provocare al livello potenziale.

[XFer]

L'idea è affascinante e senz'altro, da un punto di vista architetturale, ha moltissimo senso.

Però mi pare che nessuno dei produttori stia veramente affrontando il nodo cruciale: il supporto da parte degli sviluppatori.

Io mi ritrovo spesso a programmare in situazioni dove macinare più calcoli sfruttando multicore, unità vettoriali e GPU farebbe comodo.
Però mi scontro con problemi che non sono tanto architetturali, quanto di tool di sviluppo!
Chiunque programmi (sviluppare != usare applicazioni già pronte) in ambiente HPC sa che non esiste un modo semplice di sfruttare risorse hardware diverse dal classico single-core della CPU.
Non ci sono semplici opzioni da configurare nell'ambiente di sviluppo per rendere il codice "compatibile" con multicore, SIMD e processori grafici.

Chi vuole provare a sfruttare la potenza di CPU e GPU moderne deve affrontare le forche caudine di OpenMP, OpenCL, CUDA o DirectCompute, tutti con i propri pro e contro, tutti reciprocamente incompatibili (a livello di codice scritto).

Mi aspetterei che AMD, ma anche Intel, NVidia e la stessa ARM, anziché cercare di spingere i propri strumenti software ed estensioni più o meno proprietarie e più o meno difficili da usare, collaborassero con i principali sviluppatori di COMPILATORI per mettere a disposizione degli sviluppatori strumenti in grado di ottimizzare lo stesso identico codice automaticamente per multicore, unità SIMD, GPU.
Senza che lo sviluppatore debba studiarsi nuovi linguaggi, nuove estensioni, nuovi paradigmi di sviluppo.

Così sì, che i vantaggi di queste nuove architetture diventeranno davvero a beneficio di tutti, non solo di poche grandi aziende che hanno team di sviluppo enormi con speciali contratti di supporto da parte dei produttori di hardware.

Sì, è un po' uno sfogo, abbiate pazienza. :-)

[digieffe]

Originariamente inviato da AleLinuxBSD

Penso che la tua interpretazione sia scorretta dato che deve per forza esistere un layer software su cui le applicazioni vanno a pescare per comunicare in via privilegiata con il resto del sistema.
Che poi certe funzionalità siano gestite direttamente in hardware piuttosto che in software conta relativamente poco rispetto alle potenziali problematiche di sicurezza e di stabilità che sono in grado di provocare al livello potenziale.

No!
non è la mia interpretazione sono le slide di amd (huma, hsail, ecc).
Sto cercando le slide, posterò il link, se poi fai prima tu è meglio.

In ogni caso, la logica è questa: si tratta di un altra "cpu" chiamata gpu, per far girare un software su una cpu non interviene alcuno strato software, né il driver (questo può gestire il thermal ecc, ma non l'esecuzione del software)

[AleLinuxBSD]

Originariamente inviato da XFer

Mi aspetterei che AMD, ma anche Intel, NVidia e la stessa ARM, anziché cercare di spingere i propri strumenti software ed estensioni più o meno proprietarie e più o meno difficili da usare, collaborassero con i principali sviluppatori di COMPILATORI per mettere a disposizione degli sviluppatori strumenti in grado di ottimizzare lo stesso identico codice automaticamente per multicore, unità SIMD, GPU.
Senza che lo sviluppatore debba studiarsi nuovi linguaggi, nuove estensioni, nuovi paradigmi di sviluppo.

Direi che è qualcosa di impossibile, nonostante almeno Amd, e questo va riconosciuto, si stia quanto meno sforzando di proporre la sua soluzione come "aperta".
Nonostante gli standard in teoria dovrebbero aiutare in quanto mascherano funzionalità comuni per favorire la maggiore semplicità di scrittura nonché l'uso di sistemi diversi.
Al livello di programmazione parallela, perché di questo si tratta, la cosa più complicata risulta il debug dell'applicativo nonché l'esigenza di stravolgere, spesso e volentieri, interi algoritmi, per potersi avvantaggiare realmente delle potenzialità dell'hardware.
E queste cose non potranno mai essere automatizzate.
Certo esistono soluzioni che tendono a semplificare un po' la faccenda ma alla fine sono pagliativi incapaci di andare a fondo e quindi di scarsa utilità.

[digieffe]

Originariamente inviato da XFer

L'idea è affascinante e senz'altro, da un punto di vista architetturale, ha moltissimo senso.

Però mi pare che nessuno dei produttori stia veramente affrontando il nodo cruciale: il supporto da parte degli sviluppatori.

Io mi ritrovo spesso a programmare in situazioni dove macinare più calcoli sfruttando multicore, unità vettoriali e GPU farebbe comodo.
Però mi scontro con problemi che non sono tanto architetturali, quanto di tool di sviluppo!
Chiunque programmi (sviluppare != usare applicazioni già pronte) in ambiente HPC sa che non esiste un modo semplice di sfruttare risorse hardware diverse dal classico single-core della CPU.
Non ci sono semplici opzioni da configurare nell'ambiente di sviluppo per rendere il codice "compatibile" con multicore, SIMD e processori grafici.

Chi vuole provare a sfruttare la potenza di CPU e GPU moderne deve affrontare le forche caudine di OpenMP, OpenCL, CUDA o DirectCompute, tutti con i propri pro e contro, tutti reciprocamente incompatibili (a livello di codice scritto).

Mi aspetterei che AMD, ma anche Intel, NVidia e la stessa ARM, anziché cercare di spingere i propri strumenti software ed estensioni più o meno proprietarie e più o meno difficili da usare, collaborassero con i principali sviluppatori di COMPILATORI per mettere a disposizione degli sviluppatori strumenti in grado di ottimizzare lo stesso identico codice automaticamente per multicore, unità SIMD, GPU.
Senza che lo sviluppatore debba studiarsi nuovi linguaggi, nuove estensioni, nuovi paradigmi di sviluppo.

Così sì, che i vantaggi di queste nuove architetture diventeranno davvero a beneficio di tutti, non solo di poche grandi aziende che hanno team di sviluppo enormi con speciali contratti di supporto da parte dei produttori di hardware.

Sì, è un po' uno sfogo, abbiate pazienza. :-)

Tu in cosa sviluppi e con quale ambiente per questi problemi di calcolo?

I cambiamenti saranno negli strumenti di sviluppo, es: java 8 avrà un supporto iniziale e java 9 completo, il tutto senza scrivere granché di codice specifico!

le opzioni le stanno già integrando, vedi hsail di amd (che si interpone).
questa è solo una slide http://electronicdesign.com/site-fil...-Migration.jpg, appena trovo, posto tutto

http://developer.amd.com/wordpress/m...utionStack.png
in questa immagine si vede che non passa né i driver né i sistema operativo.

se ti riesce vedi come è strutturato hsail.

nessuno sfogo ti capisco perfettamente.

[XFer]

No, non è affatto impossibile: se tutti la pensassero come te, staremmo freschi!
Ma ti sei mai occupato veramente di programmazione HPC, o parli tanto per?

Sforzi verso l'implementazione di algoritmi di auto-vectorialization e auto-parallelization sono stati già fatti da team che collaborano, ad esempio, con il gruppo GNU che si occupa del GCC.
Speciali passaggi del compilatore analizzano il codice (normalissimo C senza estensioni proprietarie) alla ricerca di strutture, cicli e chiamate che possono essere automaticamente vettorializzate e/o parallelizzate.

Solo che questi ricercatori non hanno avuto alcun supporto, né economico né pratico, dai produttori.
Che preferiscono spendere montagne di soldi a pensare e pubblicizzare soluzioni proprietarie al problema (come Intel con i suoi compilatori speciali) per cercare di bloccare sviluppatori-chiave sui propri prodotti.

Ma non c'è mai vero progresso, fin quando i vantaggi non arrivano a tutti.

[XFer]

@digieffe: scusa, stavo rispondendo all'utente precedente

Sviluppo in ANSI C, ambienti Unix, Windows, Android (NDK) e sistemi embedded.
Riconoscimento automatico di pattern, cifratura, etc. (ambito sicurezza).

[digieffe]

trovate le slide: http://hsafoundation.com/hot-chips-2...ail-hsa-hsail/

Per capire rapidamente vi suggerisco di vedere le slide:
- in alto a sx le slide n. 3, 25, 26, 28;
- in alto a dx la 23;
- in basso a sx la 7, 8, 12
- in basso a dx 2, 3, 7, 15

[calabar]

Originariamente inviato da AleLinuxBSD

Che poi certe funzionalità siano gestite direttamente in hardware piuttosto che in software conta relativamente poco rispetto alle potenziali problematiche di sicurezza e di stabilità che sono in grado di provocare al livello potenziale.

Quali sarebbero questi problemi di sicurezza e stabilità di cui parli?
Guarda che si tratta solamente di considerare la GPU come un altro elemento di computazione.
Già ora le cpu lavorano con la parte int o con la FPU, e assegnano automaticamente i task alle diverse pipeline di calcolo.
Non mi pare affatto che questo crei problemi di sicurezza o di stabilità.

Originariamente inviato da PaulGuru

E quì è cascato l'asino.

Certo che ti fai sempre riconoscere.
Se avessi capito qualcosa dell'intervento che ho citato, e di conseguenza del mio, non avresti detto una cosa del genere.
Rileggi gli interventi, e vedrai che il filo del discorso era un altro, e che sei stato tu, a sproposito, a parlare di gaming.
Prima di dare dell'asino agli altri, dovresti riflettere un po'.

[digieffe]

Originariamente inviato da AleLinuxBSD

Direi che è qualcosa di impossibile, nonostante almeno Amd, e questo va riconosciuto, si stia quanto meno sforzando di proporre la sua soluzione come "aperta".
Nonostante gli standard in teoria dovrebbero aiutare in quanto mascherano funzionalità comuni per favorire la maggiore semplicità di scrittura nonché l'uso di sistemi diversi.
Al livello di programmazione parallela, perché di questo si tratta, la cosa più complicata risulta il debug dell'applicativo nonché l'esigenza di stravolgere, spesso e volentieri, interi algoritmi, per potersi avvantaggiare realmente delle potenzialità dell'hardware.
E queste cose non potranno mai essere automatizzate.
Certo esistono soluzioni che tendono a semplificare un po' la faccenda ma alla fine sono pagliativi incapaci di andare a fondo e quindi di scarsa utilità.

qualcosa già esiste, si chiama LLVM ed è opensource, ma ci sono anche altre soluzioni.
Forse non ci si avvantaggerà al 100% dell'hardware ma già poterlo sfruttare bene penso che sia qualcosa. Infondo è come scrivere in un linguaggio che non sia l'assembler: l'hardware non sarà mai sfruttato al 100%, ma cosa facciamo scriviamo in assembler? questi strumenti parallelizzano in automatico con complesse analisi... ora se non raggiungono il 100% va bene uguale, nel frattempo si può sfruttare avx e vga senza sbattersi
senza polemica: quali sarebbero i palliativi?

[AleLinuxBSD]

Originariamente inviato da XFer

No, non è affatto impossibile: se tutti la pensassero come te, staremmo freschi!

Premesso che direi di darti una calmata, e che una simile arroganza lascia soltanto trasparire la pochezza di una persona, se reputi che un sistema automatico per quanto sofisticato sia sufficiente a sfruttare davvero l'hardware, non soltanto riponi eccessiva fiducia in annunci e soluzioni più o meno miracolistiche, ma l'applicazione passiva di automatismi apre pure potenziali problematiche al livello di sicurezza del codice, dato che i vari passaggi, sostanzialmente risultano fuori controllo, avvenendo dietro le quinte, in modo fin troppo trasparente.
Comunque lascio spazio pure alle favolette dato che non ho la minima intenzione di farmi trascinare in discorsi fatti con questi toni.

Originariamente inviato da digieffe

quali sarebbero i palliativi?

Esempio soluzioni come OpenMP, per applicativi generici, che rimane interessante ma con diversi limiti.

Originariamente inviato da digieffe

Forse non ci si avvantaggerà al 100% dell'hardware ma già poterlo sfruttare bene penso che sia qualcosa.

Certamente ma il punto è che qui parliamo di aggirare il kernel per comunicare direttamente con l'hardware, agire in modo privilegiato su componenti di sistema così critici dovrebbe dare pensiero.
Gli automatismi sono utili, aiutano e tutto, però non sono la panacea di tutti i mali.

[XFer]

@digieffe:

Sì, ma vedi che si appoggia sempre su OpenCL e C++ AMP?

Tra l'altro OpenCL si sta rivelando disastroso non solo per la complessità della scrittura del codice (non tanto dei kernel quanto delle chiamate da codice host), ma per le tante versioni dello standard solo parzialmente (e non coerentemente) implementate dai produttori di hardware, e dalla necessità, veramente assurda, di doversi installare vari SDK contemporaneamente per indirizzare, per dire, CPU Multicore Intel, CPU Multicore AMD, GPU Nvidia, GPU AMD.
Che, per inciso, è una ricetta sicura per incasinare qualsiasi IDE.

Hanno bellamente ignorato SimpleCL, un piccolo, intelligente uovo di Colombo che richiedeva solo un po' di finanziamento e supporto tecnico, e anche Graphite.

Risultato, perdo un sacco di tempo, ho il codice pieno di #ifdef, Makefile impossibili e un delirio con le runtime (esempio stupido stupido: certi Linux embedded supportano OpenMP a livello di compilazione, ma poi mancano le giuste shared libraries).

Insomma a me le innovazioni architetturali piacciono, sono pur sempre un ingegnere, però mi piacciono gli strumenti che le rendono facilmente sfruttabili anche dai poveri programmatori disgraziati che non lavorano in Apple o Adobe o EA. :-)

[PaulGuru]

Originariamente inviato da digieffe

Il discorso cpu limited l'ho iniziato io, ti ho risposto nel merito (lamentandomi pure di amd) e tu continui a divergere con altri? perché?

Forse non sono in grado di sapermi spiegare?
A tuo avviso il mio intervento è fazioso? ed i tuoi?

ovviamente se non mi risponderai [b]nel merito[b] sarà chiara la tua intenzione di disturbare!

Originariamente inviato da digieffe

@Paul Guru: approfitto di questo post per ricordarti che attendo una risposta.

Nell'altro thread hai detto esplicitamente senza troppi giri di parole che APU con HSA risponderà ad Intel lasciando intendere qualcosa di presumibilmente miracoloso.

Dicendo anche che avrebbe risolto i suoi limiti in gaming con questo HSA dicendo che avrebbe usato l'IGP interna per svolgere buona parte del lavoro della cpu e così invece abbiamo visto che non solo come avevo intuito non sarebbe stato possibile ma non c'è nemmeno un minimo di influenza a riguardo.

Il mio intervento non lo reputo fazioso, per me sono normali scambi di opinioni aldilà di un atteggiamento che reputo eccessivamente permaloso nei confronto degli utenti che han AMD, in pratica nessuno può criticare i prodotti AMD se non con i guanti di velluto e discorsi da galateo e a volte nemmeno quelli sono sufficienti.

Originariamente inviato da calabar

Certo che ti fai sempre riconoscere.
Se avessi capito qualcosa dell'intervento che ho citato, e di conseguenza del mio, non avresti detto una cosa del genere.
Rileggi gli interventi, e vedrai che il filo del discorso era un altro, e che sei stato tu, a sproposito, a parlare di gaming.
Prima di dare dell'asino agli altri, dovresti riflettere un po'.

Quando si usa l'espressione "CASCA L'ASINO" non si intende dare dell'asino a un altra persona, è un espressione che con cui si intende dire che viene smacherato l'inghippo o un punto debole di un discorso.
Ed è un espressione abbastanza usata. -> LEGGI

[XFer]

@AleLinuxBSD: tu dimostri solo un'incredibile ignoranza, oltra che arroganza.
Proprio non sai di cosa parli, risponderti mi farebbe solo perdere tempo.

[digieffe]

Originariamente inviato da XFer

No, non è affatto impossibile: se tutti la pensassero come te, staremmo freschi!
Ma ti sei mai occupato veramente di programmazione HPC, o parli tanto per?

Sforzi verso l'implementazione di algoritmi di auto-vectorialization e auto-parallelization sono stati già fatti da team che collaborano, ad esempio, con il gruppo GNU che si occupa del GCC.
Speciali passaggi del compilatore analizzano il codice (normalissimo C senza estensioni proprietarie) alla ricerca di strutture, cicli e chiamate che possono essere automaticamente vettorializzate e/o parallelizzate.

Solo che questi ricercatori non hanno avuto alcun supporto, né economico né pratico, dai produttori.
Che preferiscono spendere montagne di soldi a pensare e pubblicizzare soluzioni proprietarie al problema (come Intel con i suoi compilatori speciali) per cercare di bloccare sviluppatori-chiave sui propri prodotti.

Ma non c'è mai vero progresso, fin quando i vantaggi non arrivano a tutti.

yes
molti si affidano a LLVM che risulta notevolmente più avanti di gcc nella autovettorializzazione ed autoparallelizzazione ora si aggiunge anche amd.

Il blocco lo chiamano "lock in".

[digieffe]

Originariamente inviato da Bivvoz

Sembrerebbe che invece AMD abbia pensato anche agli sviluppatori, infatti metteranno a disposizione HSAIL un compilatore "universale".

Poi bisognerà vedere quanto sarà universale e quanto sarà pratico.
Io dei programmi li faccio ma mai a livello da pormi il problema del multicore, ecc. perché sono cose che non richiedono molta potenza di calcolo.
Sinceramente non mi sono mai informato su come sfruttare queste caratteristiche.

Da quanto ho capito HSAIL dovrebbe ricevere come input sorgenti in diversi linguaggi tra i più diffusi e restituire il compilato compatibile con HSA.
Questo vuole dire tutto e niente, perché non spiega se il sorgente deve avere già in qualche modo delle indicazioni per il multicore e il calcolo parallelo, magari compatibili con altri standard come openCL o se magicamente riconosce cosa è possibile parallelizzare e cosa no, cosa è meglio far gestire alla cpu e cosa alla gpu.

Altra cosa interessante di cui si ventilava l'ipotesi è che HSAIL possa compilare per piattaforme diverse, quindi in teoria compilando 1 solo sorgente con HSAIL (e magari qualche modifica minore segnalata dal compilatore stesso) potrebbe essere possibile compilare per Windows o per Linux, per x86 o per ARM e via dicendo.

Sinceramente tutto questo esula le mie competenze, riassumo solo quanto ho recepito

Per i partner non mi sbilancerei su Intel e Nvidia, ma ARM, Sony, Qualcomm e un sacco di altri fanno parte a loro volta della HSA Foundation, quindi se non sono completamente rincoglioniti favoriranno la diffusione di questa tecnologia (sempre se conveniente ovviamente)

compilatore intermedio "universale" (se non ricordo male, devo rivedere le slide) non prende in carico sorgenti
(a memoria) hsail riconosce automaticamente, è compatibile con opencl e decide automaticamente cosa è meglio per la cpu e per la gpu.

[XFer]

@digieffe
Sì, il lock-in tra l'altro avviene anche, in certi casi, con pratiche non proprio "limpide", ma questo è un altro discorso.
Comunque specie con l'avvento e la pervasività di dispositivi mobile ed embedded, ci vorrebbe che i produttori capissero l'importanza di strumenti open source e trasversali. Per lo sviluppo inteso anche come debug ed emulazione (chiunque abbia provato a risolvere problemi in un kernel OpenCL, magari senza la possibilità di installare tutti i possibili dispositivi su cui dovrà girare, sa cosa intendo).

Con i mezzi che hanno, vorrei tanto che si mettessero d'accordo su una singola estensione al linguaggio (se proprio serve) e la implementassero tutti, fornendo in open source gli SDK necessari e supportando i team che lavorano a LLVM e soprattutto GCC (molto più diffuso e più facile da portare su nuove architetture).

[digieffe]

Originariamente inviato da AleLinuxBSD

Esempio soluzioni come OpenMP, per applicativi generici, che rimane interessante ma con diversi limiti.


Certamente ma il punto è che qui parliamo di aggirare il kernel per comunicare direttamente con l'hardware, agire in modo privilegiato su componenti di sistema così critici dovrebbe dare pensiero.
Gli automatismi sono utili, aiutano e tutto, però non sono la panacea di tutti i mali.

openmp e compagnia: non avevo capito il riferimento.

Non si "dovrebbe" passare in modalità privilegiata, questo è quanto capisco dalle slide. purtroppo non si sanno i dettagli della implementazione, dalle slide intuisco che abbiano una soluzione lievemente più complessa di una fpu.

[XFer]

@bivvoz

HSAIL vuole kernel OpenCL e chiamate host OpenCL (o C++ AMP).
Dopodiché capisce se è meglio indirizzare a device_CPU o device_GPU, eventualmente anche "massaggiando" un po'.
Ma non è in grado di riconoscere automaticamente se, all'interno di un comune algoritmo ANSI C (pensiamo alla montagna di letteratura e codice per BLAS o CV, fluidodinamica, simulazione strutturale ad elementi finiti, pattern matching etc.), ci sono parti vettorializzabili, CPU-parallelizzabili, GPU-parallelizzabili.

Insomma è un altro preprocessor che si mette tra OpenCL (che è un mezzo incubo di per sé) e il binario.
Sforzo apprezzabile in sé, ma poco pratico per lo sviluppatore finale, specie per piccoli team. Anche perché, appunto, darebbe benefici solo per architetture HSA, che sono e saranno solo una percentuale del totale.