C++ AMP, il GPU computing secondo Microsoft

[sierrodc]

@November

Qui c'è un esempio di codice:
http://hothardware.com/News/Microsoft-Demos-C-AMP-Heterogeneous-Computing-at-AFDS/

Non sono esperto di c++, però qualche annetto fa avevo usato OpenMP, dici che oramai è obsoleto?

[LMCH]

Originariamente inviato da Tedturb0

Mah.. da quando in qua M$ si fa paladina di specifiche open?

Embrace, Extend, Extinguish.
Prima si fanno paladini di proposte con le specifiche aperte (ma codice sorgente e brevetti sono un altro paio di maniche), poi "estendono lo standard" con roba che implementano solo loro e forti della loro posizione predominante fanno fuori la concorrenza.

[AlanBoo]

e io piccolo sviluppatore godo con quello "standard esteso" che mi permette di lavorare meglio e più velocemente per la maggioranza dell'utenza

[Racer89]

Non ho ben capito, ma un'applicazione del genere funziona con GPU sia nVidia che ATI?

[LMCH]

Originariamente inviato da AlanBoo

e io piccolo sviluppatore godo con quello "standard esteso" che mi permette di lavorare meglio e più velocemente per la maggioranza dell'utenza

Nella maggior parte dei casi non ti permette di lavorare meglio, ti da solo l'impressione che sia più semplice ma sopratutto ti lega meglio a Microsoft.

Considera ad esempio come mai .Net non abbia raggiunto gli obiettivi dichiarati ufficialmente da Microsoft e per AMP abbiano dovuto usare C++, mentre invece Apple zitta, zitta usa da tempo LLVM per ottimizzate automaticamente il codice per CPU e GPU e con Xcode4 è uscita con il supporto pieno per LLVM su tutta la linea (iPhone, iPad, ed i vari Mac).

[devbeginner]

Originariamente inviato da Tedturb0

Mah.. da quando in qua M$ si fa paladina di specifiche open?

.NET è standard ECMA da prima che tu conoscessi il significato di "open", posto che tu lo sappia anche ora.

[devbeginner]

Originariamente inviato da LMCH

Embrace, Extend, Extinguish.
Prima si fanno paladini di proposte con le specifiche aperte (ma codice sorgente e brevetti sono un altro paio di maniche), poi "estendono lo standard" con roba che implementano solo loro e forti della loro posizione predominante fanno fuori la concorrenza.

il solito blablabla.

nell'ecosistema .NET girano Ruby, Python, PHP (questi sono open sì?) e lo fanno piuttosto bene, con tanto di documentazione al seguito.

Mai dato un occhio a Codeplex?
Dai su...

Originariamente inviato da LMCH

Nella maggior parte dei casi non ti permette di lavorare meglio, ti da solo l'impressione che sia più semplice ma sopratutto ti lega meglio a Microsoft.

Considera ad esempio come mai .Net non abbia raggiunto gli obiettivi dichiarati ufficialmente da Microsoft e per AMP abbiano dovuto usare C++, mentre invece Apple zitta, zitta usa da tempo LLVM per ottimizzate automaticamente il codice per CPU e GPU e con Xcode4 è uscita con il supporto pieno per LLVM su tutta la linea (iPhone, iPad, ed i vari Mac).

nell'anno del signore 2011 per sviluppare su iPhone ti devi scordare il garbage collector e lui parla di LLVM (che per altro si sta cercando di implementare nei linguaggi che girano sul DLR).
Ma va va

[AlanBoo]

.net non ha raggiunto gli obiettivi?!
per AMP hanno "dovuto" usare C++ ?!?
Xcode?!?
Iphone, Mac ?!

ehhehe

[Aegon]

Originariamente inviato da boboviz

Visual Studio supporta già OpenCL.....

Non lo uso quindi non sapevo...

Originariamente inviato da Racer89

Non ho ben capito, ma un'applicazione del genere funziona con GPU sia nVidia che ATI?

Considerando che C++ AMP è stato presentato all'AMD Fusion D.S., questa lo supporterà a pieno insieme ad OpenCL; nVidia, analogamente, supporta OpenCL e DirectCompute quindi di sicuro abbraccerà pure questo.

SE rispettano le API standard si, un'applicazione del genere funzionerà su entrambe le piattaforme.

Originariamente inviato da LMCH

Considera ad esempio come mai .Net non abbia raggiunto gli obiettivi dichiarati ufficialmente da Microsoft e per AMP abbiano dovuto usare C++, mentre invece Apple zitta, zitta usa da tempo LLVM per ottimizzate automaticamente il codice per CPU e GPU e con Xcode4 è uscita con il supporto pieno per LLVM su tutta la linea (iPhone, iPad, ed i vari Mac).

A me sembra che .NET venga usato praticamente ovunque ormai... poi dovuto usare C++? Perché scusa, a parte C++ e Fortran quale linguaggio viene utilizzato per il CPU computing? Sempre da lì devi passare.
Apple zitta zitta ha ottimizzato GCC.

[LMCH]

Originariamente inviato da devbeginner

nell'anno del signore 2011 per sviluppare su iPhone ti devi scordare il garbage collector e lui parla di LLVM (che per altro si sta cercando di implementare nei linguaggi che girano sul DLR).
Ma va va

Quella è stata una scelta deliberata di Apple e come forse ben saprai LLVM gira sia con o senza garbage collector (può essere implementato sia dai runtime che a livello di librerie di supporto specifico di un certo linguaggio).

[LMCH]

Originariamente inviato da Aegon

A me sembra che .NET venga usato praticamente ovunque ormai... poi dovuto usare C++? Perché scusa, a parte C++ e Fortran quale linguaggio viene utilizzato per il CPU computing? Sempre da lì devi passare.

Viene usato praticamente ovunque (su S.O di Microsoft) ... solo che in codice .Net managed puro si scrivono le applicazioni che una volta si scrivevano con il Visual Basic pre-Net oppure che altri scrivono in Java, mentre per il resto si finisce con il mixare codice managed ed unmanaged ecc. ecc.
Viene usato anche su Windows CE, ma come con i runtime precedenti devi ricordarti di non usare un sacco di roba che c'e' solo sul desktop, ecc. ecc.
E questo ci porta alla necessità di usare per molta roba il "vecchio" C++ nonostante Microsoft la smeni sempre con quanto è più bello, moderno ed efficiente usare C#.

Originariamente inviato da Aegon

Apple zitta zitta ha ottimizzato GCC.

Hai presente il CLang ? (compilatore C/C++ scritto da zero, ottimizzato per LLVM e sponsorizzato da Apple)

[devbeginner]

Originariamente inviato da LMCH

Quella è stata una scelta deliberata di Apple e come forse ben saprai LLVM gira sia con o senza garbage collector (può essere implementato sia dai runtime che a livello di librerie di supporto specifico di un certo linguaggio).

una scelta cretina (non la prima, nemmeno l'ultima) lato sviluppo.
IL GC è stato creato per scaricare il dev del compito di dover allocare/disallocare risorse in continuazione.

Quando qualche sviluppatore chiede insistentemente il supporto gli viene risposto che "non ci sarà per evitare che l'autonomia cali drasticamente" adducendo che il garbage collector porta ad un aumento della memoria e delle risorse occupate.
Peccato sia esattamente il contrario, è molto meglio che un automa gestisca i vari use case piuttosto che un umano che si può tranquillamente dimenticare di rilasciare/deallocare le risorse.

Tant'è che l'iPhone non dura certo più degli altri smartphone di fascia alta.


Alla fin fine gli unici campi dove è necessario avere sempre sotto controllo lo stato di un oggetto in memoria sono le simulazioni e l'hard time in generale, ecco perché i motori grafici 3D sono (ancora) in C++.

[Racer89]

sapete dove posso trovare una guida o una documentazione che mostra come funziona?

[LMCH]

Originariamente inviato da devbeginner

Alla fin fine gli unici campi dove è necessario avere sempre sotto controllo lo stato di un oggetto in memoria sono le simulazioni e l'hard time in generale, ecco perché i motori grafici 3D sono (ancora) in C++.

Oppure qualsiasi applicazione in cui maggiori prestazioni fanno la differenza, mica solo le simulazioni.

[devbeginner]

Originariamente inviato da LMCH

Oppure qualsiasi applicazione in cui maggiori prestazioni fanno la differenza, mica solo le simulazioni.

a parità di applicazioni ed HW sono proprio curioso di vedere quali mirabolanti differenze di prestazioni possa offrire l'iPhone rispetto ad un WP7 che si avvale di .NET o di Android con Java.
Benchmark alla mano.


Occhio perché stiamo parlando di utilizzo o meno del GC che può fare la differenza, non di come l'iPhone gestisca le applicazioni native piuttosto che quelle di terze parti, perché è tutt'altra faccenda.

[LMCH]

Originariamente inviato da devbeginner

a parità di applicazioni ed HW sono proprio curioso di vedere quali mirabolanti differenze di prestazioni possa offrire l'iPhone rispetto ad un WP7 che si avvale di .NET o di Android con Java.
Benchmark alla mano.

Il riferimento alle prestazioni era riguardo l'utilizzo di C++, non sulla scelta di non permettere l'uso del garbage Collector su iPhone.

[Racer89]

la nuova libreria amp è già disponibile? vs2010 la integra o dobbiamo aspettare la prossima versione?

[Tedturb0]

Originariamente inviato da devbeginner

.NET è standard ECMA da prima che tu conoscessi il significato di "open", posto che tu lo sappia anche ora.

da quanto ne so non tutto .net è standard e i brevetti royalty free.

[Tedturb0]

Originariamente inviato da devbeginner

una scelta cretina (non la prima, nemmeno l'ultima) lato sviluppo.
IL GC è stato creato per scaricare il dev del compito di dover allocare/disallocare risorse in continuazione.

Quando qualche sviluppatore chiede insistentemente il supporto gli viene risposto che "non ci sarà per evitare che l'autonomia cali drasticamente" adducendo che il garbage collector porta ad un aumento della memoria e delle risorse occupate.
Peccato sia esattamente il contrario, è molto meglio che un automa gestisca i vari use case piuttosto che un umano che si può tranquillamente dimenticare di rilasciare/deallocare le risorse.

Tant'è che l'iPhone non dura certo più degli altri smartphone di fascia alta.


Alla fin fine gli unici campi dove è necessario avere sempre sotto controllo lo stato di un oggetto in memoria sono le simulazioni e l'hard time in generale, ecco perché i motori grafici 3D sono (ancora) in C++.

forse il fatto che iPhone non abbia GC è il motivo per cui all'atto pratico sembri ancora piu veloce dei moderni smartphone dual core con applicazioni scritte in java

solo un ipotesi eh

[devbeginner]

Originariamente inviato da Tedturb0

da quanto ne so non tutto .net è standard e i brevetti royalty free.

http://www.ecma-international.org/pu...s/Ecma-335.htm