Link alla notizia: http://www.hwupgrade.it/news/skvideo/da-amd-un-approccio-alternativo-a-cuda-per-il-calcolo-parallelo-con-gpu_59595.html

Grazie alla Boltzmann Initiative AMD punta a rendere le schede FirePro degli strumenti sempre più nelle mani di chi fa calcolo parallelo ad alte prestazioni. Tutto questo cambiando radicalmente la propria base software

Click sul link per visualizzare la notizia.

Io continuo a credere che HSA possa veramente diventare qualcosa di vincente per AMD, ma se non raggiunge la massa critica servirà a poco.

io continuo a vedere HSA per quello che è, OpenlCL con la memoria condivisa della GPU dell'APU e stop, e ora con HSA+ hanno aggiunto il supporto alla memoria condivisa delle GPU discrete con questo nuovo tool, cosa che nVidia ha iniziato a introdurre nel 2013 con CUDA 6.0 e che si concretizzera con il supporto Hardware di Pascal; presumo quindi che anche le nuove GPU AMD avranno il supporto alla memoria condivisa in hardware, direi che sono obbligati a metterla seno sara gia una partita persa.

non farebbero prima a rellare estensioni per opencl invece di inventarsi un'altra cosa proprietaria che in questo caso non usera veramente nessuno?

io continuo a vedere HSA per quello che è, OpenlCL con la memoria condivisa della GPU dell'APU e stop, e ora con HSA+ hanno aggiunto il supporto alla memoria condivisa delle GPU discrete con questo nuovo tool, cosa che nVidia ha iniziato a introdurre nel 2013 con CUDA 6.0 e che si concretizzera con il supporto Hardware di Pascal; presumo quindi che anche le nuove GPU AMD avranno il supporto alla memoria condivisa in hardware, direi che sono obbligati a metterla seno sara gia una partita persa.
E' la gpu che ha subito modifiche in questi anni proprio per adattarsi alle esigenze del calcolo eterogeneo, è questa il cuore di HSA. Comunque faccio notare che Intel ha una soluzione del genere da anni. Dall'alto della mia ignoranza, la GPU non agisce direttamente sulla RAM di sistema, ma piuttosto ci sarà una esecuzione runtime che ha il compito di sincronizzare opportunamente le letture e scritture tra cpu e gpu, in modo da mantenere coerenti i dati condivisi. Quindi c'è sempre una copia dei dati usando il PCI-Express, ma è totalmente trasparente all'applicazione.

E' un HSA "finto"..in pratica agevola solo la programmazione al programmatore, ma si capisce bene che un algoritmo HSA+ e HSA ha costi differenti e per tanto è consigliabile, quantomeno una compilazione ad hoc.

Serve ad AMD per consentire di sfruttare HSA anche sulle sue APU, anche con codici che non sono espressamente progettate per le APU (ricordo che un'applicazione HSA è incompatibile a livello di codice sorgente).

AMD è sempre stata persa nel mondo del GPGPU. Non ha mai avuto una strategia che potesse essere considerata semi decente.
Dall'uso dell'architettura VLIW che non era adatta al GPGPU al passaggio a GCN lato HW non è corrisposto alcuna evoluzione sul piano del supporto SW né della strategia stessa.
E infatti si sono visti i risultati e i tentativi di correzione al volo.

AMD è partita con capacità DP stratosferiche sulle proprie GPU. Peccato che lato professionale non offra alcun supporto al loro utilizzo. Quindi alla fine hanno capito che è silicio e corrente sprecati. All'aumento di dimensioni del die, quindi a fascia di appartenenza superiore, ogni revisione di GCN ha rimosso le capacità DP. Si è partiti con Tahiti e 1/4, Hawaii è scesa a 1/8, Tonga a 1/16 e Fiji a 1/24.
Per assurdo le GPU destinate al migliore mercato che avrebbe potuto sfruttare le capacità DP sono quelle che sono state maggiormente penalizzate. Rendedndo le GPU di fascia media inutilmente più costose da produrre per il solo scopo di far girare i videogiochi.
Questo va in contrasto con la strategia nvidia che è la stessa da sempre: capacità DP nulle sulle schede low end, ovvero tutto quello che è più piccolo della mattonella, mentre unità DP apposite aggiunte su quest'ultima. Quindi GPU da gioco meno costose (per lei) e GPU professionali a costo elevato ma con la sicurezza di poterle vendere con margine altissimo lo stesso.
Le due strategie HW vanno in direzioni opposte, e non si capisce davvero dove porti quella di AMD. Si vede che in India si studia economia al rovescio.
Se aggiungiamo che AMD non ha mai investito seriamente nel supporto SW delle proprie architetture, la frittata è bella che fatta.

Ora se ne esce con un tool di conversione tra le applicazioni CUDA e il suo nuovo OpenCL con nuovi entusiasmanti acronimi, manco che convertire la sintassi equivalesse a poter usare tutte le librerie che nvidia mette a disposizione con CUDA.
Diciamo pure che è in alto mare e non sembra capace di portarsi verso riva. E non sembra nemmeno che si stia sforzando poi molto per farlo. Con una frazione di quello che è stato investito per trasformare GCN1.0 in GCN1.2 senza davvero aver migliorato di alcunché la sua situazione (anzi peggiorandola lato professionale), avrebbero benissimo potuto cercare (quantomeno cercare) di dare maggior supporto al proprio HW invece di affidarsi, come ormai le è di abitudine, che siano altri a fare il lavoro per conto suo.
Ma con meno del 20% del mercato, ormai sta perdendo anche il supporto degli irriducibili. E recuperarlo quando si è così indietro, diventerà molto ma molto difficile.

@tuttodigitale
HSA non è programmazione su APU. La APU è una implementazione di HSA. Ma non è HSA.
Avere la memoria condivisa o meno non cambia il modo di lavorare. E' un vantaggio che può (e deve ) essere sfruttato, ma un algoritmo può essere scritto benissimo per girare (con diverse prestazioni) indipendentemente dal fatto che la memoria sia condivisa o meno sullo stesso MC.
Se il framework n cui si lavora estrae la configurazione della memoria in maniera completa, l'algoritmo è trasparente alla configurazione fisica. Quest'ultima influenza solo le prestazioni. nvidia con Pascal introdurrà l'nvlink, che non sarà come avere la memoria condivisa tramite lo stesso MC come con le APU, ma non sarà neanche come usare il PCI-e per fare i dovuti trasferimenti tra i vari buffer.
Mentre AMD è e sarà limitata ad avere alta efficienza solo con le APU, nvidia aumenterà la sua efficienza con le schede discrete destinate al mercato dove l'nvlink farà la differenza. Ancora una volta una bella differenza tra le due strategie.

Poi ovviamente, come da prassi da diversi anni, tra qualche mese AMD se ne uscirà su un foglio di carta con la proposta "open" di una specifica nuova per un nuovo bus di interconnessione CPU-GPU ad alte prestazioni, da far realizzare agli altri ovviamente, facendo ancora una volta la figura di quella che crea tecnologia "aperta" e non proprietaria.

...
Doppio

farà la fine di mantle...

Si è partiti con Tahiti e 1/4, Hawaii è salito a 1/2, Tonga a 1/16 e Fiji a 1/24.
@crapadilegno gli algoritmi si sviluppano in base all'hardware c'è sotto: tra HSA in forma discreta e quella in forma integrata cambia una vita.
E comunque un bus ad alte prestazioni per la GPU, AMD già ce l'ha già e si chiama HyperTrasport.

Tutto il resto sono sciocchezze, inclusa il fatto che HSA(+) non facilita la programmazione:
Memory regions shared between the LCU and TCU are coherent. This simplifies programming by
eliminating the need for explicit cache coherency management primitives, and it also enables finergrained
offload and more efficient producer/consumer interaction. The major benefit from coherent
memory comes from eliminating explicit data movement and eliminating the need for explicit heavyweight
synchronization (flushing or cache invalidation). The support of existing programming models that
already use flushing and cache invalidation can also be supported, if needed.

Io non ne so molto, ma tu mi batti. :O

lui è un appassionato di amd, sa tutto di amd e non solo, commenta solo le news di amd e soprattutto compra solo amd indi per cui ha comunque ragione.

in pratica, lui è come me all'ennesima potenza. :D

E' la gpu che ha subito modifiche in questi anni proprio per adattarsi alle esigenze del calcolo eterogeneo, è questa il cuore di HSA. Comunque faccio notare che Intel ha una soluzione del genere da anni. Dall'alto della mia ignoranza, la GPU non agisce direttamente sulla RAM di sistema, ma piuttosto ci sarà una esecuzione runtime che ha il compito di sincronizzare opportunamente le letture e scritture tra cpu e gpu, in modo da mantenere coerenti i dati condivisi. Quindi c'è sempre una copia dei dati usando il PCI-Express, ma è totalmente trasparente all'applicazione.
Intel utilizza la cache L3 allo scopo, che è condivisa fra CPU e GPU. In questo modo si mantiene automaticamente, ed efficientemente, la coerenza dei dati fra i due componenti, e fra questi e la memoria. Non c'è copia dei dati su PCI-Express, perché la GPU integrata lavora sulla memoria di sistema.
Ora se ne esce con un tool di conversione tra le applicazioni CUDA e il suo nuovo OpenCL con nuovi entusiasmanti acronimi, manco che convertire la sintassi equivalesse a poter usare tutte le librerie che nvidia mette a disposizione con CUDA.
Le librerie si possono riscrivere per sfruttare direttamente HSA, mantenendo la stessa interfaccia (o comunque facendo sì che il traduttore si occupi anche di quest'aspetto).

Comunque il tool di conversione è una buona trovata per agevolare la conversione/porting del codice che già usa CUDA, che non è certo poco (visto che nVidia è stata pioniera).

Sarebbe interessante sapere se questo tool sarà open source, o comunque sia in grado di generare codice OpenCL sufficientemente generico da poter essere utilizzato anche su soluzioni diverse dalle sue. Intel è il leader di mercato riguardo alle GPU, e i suoi utenti potrebbe trarne grande beneficio.
Avere la memoria condivisa o meno non cambia il modo di lavorare. E' un vantaggio che può (e deve ) essere sfruttato, ma un algoritmo può essere scritto benissimo per girare (con diverse prestazioni) indipendentemente dal fatto che la memoria sia condivisa o meno sullo stesso MC.
Se il framework n cui si lavora estrae la configurazione della memoria in maniera completa, l'algoritmo è trasparente alla configurazione fisica. Quest'ultima influenza solo le prestazioni. nvidia con Pascal introdurrà l'nvlink, che non sarà come avere la memoria condivisa tramite lo stesso MC come con le APU, ma non sarà neanche come usare il PCI-e per fare i dovuti trasferimenti tra i vari buffer.
Come ha già fatto notare tuttodigitale, non è affatto così. Scrivere un algoritmo che utilizza una GPU integrata o una discreta produce risultati ben diversi, a causa delle enorme differenze che ci sono in termini di latenza e banda di memoria. Se poi ci mettiamo pure la presenza di cache L3 condivisa e/o L4 (eDRAM), come avviene nelle soluzioni Intel (l'eDRAM solo con le Iris Pro), ci troviamo di fronte a ulteriori, notevoli, differenze.

Questo non vuol dire che non si possa scrivere codice generico che giri su qualunque di queste GPU, però i risultati non saranno sicuramente ottimali (a volte decisamente sub-ottimali).

Per sfruttare al meglio un dispositivo di massiccio calcolo parallelo, per il programmatore è necessario conoscere anche questi dettagli.

Poi se ci si accontenta di una prima bozza di soluzione, perché "tanto va già molto meglio rispetto alla CPU", è un altro paio di maniche.
Mentre AMD è e sarà limitata ad avere alta efficienza solo con le APU, nvidia aumenterà la sua efficienza con le schede discrete destinate al mercato dove l'nvlink farà la differenza. Ancora una volta una bella differenza tra le due strategie.

Poi ovviamente, come da prassi da diversi anni, tra qualche mese AMD se ne uscirà su un foglio di carta con la proposta "open" di una specifica nuova per un nuovo bus di interconnessione CPU-GPU ad alte prestazioni, da far realizzare agli altri ovviamente, facendo ancora una volta la figura di quella che crea tecnologia "aperta" e non proprietaria.
Ha già Hypertransport, come ha detto tuttodigitale, e Intel ha appena presentato la sua tecnologia a questo scopo.

Gli cambieranno nome e lo useranno tutti quindi? :rolleyes:

ancora co sta storia che dx12 è mantle? :D

Io continuo a credere che HSA possa veramente diventare qualcosa di vincente per AMD, ma se non raggiunge la massa critica servirà a poco.HSA di certo non ha come settore di punta il desktop.
E penso che sarà la analoga implementazione di Nvidia e Intel a ingranare, ma più su altri settori.

:doh:

È come dire che una ferrari non va forte in pista se non gli metti le gomme da neve
HSA serve con le integrate, con le dedicate cambia ben poco da openCL.

Integrate che le cpu di punta non hanno.
E soprattutto hai detto bene .... lavorano con le integrate, quindi dà anche un senso di spreco enorme di potenziale avendo le discrete installate, contrariamente invece al settore mobile.

del resto quando si scende così tanto verso l'hardware è normale (penso) che il linguaggio di programmazione si livella

http://i169.photobucket.com/albums/u233/Rocketrod6a/Mantle%20vs%20DX12%20pgm%20guide.jpg

Impossibile non notare l'evidente plagio. Chissà chi dei due ha copiato...

In effetti la strategia di AMD è poco comprensibile, secondo me l'obbiettivo era di spostarsi tutto su APU anche per quel la fascia alta, ma poi quando hanno visto che HSA non se l'è filato nessuno hanno cambiato idea.

Non avrebbe senso fare delle della APU con una iGPU enorme, deve svolgere operazioni di calcolo eterogeneo in ambito consumer, non far girare gta5 in 4k.
Se devi far girare gta5 ci pensa la dedicata mentre l'integrata accelera quello che normalmente fa la cpu, uno volta ho trovato anche una slide (tra le milioni che produce AMD) che parlava di questa configurazione.

Ma per ZEN parlano di solo CPU quindi mi sa che è tutto finito alle ortiche, almeno in ambito consumer, per i server invece parlano di APU ciccione, sperem.
Non mi riferisco ai giochi.

Velocizzare la parte FPU utilizzando la GPU è ok, ma il dover utilizzare l'integrata quando si ha qualcosa di fascia alza installato fa ridere.
E' come avere un ottica tecnologia fisicamente handicappata.

Per quanto riguarda la potenza di calcolo non esiste un limite dove qualcuno può dire che la iGPU è in qualche modo tarata rispetto alla CPU secondo l'ottica HSA, perchè non è vero.

E se non avesse copiato nessuno?
AMD mi pare abbia dichiarato di lasciar perdere mantle in quanto soddisfatta dalle dx12 (o una cosa simile) come ho già scritto poco fa, proprio mentre amd e ms cooperavano per xbox1.
Sì, ma qualcuno l'avrà pur scritto il primo documento con quel testo...

Velocizzare la parte FPU utilizzando la GPU è ok
Non si può usare la GPU per velocizzare l'FPU, ma per sostituirla.

Intel utilizza la cache L3 allo scopo, che è condivisa fra CPU e GPU. In questo modo si mantiene automaticamente, ed efficientemente, la coerenza dei dati fra i due componenti, e fra questi e la memoria. Non c'è copia dei dati su PCI-Express, perché la GPU integrata lavora sulla memoria di sistema.

Mi riferivo al dialogo tra le soluzioni Xeon x86 e le soluzioni pci express Xeon Phi. Credo che l'implementazioni di AMD descritta nella news sia la medesima.

Precisato questo, quoto non solo ogni singola parola, ma anche la punteggiatura.

Allora avevo capito male io. Siamo perfettamente d'accordo. ;)

Non mi riferisco ai giochi.

Velocizzare la parte FPU utilizzando la GPU è ok, ma il dover utilizzare l'integrata quando si ha qualcosa di fascia alza installato fa ridere.
E' come avere un ottica tecnologia fisicamente handicappata.

Per quanto riguarda la potenza di calcolo non esiste un limite dove qualcuno può dire che la iGPU è in qualche modo tarata rispetto alla CPU secondo l'ottica HSA, perchè non è vero.

questo è vero sempre, ad esempio, ci sono compiti in cui non è richiesta la FPu, e una cpu priva di questo elemento potrebbe garantire un'efficienza più elevata.
.
La differenza te l'ha detta cdimauro. Questo significa che una soluzione integrata può permettersi un dialogo più intenso tra cpu e gpu: laddove in una soluzione discreta, la cpu e la gpu sono costretti, in misura maggiore, a eseguire parte di codice dove un processore è molto peggio dell'altro.
Questo è dovuto proprio al passaggio dei dati (poco conta se la copia non è esplicita). In pratica il processore1 potrà eseguire il compito più velocemente (una ditta con numerosi operai), peccato che esiste una certa latenza, MOLTO maggiore nelle soluzioni discrete (la cosiddetta burocrazia), tanto che è più vantaggioso appoggiarsi al lentissimo processore2, (l'amico nel tempo libero): il risultato è che il lavoro può effettivamente terminare prima facendo eseguire una sequenza di istruzioni ad un processore meno adatto.

La cpu e la fpu si scambiano il ruolo di processore1 e processore2, dell'esempio precedente, in base al codice che devono eseguire.

HSA, o comunque le soluzioni integrate, possono aprire orizzonti nuovi. Ci vuole del tempo. Forse il 2017 HSA sarà sfruttato a dovere, proprio nel mercato HPC.

In effetti la strategia di AMD è poco comprensibile, secondo me l'obbiettivo era di spostarsi tutto su APU anche per quel la fascia alta, ma poi quando hanno visto che HSA non se l'è filato nessuno hanno cambiato idea.

http://www.bitsandchips.it/9-hardware/5858-amd-exascale-heterogeneous-processor

A me pare che AMD sia ritornata all'idea originale...

Allora avevo capito male io. Siamo perfettamente d'accordo. ;)
:cool:

questo è vero sempre, ad esempio, ci sono compiti in cui non è richiesta la FPu, e una cpu priva di questo elemento potrebbe garantire un'efficienza più elevata.ben vanga la rimozione completa della FPU.
Meno transistors e più efficienza per tutta l'architettura x86 ( specie rispetto ad ARM ).

La differenza te l'ha detta cdimauro. Questo significa che una soluzione integrata può permettersi un dialogo più intenso tra cpu e gpu: laddove in una soluzione discreta, la cpu e la gpu sono costretti, in misura maggiore, a eseguire parte di codice dove un processore è molto peggio dell'altro.
Questo è dovuto proprio al passaggio dei dati (poco conta se la copia non è esplicita). In pratica il processore1 potrà eseguire il compito più velocemente (una ditta con numerosi operai), peccato che esiste una certa latenza, MOLTO maggiore nelle soluzioni discrete (la cosiddetta burocrazia), tanto che è più vantaggioso appoggiarsi al lentissimo processore2, (l'amico nel tempo libero): il risultato è che il lavoro può effettivamente terminare prima facendo eseguire una sequenza di istruzioni ad un processore meno adatto.
Dipende da cosa si intende fare, ci sono operazioni in cui la componente integer è quasi superflua ( e infatti si sfruttano le VGA ), senza contare che un calcolo float è di sicuro più complesso di un integer.

Fra discreta e CPU c'è molta più latenza ma c'è anche una differenza di potenza spaventosa.
Non è di certo nelle operazioni di rilievo che può essere utile su un desktop high end, ma più laddove c'è necessità di una massiva mole di calcolo.

La iGPU è a dir poco ridicola come GPU.

Impossibile non notare l'evidente plagio. Chissà chi dei due ha copiato...

ti pare che se amd avesse avuto la possibilità di fare una causa miliardaria a microsoft non l'avrebbe fatta?

ben vanga la rimozione completa della FPU.
Meno transistors e più efficienza per tutta l'architettura x86 ( specie rispetto ad ARM ).
Finché l'FPU consentirà di manipolare dati a 80 bit (contro i massimo 64 bit delle unità SIMD e in generale delle FPU presenti nelle altre architetture, ARM inclusa), è bene che rimanga al suo posto, perché è l'unico buon motivo per cui ha senso utilizzarla ancora oggi.
Dipende da cosa si intende fare, ci sono operazioni in cui la componente integer è quasi superflua ( e infatti si sfruttano le VGA ),
Per quanto massiccio possa essere l'uso di operazioni in virgola, c'è sempre una parte di istruzioni "intere" che viene eseguita. Questo perché, oltre ai calcoli interi, servono anche operazioni di "controllo" (che per semplicità vengono automaticamente "incluse" in quelle che chiamiamo "intere").
senza contare che un calcolo float è di sicuro più complesso di un integer.
Ecco qui:
REPNE CMPSB
Quest'istruzione "intera" potrebbe impiegare più di 100 ANNI (sì, hai letto bene: non sono nanosecondi) per essere portata a termine su un processore x64. Credo che sia abbastanza complessa, no?

Trovami un'istruzione in virgola mobile di qualunque altra architettura che possa fare di peggio.
Fra discreta e CPU c'è molta più latenza ma c'è anche una differenza di potenza spaventosa.
Non è di certo nelle operazioni di rilievo che può essere utile su un desktop high end, ma più laddove c'è necessità di una massiva mole di calcolo.
Non me ne faccio nulla di una potenza spaventosa, se per avere i risultati dei calcoli devo aspettare troppo.

Dipende tutto dal contesto applicativo. Se ho da verificare qualche teoria sulla cromodinamica quantistica, posso lanciare l'applicazione su un sistema massivamente parallelo, e venire a prendermi i risultati l'anno successivo: va benissimo così, perché so che è necessario aspettare.

Ma se ho un sistema realtime che ha tempi stretti per l'elaborazione, una latenza di qualche centinaio di nanosecondi potrebbe essere fatale. Dunque no: non posso aspettare la GPU discreta strafica che processa 10 volte i dati rispetto a quella integrata, ma mi accontento di quest'ultima che è in grado di fornirmi dei risultati accettabili nel tempo che mi serve.
La iGPU è a dir poco ridicola come GPU.
Idem come sopra: dipende da cosa devi farci. Io vedo diverse possibilità per la GPU integrata, come pure per l'FPU (che NON voglio che sia eliminata, finché non ci sarà un rimpiazzo che possa fare ALMENO le stesse cose, ALMENO in tempi simili).

Tu vedi il mondo troppo "o bianco o nero", senza riflettere sulle reali problematiche che devono essere risolte. E purtroppo lo fai senza nemmeno avere adeguate conoscenze tecniche (vedi sopra per alcuni esempi) e una buona dose di arroganza.

Capisco che per te sia importante attaccarti al joypad e goderti il tuo PC pompato con 4 Titan in configurazione SLI, ma non sono tutti come te e il mondo è pieno di gente che ha esigenze diverse, o che più semplicemente potrebbe benissimo anche accontentarsi di soluzioni meno "ricercate".

Dunque il mio consiglio è di evitare di intervenire in questioni, specialmente tecniche, di cui hai mostrato di non avere alcuna cognizione. E, cosa più importante, impara a dialogare civilmente, rispettando i tuoi interlocutori.
ti pare che se amd avesse avuto la possibilità di fare una causa miliardaria a microsoft non l'avrebbe fatta?
Assolutamente no, perché le due aziende sono in ottimi rapporti, e non sarebbe un caso come questo a incrinarli.

Personalmente penso che i tempi fossero ormai maturi per una soluzione più a basso livello, che mettesse in mano agli sviluppatori uno strumento che consentisse loro un maggior controllo delle risorse.

Semplicemente da appassionato di tecnologie m'interessava sapere chi dei due ha fatto partire il primo progetto "consumer" (perché IMO nelle console esistevano già soluzioni similari) di questo tipo. Tutto qui.

Tu vedi il mondo troppo "o bianco o nero", senza riflettere sulle reali problematiche che devono essere risolte. E purtroppo lo fai senza nemmeno avere adeguate conoscenze tecniche (vedi sopra per alcuni esempi) e una buona dose di arroganza.

Capisco che per te sia importante attaccarti al joypad e goderti il tuo PC pompato con 4 Titan in configurazione SLI

Dunque il mio consiglio è di evitare di intervenire in questioni, specialmente tecniche, di cui hai mostrato di non avere alcuna cognizione.
E questo chi lo dice ?

Un programmatore che si spacciava per progettista hardware ?
Forse è il caso di rimanere tale, invece di fingerti chissà chi per affermare cose NON DI TUA COMPETENZA.

Finché l'FPU consentirà di manipolare dati a 80 bit (contro i massimo 64 bit delle unità SIMD e in generale delle FPU presenti nelle altre architetture, ARM inclusa), è bene che rimanga al suo posto, perché è l'unico buon motivo per cui ha senso utilizzarla ancora oggi.Perchè su desktop si svolgono molte operazioni a 80bit .....

Per quanto massiccio possa essere l'uso di operazioni in virgola, c'è sempre una parte di istruzioni "intere" che viene eseguita. Questo perché, oltre ai calcoli interi, servono anche operazioni di "controllo" (che per semplicità vengono automaticamente "incluse" in quelle che chiamiamo "intere").Appunto operazioni di controllo, che non hanno di certo un peso paragonabile.

Ecco qui:
REPNE CMPSB
Quest'istruzione "intera" potrebbe impiegare più di 100 ANNI (sì, hai letto bene: non sono nanosecondi) per essere portata a termine su un processore x64. Credo che sia abbastanza complessa, no?Visto che sei un programmatore ( e forse non così bravo ) saprai che in ogni software esiste un ottimizzazione di base.
Mediamente le operazioni in float richiedono molte più risorse, delle eccezioni quì e là non mi interessano.


Non me ne faccio nulla di una potenza spaventosa, se per avere i risultati dei calcoli devo aspettare troppo.Motivo per cui HSA non viene preso in considerazione su server e hardware hi-end.
Meglio aspettare una risoluzione HARDWARE.

ben vanga la rimozione completa della FPU.
Meno transistors e più efficienza per tutta l'architettura x86 ( specie rispetto ad ARM ).


Hai travisato un poco le mie parole.:D

Le operazioni floating point potranno essere gestite esclusivamente dalle GPU nel momento in cui questa offrirà minori cicli morti. Siamo ancora lontani.

Fra discreta e CPU c'è molta più latenza ma c'è anche una differenza di potenza spaventosa.
Non vorrei dire, ma ha una potenza spaventosa solo perchè consuma spaventosamente e qualcosa in più di una soluzione integrata.
Non paragoniamo soluzioni da 65W. alias, a10-7800, con un mostro da 250+150W: se il secondo non sarà più potente di 6x anche quando sfruttanno l'apu, diventerà una soluzione perdente.

La iGPU è a dir poco ridicola come GPU.
Certo paragonata a soluzioni con un die complessivo di oltre 1000mmq direi di si.
Si vocifera che la prossima APU, avrà una gpu con un numero di SP pari ad almeno 2048 con una potenza in doppia precisione pari 1/2 SP


Motivo per cui HSA non viene preso in considerazione su server e hardware hi-end.
Meglio aspettare una risoluzione HARDWARE.
Questa è una STUPIDAGGINE.
Per fare un software ottimizzato, su un HW che di fatto è del tutto nuovo, sono necessari anni, poi solo l'apu NON è una alternativa, alle soluzioni discrete.
Cosa vieta di fare soluzioni con CPU eterogenee centrali e soluzioni PCIexpress, fermo restando che l'apu HPC sarà molto potente (ok lato cpu andrà sempre la metà dell'opteron di turno, ma è pur sempre un compromesso).

INTEL progetta di far lavorare su socket anche due CPU con 2 architetture diverse.

E questo chi lo dice ?

Un programmatore che si spacciava per progettista hardware ?
Forse è il caso di rimanere tale, invece di fingerti chissà chi per affermare cose NON DI TUA COMPETENZA.


Perchè su desktop si svolgono molte operazioni a 80bit .....

Appunto operazioni di controllo, che non hanno di certo un peso paragonabile.

Visto che sei un programmatore ( e forse non così bravo ) saprai che in ogni software esiste un ottimizzazione di base.
Mediamente le operazioni in float richiedono molte più risorse, delle eccezioni quì e là non mi interessano.


Motivo per cui HSA non viene preso in considerazione su server e hardware hi-end.
Meglio aspettare una risoluzione HARDWARE.


scusami, ma non mostri neanche un po' di rispetto per chi parla da persona matura e soprattutto su determinate cose ci ha lavorato realmente, non come tanti altri che si fanno "la bocca".

per il resto non commento, genericamente IMHO ti posso dire che certe cose le intuisci solamente e pure male.

su linux dovrebbe essere presente il supporto di default dalla prossima versione del compilatore, tempi previsti q2 2016.

AMD Plans To Contribute Heterogeneous Compute Compiler (http://www.phoronix.com/scan.php?page=news_item&px=AMD-HCC-LLVM-Plans)

"Besides the GCC support, AMD is apparently planning to publish a Heterogeneous Compute Compiler."


mi sorge un dubbio: Amd non aveva acquistato la "Sea.???" per l'architettura di interconnessione di tipo "fabric" per collegarci una elevata quantità di piccole apu ? ha abortito il progetto ?

E questo chi lo dice ?
I fatti di cui sopra, che dimostrano la tua scarsa conoscenza sulle cose che hai riportato.
Un programmatore che si spacciava per progettista hardware ?
Non mi sono mai sognato di affermare nulla del genere, ma sei liberissimo di quotarmi e dimostrarlo.
Forse è il caso di rimanere tale, invece di fingerti chissà chi per affermare cose NON DI TUA COMPETENZA.
In realtà sono proprio cose di mia competenza perché guarda caso lavoro coi sistemi Xeon Phi e negli ultimi mesi anche con le nostre GPU integrate.

Precisato questo, non ho bisogno di nascondermi dietro "titoli nobiliari" per sostenere le mie affermazioni: sono sufficienti i fatti che ho riportato in precedenza.

Per il resto il tuo è il classico attacco sul piano personale, da parte di chi non è in grado di sostenere una discussione.
Perchè su desktop si svolgono molte operazioni a 80bit .....
L'FPU degli x86 (ma lo stesso vale per quella dei Motorola 68K) lavora sempre alla massima precisione possibile. Dunque sì: TUTTE le operazioni (tranne ovviamente quelle di troncamento, o di store in memoria con tipi a precisione inferiore alla massima possibile, la "Extended") dell'FPU vengono svolte a 80 bit (16 per l'esponente, e ben 64 per la mantissa).

Inoltre ti faccio presente che ci sono linguaggi come Javascript che hanno il tipo intero, ma soltanto il float (a doppia precisione). Questo significa che un'implementazione di Javascript che non stia attenta a questi dettagli, e decidesse di usare proprio il tipo float a doppia precisione per qualunque cosa, potrebbe avere serie difficoltà a rappresentare tutti gli interi (con segno) che normalmente sono rappresentabili con 64 bit.
Appunto operazioni di controllo, che non hanno di certo un peso paragonabile.
Dipende tutto dal codice, ma possono tranquillamente avere un peso non indifferente nell'esecuzione di codice massicciamente parallelo.

In particolare l'architettura degli Xeon Phi ha introdotto un set di registri interi (quelli cosiddetti di "maschera"), con annesse operazioni "intere", che sono abbastanza utilizzati nel codice generato, perché in diversi casi consentono di eliminare un bel po' di istruzioni in virgola mobile, con ovvi benefici in ambito prestazionale. Questo arriverà anche su "desktop" con le prossime estensioni SIMD, le AVX-512.
Visto che sei un programmatore ( e forse non così bravo )
Almeno io lo sono. E lascio giudicare gli altri se me la cavo oppure no, ma certamente non prendo lezioni da uno che ha dimostrato di saperne in materia quanto io ne so di bricolage.
saprai che in ogni software esiste un ottimizzazione di base.
No, non lo so, ed è la prima volta che lo sento. Perché non m'illumini e spieghi, anche con degli esempi, cosa intendi con ciò? Nella vita non si smette mai d'imparare...
Mediamente le operazioni in float richiedono molte più risorse, delle eccezioni quì e là non mi interessano.
Copiare, confrontare, e riempire blocchi di memoria sono fra le operazioni più comuni e diffuse, e si realizzano spesso proprio con le istruzioni "intere" di cui ho riportato un esempio (che non è l'unico, quindi) in precedenza.

Specialmente da un po' di (micro)architetture a questa parte, Intel ha accelerato notevolmente alcune di queste istruzioni (chiamate "di stringa"), consentendo di avere prestazioni comparabili o migliori ai pezzi di codice che venivano utilizzati in precedenza, e che erano basate sostanzialmente sull'utilizzo dell'unità SIMD allo scopo (solo che le unità SIMD cambiano, e di conseguenza servono versioni apposite di queste routine per sfruttare adeguatamente le novità).
Motivo per cui HSA non viene preso in considerazione su server e hardware hi-end.
Questo non c'entra proprio nulla. Di HSA manca il supporto: è questo il suo attuale problema. Certamente non il fatto che offra meno potenza grezza di elaborazione rispetto alle GPU discrete.
Meglio aspettare una risoluzione HARDWARE.
A parte che si dice soluzione, e non risoluzione, sei in grado di fornire qualche idea in proposito? O l'hai buttata lì tanto per, giusto per spararne un'altra delle tue?
su linux dovrebbe essere presente il supporto di default dalla prossima versione del compilatore, tempi previsti q2 2016.

AMD Plans To Contribute Heterogeneous Compute Compiler (http://www.phoronix.com/scan.php?page=news_item&px=AMD-HCC-LLVM-Plans)

"Besides the GCC support, AMD is apparently planning to publish a Heterogeneous Compute Compiler."
Il problema è che realizzare un compilatore che sia in grado di generare codice ben ottimizzato per il target richiede non poche risorse, e dubito che AMD ne abbia da mettere a disposizione allo scopo.
mi sorge un dubbio: Amd non aveva acquistato la "Sea.???" per l'architettura di interconnessione di tipo "fabric" per collegarci una elevata quantità di piccole apu ? ha abortito il progetto ?
SeaMicro o è fallita o è stata venduta (adesso non ricordo bene), dopo due anni che AMD l'aveva acquistato (senza averci fatto niente di utile).

Il problema è che realizzare un compilatore che sia in grado di generare codice ben ottimizzato per il target richiede non poche risorse, e dubito che AMD ne abbia da mettere a disposizione allo scopo.

per il compilatore a sè stante ho delle perplessità, per l'introduzione di HSA in GCC 6 sono abbastanza fiducioso in quanto ci sarebbero altre entità a dar manforte (Suse ...)

Una piccola nota a margine.
Non è da escludere che le future FIREPRO della serie S, siano da inserire nello zoccolo (la magia delle HBM), in questo modo il rapporto CPU-GPU può essere gestito dal costruttore del sistema. Secondo me ci sono solo svantaggi nel proseguire con il pci-express.

chiedo a cdimauro, il prossimo XEON PHI sarà solo per socket?

per il compilatore a sè stante ho delle perplessità,
Non parlavo di un compilatore a sé stante. In questo caso ho ben più che delle perplessità sulla capacità per AMD di realizzarne uno.
per l'introduzione di HSA in GCC 6 sono abbastanza fiducioso in quanto ci sarebbero altre entità a dar manforte (Suse ...)
Il problema è che GCC non è certo il più rinomato compilatore riguardo alla generazione di codice ottimizzato, e in particolare riguardo alla (auto)vettorizzazione che è proprio ciò che serve in questo caso.
Una piccola nota a margine.
Non è da escludere che le future FIREPRO della serie S, siano da inserire nello zoccolo (la magia delle HBM), in questo modo il rapporto CPU-GPU può essere gestito dal costruttore del sistema. Secondo me ci sono solo svantaggi nel proseguire con il pci-express.
Concordo. Ed è il motivo per cui il prossimo Xeon Phi sarà (soprattutto) su socket.
chiedo a cdimauro, il prossimo XEON PHI sarà solo per socket?
No, è previsto anche su PCI-Express, esattamente come quelli attuali. E' un modello che è stato già sperimentato, Intel ha dei clienti, e se il nuovo chip offre la stessa interfaccia tutto il codice già sviluppato sarà riutilizzabile, ma con l'enorme vantaggio di girare all'incirca 3 volte più velocemente col nuovo hardware.

Non parlavo di un compilatore a sé stante. In questo caso ho ben più che delle perplessità sulla capacità per AMD di realizzarne uno.

mi sembra che amb avesse/abbia un compilatore "Open64" del quale però ne ignoro sia la efficacia sia lo stato di aggiornamento.


Il problema è che GCC non è certo il più rinomato compilatore riguardo alla generazione di codice ottimizzato, e in particolare riguardo alla (auto)vettorizzazione che è proprio ciò che serve in questo caso.

a tal proposito, anni fa feci il confronto tra gcc ed intel icc e, sicuramente, quest'ultimo era discretamente più veloce. Quello di gcc sarebbe un inizio, in genere segue sempre llvm ...

LLVM lo vedo meglio, perché è un progetto molto, ma molto più facile da migliorare/estendere, rispetto a GCC.

sveglia! per amd il fatto che le dx12 siano uguali o simili a mantle è un vantaggio e se devo dirla tutta la strategia di amd è stata quella di spingere ms a far si che questo avvenisse (mantle, architettura gcn su console e così via).

quale causa, una statua gli farebbero.

non mi sembra che le dx12 avvantaggino i gcn

non mi sembra che le dx12 avvantaggino i gcn
lato cpu sicuramente si. Intel continuerà ancora ad avere la CPU più prestante nel ST. Ne sono quasi certo.
lato gpu anche: i driver AMD, ironia della sorte, erano (sono) più single thread dipendenti di quelli nvidia.

Comunque a dirla tutta, la vecchia generazione di GPU GCN ha avuto un buon guadagno delle prestazioni in fable-legends rispetto alle soluzioni della stessa fascia di prezzo.
Ovviamente da verificare se questo sarà il trend.

Intanto, techpowerup, ha rinnovato la batteria di test e come risultato la Fury X è pari alla GTX980TI in 1440p e superiore in 4k.