[Larrabee][ENG] Nuovi dettagli + primo SDK

[Tommo]

Intel ormai parla da un bel pò di Larrabee, e questo dovrebbe essere (nei loro piani) il progetto che riporterà tutto il mercato High-End nelle mani del loro x86... fermando sul nascere l'indipendenza delle GPGPU.

Comunque finora si avevano molte poche informazioni, a parte vari annunci entusiastici...
però oggi ho trovato un pò di articoli interessanti che vanno piuttosto nel dettaglio:

-A First Look at the Larrabee New Instructions (LRBni)
5 pagine di inglese fitto fitto, ma decisamente interessanti: spiegano l'instruction set che dovrebbe permettere a questo "coso" di raggiungere il picco prestazionale senza fare salti mortali, tramite un insieme di operazioni a 3 registri (e 16 componenti) fondamentalmente "gratuite".

-Beyond Programmable Shading
Non sapevo che avessero fatto un talk di questo genere, comunque contiene un pò di esempi di quello che si crede porterà questo nuovo paradigma.

-Larrabee's New Instructions In C++: A Prototype
Informazioni sul prototipo di SDK per Larrabee, completo di emulatore per provare subito il codice.
Per i coraggiosi, direi

Per quanto mi riguarda, la cosa più interessante è l'attenzione che sta avendo l'idea di "salutare" Dx e OpenGL per ricostruire un proprio motore grafico completamente software dalle potenzialità decisamente superiori.
E pensare che quando dissi la stessa cosa anni fa "qualcuno" mi disse che non aveva minimamente senso
Oppure avrebbe senso un porting di Python su Larrabee:
"Python 100x faster than C++ in heavy processing"
Credo che molti sbaverebbero per un "headline" di questo genere qua in giro
Qualcun'altro è interessato a questa roba?

[cdimauro]

Finito di leggere l'articolone.

Debbo dire che come architettura è impressionante, ma qui il massimo lo si ottiene lavorando in assembly, per quanto possano fare un buon lavoro il compilatore e la libreria di Intel.

[Tommo]

A quanto pare si... spero che qualcuno tirerà fuori velocemente un middleware che lo fa per noi

Anche perchè in effetti pensare l'intera applicazione per dare in pasto i dati a quell'assembly può essere molto complicato...

[cdimauro]

L'intera applicazione no: si scrivono soltanto le parti più intensive.

Comunque non mi pare male lavorare con quell'assembly. Mi sembra molto versatile.

[Tommo]

Beh ma si è visto che fine fanno le architetture che obbligano a programmare in assembly, per quanto flessibile

La gente oggi snobba CUDA perchè è C, figurarsi in assembly... e poi poterci eseguire linguaggi di alto livello potrebbe essere un valtaggio in realtà.

[cdimauro]

Indubbiamente (e sai quanto mi piacerebbe vederci girare Python ), ma snobbare il C è cosa buona giusta.

[nAo]

La stragrande maggioranza delle persone programmera' LRB come qualsiasi altra GPU..ovvero via shaders. Il programming model e' semplificato, ma non ti devi certo imparare l'assembly per avere codice ottimizzato.

[cdimauro]

Non si parlava di codice ottimizzato e basta, ma di "massimo". Nel senso di codice spremuto per benino.