Link alla notizia: http://www.hwupgrade.it/news/skvideo/heterogeneous-queuing-l-approccio-di-amd-alla-programmazione-di-cpu-e-gpu_49297.html

AMD prosegue l'evoluzione delle proprie architetture APU annunciando hQ, Heterogeneous Queuing, per l'ottimale gestione delle risorse di CPU e GPU in modo parallelo ed efficiente

Click sul link per visualizzare la notizia.

ennesimo presunto miracolo di AMD

mi chiedo ancora come diano la possibilità a gente come te di scrivere sui vari forum in rete...

adesso spiegami quali sono i presunti miracoli che AMD ha promesso negli ultimi 10 anni??? (a parte le prestazioni che doveva avere Bulldozer grazie ad un reparto marketing da prendere a calci in cul*)

...poi lo fanno tutti, lo fece anche ai suoi tempi la cara Intel nel pubblicizzare i suoi P4, lo ha fatto nvidia con fermi e la serie 400... cosa dovevano/devono fare, dirci che fanno schifo i processori o le gpu che fanno?

Quindi chi critica AMD non ha diritto di parlare secondo te, bene lo terremo in considerazione.
Non ci tengo a fare polemica ma dopo quasi 9 anni di delusioni e continue e promesse mai mantenute e dichiarazioni false a scopo di temporeggiare i possibili acquirenti Intel mi pare più che giustificato dare un peso scarsino alle parole di AMD.

A partire dalle proposte Phenom I che AMD ha temporeggiato per oltre un anno dall'uscita di Conroe prendendo in giro tutti e di cui mostrava presunte slide poi rivelatosi un flop, all'uscita di R600, alla rivelazione di Bulldozer con tanto di slide falsificate del Cinebench fino all'eliminazione di Steamroller FX e del socket AM3+ che penso alcuni abbiano anche comprato con la speranza di farsi un update a quest'ultimo.

Nvidia e Intel con Fermi e P4 agli esordi erano superiori, Intel fino a che non è arrivato Athlon64 era superiore agli XP, Nvidia con Fermi era la GPU più potente del mercato, quindi per entrambi la decenza è sempre stata raggiunta, cosa che manca ad AMD da 9 anni.

HSA dipenderà in primis dai programmatori più che da AMD ed ho dei dubbi in merito alla sua diffusione in quanto AMD rappresenta circa il 30% del market share delle cpu desktop. Sono alquanto scettico quando sento parlare per l'ennesima volta di miracolo prestazionale in grado di battere Intel, ma poi in quali applicazioni, in quante e soprattutto in che misura visto che APU rispetto a FX parte già con la metà dei cores e niente L3.

Non sto assolutamente dicendo questo, si DEVE criticare AMD, ma tu sei un troll e un flamer di prima categoria è questo che dico...
Phenom I avevo proprio un bug corretto con l'ottimo phenomII, R600 è di ATI mica di AMD, Bulldozer a parte le basse prestazioni è una architettura che nasce per questo scopo, per il progetto che verrà, non te lo voglio più ripetere!
...Fermi serie 400 scaldava e consumava uno sproposito in rapporto alle performance, e non parliamo di 60° e 100/150Watt come di Bulldozer, ma di 90° e 300/400watt... ma P4 era peggio del P3, ma cosa dici???
detto questo puoi stare anche qua ad inquinare i post le news i thread di AMD, già che ieri andavi in mezza rete a scrivere le stesse cose 10 volte... :doh:
Mi stai dando del troll perchè ho criticato anche in passato AMD o solo per screditare chi non la pensa come te ?
E ammettendo che uno abbia in passato trollato non può più dire nulla perchè ogni cosa che dice è automaticamente un trollaggio ?

P4 era inferiore a P3 a pari clock, ma P4 era famoso appunto per la frequenza molto più alta e fino al 2003 dominava il mercato visto che gli AthlonXP erano inferiori o vuoi negarlo ?

Fermi 300-400W ? Parli per esperienza o per sentito dire ?
Io ho avuto una GTX 470 Gainward prima e la GTX 570 Zotac dopo ( entrambe vendute quì ) entrambe reference Nvidia, e prima una Sapphire HD5870 te invece quale hai avuto per affermare ciò ?

A parte il fatto che una scheda single GPU non può consumare 400W, i loro TDP dichiarati erano relativamente 215 e 250W, e la 470 aveva solo 2 connettori da 6pin mentre la 480 1*6 + 1*8 come oramai quasi tutte le attuali VGA di quella fascia.
Per giunta al tempo avevo tutto montato su un Enermax MODU82+ da 525W.

Data la difficoltà che si ha oggi per programmare su GPU, è indubbio che un approccio atto a semplificare è un'ottima strada da seguire.

Sono curioso si vedere come questo di concretizzerà in termini di ambiente di sviluppo e in che modo lavorerà con l'hardware quando l'integrazione che AMD ha in mente sarà stata sviluppata (ossia quando CPU e GPU non saranno più due entità distinte e distinguibili all'interno del chip).

Mi chiedo anche come questo influenzerà lo sviluppo della FPU, se verrà di fatto sostituita dagli elementi della GPU o sarà ancora necessaria per i compiti non molto parallelizzati, i task "seriali" di cui parlano le slide.

@PaulGuru
Credo che il tuo problema sia l'atteggiamento (che trovo francamente incomprensibile, ma del resto il tifo non è raziocinio) da "tifoso" Intel.
E lo dimostri di continuo, cercando nelle discussioni non di apprende e arricchirle con il tuo contributo, ma difendendo continuamente Intel anche di fronte all'evidenza. E ti impunti nelle tue argomentazioni, anche quando altri più competenti di te stanno solo cercando di spiegarti dove e perchè sbagli.
AMD sicuramente non è esente da critiche (anzi), ma tu col tuo primo post non hai scritto una critica, hai fatto una sparata senza argomentazioni.
Non è un problema di cosa dici, ma di atteggiamento.

Mi stai dando del troll perchè ho criticato anche in passato AMD o solo per screditare chi non la pensa come te ?
E ammettendo che uno abbia in passato trollato non può più dire nulla perchè ogni cosa che dice è automaticamente un trollaggio ?

Uno è liberissimo di dire ed esprimersi come vuole, ma se inzia e finisce con un commento del genere....

ennesimo presunto miracolo di AMD

....come puoi tu pretendere che non lo si traduca come un tentativo di flame?.
Ripeto, sei libero di scrivere ciò che vuoi ma come sei libero tu di farlo lo sono anche altri nel contestare ciò che affermi, che sia per i modi che per i concetti. Nei forum così funziona. Se non ti sta bene evita o per lo meno cerca di esprimerti in un modo migliore.

Ok forse l'atteggiamento è quello che è però è evidente che ad ogni commento contro AMD mi venga dato del fan Intel, eppure ho più volte espresso il mio disappunto sulla mia cpu, il fatto è che mi ritrovo a non avere una valida alternativa, quindi è normale che vada dire certe cose in quanto secondo la mia esperienza AMD ha deluso per 9 anni di fila senza azzeccarne mezza e quindi ho smesso di credere a ciò che riferisce.

Questa tecnologia ammesso che funzioni non sarà minimamente ad effetto immediato, ci vorrà un del tempo affinchè venga presa in considerazione e collaudata e se parliamo di anni questo vorrà dire che quando sarà veramente operativa le APU che stan per uscire saranno già vecchie e il suo competitor potrebbe avere anch'egli qualcos'altro da mostrare, quindi attualmente la situazione rimane e rimarrà quella, ovvero che io e tutti gli altri saremo costretti a stare con Haswell fino al 2015.

Per quanto riguarda la possibile sostituzione della FPU della CPU detta da te Calabar sarebbe anche interessante ma devi ammettere che adesso stai azzardando anche te delle ipotesi mooooooolto lontane, visto che non ne è stato fatto minimamente cenno.

Mi stai dando del troll perchè ho criticato anche in passato AMD o solo per screditare chi non la pensa come te ?
cut

forse perche' in ogni news intervieni sempre e fuori luogo :D

cut

Questa tecnologia ammesso che funzioni



:D che vuol dire ammesso che funzioni? :D :D

non sarà minimamente ad effetto immediato, ci vorrà un del tempo affinchè venga presa in considerazione e collaudata e se parliamo di anni questo vorrà dire che quando sarà veramente operativa le APU che stan per uscire saranno già vecchie e il suo competitor potrebbe avere anch'egli qualcos'altro da mostrare, quindi attualmente la situazione rimane e rimarrà quella, ovvero che io e tutti gli altri saremo costretti a stare con Haswell fino al 2015.
cut

vorse volevi dire completamente sfruttata.
perche' amd si messa in moto perche' sia sfruttata subito, vedi windows 8.1 che tra l'altro girera' (non so se lo stesso) anche nella console di windows, che e' un apu con huma. sta collaborando oltre che nei giochi con adobe ecc.
inoltre c'e' interesse in questa tecnologia anche nel mondo table e smartpphone, dove le future cpu saranno apu 64 bit otto core con huma (non necessariamente amd naturalmente, ma qualcomm collabora al proggetto e anche amd fa apu arm).

:D che vuol dire ammesso che funzioni? :D :D

vorse volevi dire completamente sfruttata.
perche' amd si messa in moto perche' sia sfruttata subito, vedi windows 8.1 che tra l'altro girera' (non so se lo stesso) anche nella console di windows, che e' un apu con huma. sta collaborando oltre che nei giochi con adobe ecc.
inoltre c'e' interesse in questa tecnologia anche nel mondo table e smartpphone, dove le future cpu saranno apu 64 bit otto core con huma (non necessariamente amd naturalmente, ma qualcomm collabora al proggetto e anche amd fa apu arm).
Bene quindi quando uscirà Kaveri mi aspetto di vedere notevoli incrementi negli applicativi di conversione e rendering nell'ordine del +200-300%.

sta collaborando oltre che nei giochi con adobe ecc.

Che vuol dire Adobe ecc ecc ?
Se sono veramente così tante le SH con cui stanno collaborando non riesci che a trovarmi solo il nome di Adobe ( che fra l'altro usa già l'accelerazione grafica, quindi avrò un netto incremento col Flashplayer e Java ? utilissimo ) ? Tirami giù una bella lista folta visto che sono così tante.

Huma è un altra storia nei giochi, quì si sta parlando dei possibili vantaggi che si avrà nel calcolo eterogeneo e ancora non me li hai saputi elencare e la news a riguardo guardacaso è molto vaga, non dice espressamente in quali ambiti e in quali applicativi ci sarà il vantaggio ed in che ordine sarà.


Perche' amd si messa in moto perche' sia sfruttata subito, vedi windows 8.1 che tra l'altro girera' (non so se lo stesso) anche nella console di windows, che e' un apu con humaCosa centra il fatto che 8.1 gira con APU Huma ? Le APU girano anche su Win7 e probabilmente anche precedenti.
Sono io ad essere fuori luogo o ti è sfuggito che si sta parlando di HSA e non di Huma ? O per te sono la stessa cosa ?

Bene quindi quando uscirà Kaveri mi aspetto di vedere notevoli incrementi negli applicativi di conversione e rendering nell'ordine del +200-300%.
Forse non da subito, il software di solito è sempre più lento dell'hardware, ma la strada da intraprendere è quella.
E in questo caso non bisogna solo implementare, ma anche affinare.

Cosa centra il fatto che 8.1 gira con APU Huma ? Le APU girano anche su Win7 e probabilmente anche precedenti.
Sono io ad essere fuori luogo o ti è sfuggito che si sta parlando di HSA e non di Huma ? O per te sono la stessa cosa ?
HUMA sta alla base dell'implementazione AMD di HSA.
Quello che intendeva è che semplicemente l'approccio HSA allo sviluppo software potrebbe essere molto diffuso in futuro, grazie alle APU delle consolle e all'interessamento dei vari membri appartenenti al consorzio, tra cui parecchie realtà del mondo mobile, che oggi hanno una notevole importanza.

Bene quindi quando uscirà Kaveri mi aspetto di vedere notevoli incrementi negli applicativi di conversione e rendering nell'ordine del +200-300%.

...

Huma è un altra storia nei giochi, quì si sta parlando dei possibili vantaggi che si avrà nel calcolo eterogeneo e ancora non me li hai saputi elencare e la news a riguardo guardacaso è molto vaga, non dice espressamente in quali ambiti e in quali applicativi ci sarà il vantaggio ed in che ordine sarà.

- IMHO non ci sarà nessun incremento del 200-300% nei lavori a grana grossa ma solo un incremento nella parallelizzazione cpu e gpu (riducendo di fatto il cpu limited, in quanto la gpu sarà più autonoma) ovviamente un un ragionevole incremento di performance, invece, forse, nei lavori a grana fina dove l'interazione cpu-gpu può essere altissima ci potrebbero essere elevati incrementi di performance.

- Prossimamente non si potrà prescindere da huma ed il suo futuro concorrente a memoria unficata di Nvidia (maxwell), ergo tutti i programmi bene o male dovranno adottarlo, resta il dubbio se i due standard saranno compatibili ecc.

HUMA sta alla base dell'implementazione AMD di HSA.
Quello che intendeva è che semplicemente l'approccio HSA allo sviluppo software potrebbe essere molto diffuso in futuro, grazie alle APU delle consolle e all'interessamento dei vari membri appartenenti al consorzio, tra cui parecchie realtà del mondo mobile, che oggi hanno una notevole importanza.Huma è una parte dell'HSA, e viene per di più usata su console per eliminare il collo di bottiglia relativo alla quantità di RAM utilizzabile e quindi è un discorso relativo all'efficienza sulla condivisione della memoria, mentre per HSA in toto si intende appunto il calcolo eterogeneo, in che ambito verrà applicato e in che misura ?
Benefici in ambito mobile ? Si ok ma stiamo parlando di desktop, il mobile di certo conta poco o niente sotto il profilo performance.

nei lavori a grana fina dove l'interazione cpu-gpu può essere altissima ci potrebbero essere elevati incrementi di performance.Tipo ?

- IMHO non ci sarà nessun incremento del 200-300% nei lavori a grana grossa ma solo un incremento nella parallelizzazione cpu e gpu (riducendo di fatto il cpu limited, in quanto la gpu sarà più autonoma) ovviamente un un ragionevole incremento di performance, invece, forse, nei lavori a grana fina dove l'interazione cpu-gpu può essere altissima ci potrebbero essere elevati incrementi di performance.

Domandina a tutti e 2, anzi a tutti e 3 ma su carlotto nemmeno ci spero, in che modo diminuirebbe il CPU limited nei giochi in presenza di una VGA discreta ?

....
Tipo ?



Domandina a tutti e 2, anzi a tutti e 3 ma su carlotto nemmeno ci spero, in che modo diminuirebbe il CPU limited nei giochi in presenza di una VGA discreta ?
si possono abbattere, o addirittura eliminare, i tempi per passare al "kernel mode" per poi tornare all' "user mode", anche si riduc./elimin. i tempi per esecuzione del driver, nonché del look-up dei dati se ne può prendere carico la gpu. Tutte queste operazioni se molto frequenti possono sprecare molta cpu, è per questo che ho scritto a grana fina. Se i game engine ed il gioco stesso fanno poche chiamate, allora l'offload della cpu sarà minimo, se fanno molte chiamate sarà più sostanzioso. Purtroppo non ho né il codice, né il profiling dei game engine e neanche la documentazione tecnica di amd quindi, non ti posso fare una reale quantificazione. Azzardando, posso ipotizzare da pochi punti percentuali fino, anche, a ciò che hai scritto tu, ma tutto dipende dal contesto delle chiamate, come è stata scritta l'applicazione, come lavorano i drivers, ecc


EDIT: anche io ho una certa delusione nei confronti di amd, non per ciò son particolarmente sfiduciato. Attendiamo e vediamo cosa sarà poi giudicheremo. E poi nella storia amd non ha fatto sempre male, anzi quando ha in qualche modo potuto fare la concorrenza ad intel, quest'ultima si è dovuta smuovere. Solo un esempio: ad oggi se non fosse per amd, staremmo ancora con PIV 32bit con ram >4Gb ma ad estensione p.a.e. e la fascia 64 bit relegata all'itanium...

Benefici in ambito mobile ? Si ok ma stiamo parlando di desktop, il mobile di certo conta poco o niente sotto il profilo performance.
Benefici in ogni ambito.
In ambito mobile perchè certi tipi di elaborazioni sono più efficienti su GPU, e questo porterebbe ad un risparmio di batteria. Non solo, usando l'hardware a disposizione riduci la necessità di usare hardware più potente, con un risparmio di spazio, transistor e quindi consumi.
In ambito desktop perchè certi tipi di elaborazione sono molto più veloci se fatti dalla GPU, quindi un incremento prestazionale notevole utilizzando l'hardware a disposizione.

Domandina a tutti e 2, anzi a tutti e 3 ma su carlotto nemmeno ci spero, in che modo diminuirebbe il CPU limited nei giochi in presenza di una VGA discreta ?
Per la questione CPU-limited non si riferiva all'ambito gaming, ma al fatto che oggi le elaborazioni sulla GPU devono essere pilotate dalla CPU, con conseguente carico di lavoro su quest'ultima. Eliminare questo ulteriore carico di lavoro dalla CPU significa avere più risorse libere a disposizione e di conseguenza ridurre il fenomeno del CPU-limited.

Per i giochi sicuramente puoi avere un notevole miglioramento grazie a HUMA, per i motivi di cui abbiamo già abbondantemente discusso nella news in cui se ne era parlato (in particolare evitare l'overhead sul bus di memoria ed evitare operazioni di copia/spostamento dei dati).

Per la questione CPU-limited non si riferiva all'ambito gaming, ma al fatto che oggi le elaborazioni sulla GPU devono essere pilotate dalla CPU, con conseguente carico di lavoro su quest'ultima. Eliminare questo ulteriore carico di lavoro dalla CPU significa avere più risorse libere a disposizione e di conseguenza ridurre il fenomeno del CPU-limited. E quì è cascato l'asino.

E quì è cascato l'asino.

scusami ti ho risposto così:
http://www.hwupgrade.it/forum/showpost.php?p=40153520&postcount=17

allora è vero quando scrivono che cerchi il flame...
mi dispiace io non avevo di te la considerazione che scrivono in giro ma a quanto pare hanno ragione.

ma dimmi, quando mai si è parlato di gaming nelle news relative ad huma o hq come oggi?

...ma poi, gira tutto intorno al gaming? il PC è fatto apposta per fare n-mila altre cose, il gaming è una minima parte e nemmeno fa parte del dove mira questo progetto "apu"
...come concetto è inteso come evoluzione della cpu come oggi la conosciamo (x86) in una altra cosa (ibrida), allora non vedrai fare +10% di IPC da un anno all'altro, ma +100/200% magari...
ma nessuno ha la sfera di cristallo per dirti quando avverrà e sempre se avverrà, non ci rimane che attendere ;)
Si parlava di CPU limited quindi dove pensavi che ricadesse il discorso scusa ?

Adesso non cerchiamo di deviare il discorso, si buona parte dell'uso indispensabile di un PC è il gaming ovviamente e non capisco perchè ogni volta bisogna trovare scuse per mascherarlo, denigrarlo o postare recensioni o video selezionati, solo perchè non è un punto a favore per AMD mentre quando c'era l'Athlon64 si parlava solo di quello.

Se AMD fosse stato inferiore in tutto e per tutto a Intel ma superiore solo nel gaming quì stai pur certo che l'avremmo montata quasi tutti, anzi per certi versi il fallimento della serie di punta AMD è stato decretato proprio dal comportamento con i giochi.

Si parlava di CPU limited quindi dove pensavi che ricadesse il discorso scusa ?

...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!

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.

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.

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.

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. :-)

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)

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à.

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-files/electronicdesign.com/files/uploads/2013/09/89831_fig2sm-HSA-Migration.jpg, appena trovo, posto tutto

http://developer.amd.com/wordpress/media/2012/10/HSASolutionStack.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.

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.

@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).

trovate le slide: http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-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

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à.

E quì è cascato l'asino.
Certo che ti fai sempre riconoscere. :rolleyes:
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'.

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?

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. :rolleyes:

quali sarebbero i palliativi?
Esempio soluzioni come OpenMP, per applicativi generici, che rimane interessante ma con diversi limiti.

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.

@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. :-)

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 nel merito[b] sarà chiara la tua intenzione di disturbare!

[B]@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.


Certo che ti fai sempre riconoscere. :rolleyes:
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 (http://it.answers.yahoo.com/question/index?qid=20080306012004AAMSyoX)

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

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".

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.

@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).

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.

@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.

@digieffe:

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

Hanno bellamente ignorato SimpleCL, un piccolo, intelligente uovo di Colombo che richiedeva solo un po' di finanziamento e supporto tecnico, e anche Graphite.
dove dovrei vederlo?
nella slide che ho postato? se si, non indica che si appoggia ma che questi "sistemi" sono compatibili.

non conosco simplecl e graphite.


@tutti: perché non continuiamo la discussione dopo aver visto le slide?

Prima volevi un risposta e poi mi ignori ? :D

@digieffe
Sì dalle slide, in particolare la n.7 del gruppo in basso a destra.

Cito, non integralmente:

"HSA Parallel Execution Model:

Programmer supplies a kernel that is run on each work-item
Programmer specifies grid dimensions"

E' il classico approccio dei linguaggi paralleli, come OpenCL, C++ AMP, CUDA: scrivi un kernel per il parallel device in un linguaggio con certi costrutti (tipi di dato, definizione di grid etc.) e poi lo dai in pasto ad un compilatore specifico per la ISA in gioco.
Non per nulla, si fa esplicito riferimento, tra gli ambienti compilati (JVM a parte, insomma), a OpenCL e C++ AMP: per "rassicurare" in qualche modo gli sviluppatori che già li usano.
Tempo fa, il gruppo PGI (Portland) ha fatto una cosa molto simile, con precompilatore in vendita a circa 500 euro (l'ho anche provato).

Ma è un approccio che non mi trova d'accordo, lock-in, niente trasversalità (no Intel, no NVidia, no ARM almeno con certe IP integrate) etc. :-(

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.

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 (http://it.answers.yahoo.com/question/index?qid=20080306012004AAMSyoX)Intel? non mi pare di aver nominato intel negli ultimi giorni, tutt'alpiù nvidia.

Risolto i suoi limiti in ambito gamig?
Utilizzando l'ipg per svolgere buona parte del lavoro della cpu? (forse ho detto qualcosa di simile ma non questo)

in ogni caso, cortesemente mi riporteresti il mio post evidenziando le parti in questione, così ne chiariamo pacificamente? :)

in ogni caso non sono un fanboy di amd e nei thread amd sono molto critico.

@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).purtroppo ti capisco, purtroppo nel migliore dei casi non si mettono d'accordo nel peggiore cercano di fare "divide et impera".

@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.vorrei conoscere la tua opinione su hsa bolt, è nelle slide.

@PaulGuru:

Premetto che non sono un gran simpatizzante AMD negli ultimi tempi, anche se all'epoca degli Athlon mi avevano conquistato il cuore. :-)

Però è vero che un approccio di questo tipo (HSA con hUMA) può risolvere tanti colli di bottiglia, anche in ambito gaming. Sulla carta almeno!
Finché devi passare per una chiamata a sistema per far iniziare a lavorare una GPU, hai un ritardo orrendo. In certi casi il ritardo per la partenza del kernel è tale, da mangiarsi quasi interamente il guadagno in termini di velocità di elaborazione. Bypassare la chiamata a sistema (HSA) renderebbe la GPU utile anche per "piccoli" lavori che normalmente sarebbero inefficienti per il ritardo della partenza del kernel.
Inoltre le GPU lavorano male quando c'è branching. O il programmatore se ne fa carico ( :-( ) o la GPU dovrebbe poter chiamare la CPU quando ci sono parti del codice che non sono adatte a lei. Oggi non lo può fare (neanche nelle architetture integrate Intel, che pure sono quasi-hUMA), con HSA sì.

In più oggi devi spostare continuamente i dati tra memoria CPU e memoria GPU; è un'operazione lenta, sia perché anche in quel caso devi passare per una chiamata a sistema, sia perché il passaggio tramite PCIExpress penalizza le prestazioni rispetto all'accesso diretto a memoria.
Con hUMA risolvi il problema.

Che AMD abbia visto bene si capisce anche dal fatto che NVidia sta inserendo CPU ARM nelle sue prossime architetture GPU, per evitare questo ping-pong attraverso OS e PCI-Express tra CPU e GPU.

Poi sono d'accordo con te che tra il dire e il fare...!

Prima volevi un risposta e poi mi ignori ? :Dti ho risposto, è che ho un certo lag per via del multitasking al quale sono sottoposto.

@tutti: mi scuso con il ritardo con il quale sono costretto a rispondere, questo out of syncro può rendere i miei interventi meno logico :(

Ragazzi bella chiaccherata, un grazie a tutti e specialmente a digieffe, ora devo scappare.
Speriamo di vedere presto qualche ricaduta pratica di queste innovazioni architetturali.
Se non per i piccoli/medi team di sviluppo indipendenti, almeno per gli utenti finali (es.: il QuickSync di Intel si "vede" :-) ).
Almeno fornissero librerie runtime già ottimizzate, sarebbe qualcosa.
Con OS-X, ad esempio, Apple ha realizzato librerie runtime C e C++ che implementano già, in modo trasparente per utente e sviluppatore: multicore, vettorializzazione e in qualche caso esecuzione su GPU.
Anche quella è una strada, anche se meno attraente di un singolo kit SDK open source condiviso e implementato da tutti. :-)

@digieffe
Sì dalle slide, in particolare la n.7 del gruppo in basso a destra.

Cito, non integralmente:

"HSA Parallel Execution Model:

Programmer supplies a kernel that is run on each work-item
Programmer specifies grid dimensions"

E' il classico approccio dei linguaggi paralleli, come OpenCL, C++ AMP, CUDA: scrivi un kernel per il parallel device in un linguaggio con certi costrutti (tipi di dato, definizione di grid etc.) e poi lo dai in pasto ad un compilatore specifico per la ISA in gioco.
Non per nulla, si fa esplicito riferimento, tra gli ambienti compilati (JVM a parte, insomma), a OpenCL e C++ AMP: per "rassicurare" in qualche modo gli sviluppatori che già li usano.
Tempo fa, il gruppo PGI (Portland) ha fatto una cosa molto simile, con precompilatore in vendita a circa 500 euro (l'ho anche provato).

Ma è un approccio che non mi trova d'accordo, lock-in, niente trasversalità (no Intel, no NVidia, no ARM almeno con certe IP integrate) etc. :-(vedo ciò che mi posti, anche se ho la sensazione che non sia tutto così, purtroppo ho bisogno di rivedere le slide (che ho visto in settembre), può andar bene se rispondo più lentamente? continuerai a seguire il thread fino almeno domani


Edit: la mia sensazione (ricordi non chiari) era errata, applicavo mentalmente l'autoparallelizzazione e autovettorializzazione di llvm ad hsail.
sarà necessario capire a che punto di maturità è llvm e come lo integreranno in questa soluzione.

Leggerò le slide con comodo (ci vorrà qualche oretta), ma la cosa sembra a pelo molto interessante :D

Mi chiedevo una cosa, ma a sto punto se è così facile come dicono parlare direttamente con la GPU si potrebbe fare a meno dei driver?

Un ipotetico OS futuro potrebbe far disegnare le finestre direttamente alla GPU? A me pare possibile... e sembra, in effetti, logico :sofico:

Una nota LLVM di per sè è una Macchina Virtuale a basso livello quindi cosa MOLTO diversa da GCC, la cosa più simile a GCC in quel mondo è LCC che però al momento non è finito e si preferisce usare un loro fork dello stesso GCC che, però non compila codice macchina, ma bitcode (sì la 'y' manca volutamente :D ).

Con LLVM, però, puoi compilare JAVA, C, C++ e potenzialmente qualsiasi cosa... è persino banale scrivere il proprio linguaggio di programmazione[1] e sospetto questa sia la via seguita da AMD... non programmerai in C/C++, ma in qualcosa di molto simile e sarà poi LLVM a farsi il c*lo :ciapet:

Egoisticamente dobbiamo sperare che AMD abbia fatto il colpaccio come con X64 e che nonna Intel sia costretta a seguirla con la coda tra le gambe :Prrr:

[1] Vedi il toy language "Kaledoscopie" ci ho capito persino qualcosa io e mi è persino venuta voglia di cimentarmici :read:

Leggerò le slide con comodo (ci vorrà qualche oretta), ma la cosa sembra a pelo molto interessante :D

Mi chiedevo una cosa, ma a sto punto se è così facile come dicono parlare direttamente con la GPU si potrebbe fare a meno dei driver?

Un ipotetico OS futuro potrebbe far disegnare le finestre direttamente alla GPU? A me pare possibile... e sembra, in effetti, logico :sofico:

Una nota LLVM di per sè è una Macchina Virtuale a basso livello quindi cosa MOLTO diversa da GCC, la cosa più simile a GCC in quel mondo è LCC che però al momento non è finito e si preferisce usare un loro fork dello stesso GCC che, però non compila codice macchina, ma bitcode (sì la 'y' manca volutamente :D ).

Con LLVM, però, puoi compilare JAVA, C, C++ e potenzialmente qualsiasi cosa... è persino banale scrivere il proprio linguaggio di programmazione[1] e sospetto questa sia la via seguita da AMD... non programmerai in C/C++, ma in qualcosa di molto simile e sarà poi LLVM a farsi il c*lo :ciapet:

Egoisticamente dobbiamo sperare che AMD abbia fatto il colpaccio come con X64 e che nonna Intel sia costretta a seguirla con la coda tra le gambe :Prrr:

[1] Vedi il toy language "Kaledoscopie" ci ho capito persino qualcosa io e mi è persino venuta voglia di cimentarmici :read:I driver ci saranno sempre ma per l'assegnazione dei lavori non saranno utilizzati (vedi slide 25 e 26 gruppo in alto a sx)
io intendevo llvm IR e strumenti relativi.

I driver ci saranno sempre ma per l'assegnazione dei lavori non saranno utilizzati (vedi slide 25 e 26 gruppo in alto a sx)


Quello che pensavo è posso rivoltare la frittata? Ovvero posso inviare alla GPU "disegna un quadrato"? O sono limitato a calcoli matematici? Ovvero ad usare la GPU come una... CPU?

Pensavo alla possibilità di scrivere una sorta di "Poor Man's Driver" per OS Open Source che per un motivo o per l'altro non può avere i Driver (per esempio il "mio" Haiku non supporta manco una banalissima GPU Intel ficcata dentro la CPU :muro:) oppure un super Qt o Super Java che disegna direttamente le finestre senza l'intervento nè di Kernel nè di OS!
(Non nascondiamoci dietro ad un dito AWT e SWT non sono venuti bene, e la versione di Eclipse è peggio perchè non supporta il Garbage Collector... liberare memoria? In JAVA?)


io intendevo llvm IR e strumenti relativi.


E' appunto ciò di cui parlavo Bitcode o IR - Intermediate Representation, ma facciamolo dire a loro:


The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation ("LLVM IR"). The LLVM Core libraries are well documented, and it is particularly easy to invent your own language (or port an existing compiler) to use LLVM as an optimizer and code generator.


e quindi? E quindi abbiamo, da una delle loro slide, che "HSAIL is a virtual ISA for parallel programs" che è finalizzato da un JIT (LLVM) che è indipendente per costruzione da CPU & GPU (Bitcode / IR), a me sembra alquanto chiaro, no? ISA sta per Instruction Set Architecture, no? Ovvero, in Italiano, un'architettura per una Macchina Virtuale...

LLVM, ovviamente, può essere un modo per "compilare" HSAIL, a quanto pare JVM è un altro :D

Accidenti! Ricompilano JAVA in LLVM IR e poi in Open CL! Vi rendete conto? Tu scrivi "normale" JAVA e lui di soppiatto lo trasforma per vostre stesse parole in quel m*rdaio di Open CL o, bontà di LLVM, in un paio di thread JAVA se la vostra GPU fa schifo... a Runtime s'intende :D
Non è che va a finire che JAVA diventa veloce come C/C++ o persino più veloce?
Di sicuro sarà più facile da programmare senza gli orridi Posix Threads o OpenMP :p
Il passo successivo? Riscrivere Java in modo che non crei più bytecode, ma direttamente HSAIL loro lo chiamano "Sumatra Project" ;)

Anche la Microsoft, se vuole, lo fo fare a .NET, i ragazzi di Qt potrebbero compilare per HSAIL, gli GNU possono mettersi a riscrivere GCC (auguri!)...

Dite che non è aperto? Tutt'altro io vedo ad occhio centinaia di pagine di Specifiche cosa volete di più? Che lo scrivano al posto vostro :Prrr: ?