Link alla notizia: http://www.businessmagazine.it/news/intel-xeon-phi-ufficialmente-al-debutto-schede-x86-per-gpu-computing_44628.html

In concomitanza con SC12 Intel presenta le proprie schede Xeon Phi, prodotti che abbinano l'accelerazione a calcoli paralleli con la flessibilità dell'architettura x86

Click sul link per visualizzare la notizia.

Sbaglio o questa è la prima gpu dedicata di intel? :)

Sbaglio o questa è la prima gpu dedicata di intel? :)

è un comprocessore matematico non una gpu o una scheda gpgpu.

è un comprocessore matematico non una gpu o una scheda gpgpu.

Ah è che l'avevo letto nella news

Di fatto si tratta quindi di schede video con GPU compatibile con le istruzioni x86...
la scheda Xeon Phi 5110P, soluzione che integra GPU dotata...

diciamo allora una via di mezzo?

Infatti non è un GPU. E' una sorta di mini-cluster-on-a-box, programmabile x86. E' il figlio di MIC (many integrated cores), o meglio, la sua prima applicazione concreta. Di fatto sono 60 micro Xeon connessi tra di loro.

Ah è che l'avevo letto nella news

diciamo allora una via di mezzo?

ho visto ma per come è scritta la news è sbagliata, chiamarla scheda video e gpu è sbagliatisimo, ma lo fanno perche per la massa è piu facile da capire.

Che Phigata™ :sofico:

hmm ma essendo x86 non c'e' modo di far vedere la scheda come se fosse in dual socket e trovarsi nel taskmanager un godzillione di core?

per le workstation sarebbe una manna

(edit: scusate i termini alla buona ma era per rendere meglio il concetto)

Certo, ma non in ambiente Windows. La scheda la piloti con il suo Linux dedicato e la programmi come un supercomputer nano (o come un cluster appunto...). A breve dovrebbe arrivare la 100 core.

Per il calcolo su workstation in teoria basta scaraventarci dentro il motore di calcolo distribuito e farlo partire (es. se stai parlando di rendering o analisi). L'unica cosa che non ho capito è se il suo SO funziona in un ambiente virtualizzato o cosa...

eh no, io dico proprio come uso bruto senza dover scrivere una virgola di codice in +...

il vantaggio x86 per certi aspetti sarebbe proprio questo..

nowadays il problema continua ad essere la pigrizia enorme con cui le software house rilasciano compatibilità con l'hardware sottostante

i produttori di programmi professionali si e no si sono degnati di scrivere codice multi cpu, ce ne sono ancora alcuni che vanno solo in monocore e manco in 64bit..

quanti effettivamente stanno sfruttando il gpugpu..?

e in quanti casi si hanno software che permettono il rendering via rete? si contano sulla punta delle dita e hanno licenze assurde

a parte quello classico della ricerca scientifica ci sono un sacco di ambiti, in cui infilare nel case una di queste schede e trovarsi anche 64 core che viaggiano a 800mhz in + senza dover imbastire cluster di calcolo pesi sarebbe una vera manna manna

ne venderebbero un'infinità

parliamo di gente che fa tutto un altro lavoro e non sa scrivere una riga di codice ma i software li usa

Certo, ma non in ambiente Windows. La scheda la piloti con il suo Linux dedicato e la programmi come un supercomputer nano (o come un cluster appunto...). A breve dovrebbe arrivare la 100 core.

Per il calcolo su workstation in teoria basta scaraventarci dentro il motore di calcolo distribuito e farlo partire (es. se stai parlando di rendering o analisi). L'unica cosa che non ho capito è se il suo SO funziona in un ambiente virtualizzato o cosa...

la scheda puo essere utilizzata tranquillamente in windows. Il linux dedicato è all'interno della scheda stessa e fa da framework non è un sistema operativo che installi sul pc per poi usare la scheda stessa.

Quindi questa scheda la puoi montare anche su una workstation normale come puoi fare con le controparti amd e nvidia, lo scopo è lo stesso anche se l'implementazione hardware è differente.

eh no, io dico proprio come uso bruto senza dover scrivere una virgola di codice in +...

quello che chiedi è impossibile da raggiungere, è il software che sfrutta l'hardware non viceversa.

Citavi i software di rendering, quelli sono per natura difficilmente accelerabili da soluzioni GPGPU il codice è troppo complesso per poter "girare" su quel tipo di hardware solo certe modalità sono supportate, gia questa soluzione intel sarebbe piu adatta per come è implementata internamente ma è arrivata appena oggi quindi dobbiamo vedere cosa ci riserva il futuro. Quindi ne i tuoi software di rendering non si sono adattati è perche non potevano farlo non per pigrizia.

quello che chiedi è impossibile da raggiungere, è il software che sfrutta l'hardware non viceversa.

ci scrivono loro un driver intendo... ma sul layer dell'os vengono visti come processori aggiuntivi cosa c'e' di cosi' impossibile..?

per farla breve

se è utilizzabile solo riscrivendo codice a se stante ma con pieno supporto delle x86 è una "win" per gli sviluppatori

se è utilizzabile da chiunque come processori extra x86 "quelli nel task manager" (stiamo parlando ovviamente di un potenziale inferiore a quella che potrebbe essere na mobo quad socket con varie cpu multicore seria) sarebbe una "win" per tutti...

---

nel caso a, è solo un altro competitor e devi aspettare che... che so' adobe decida di abilitare il supporto completo in tutta la suite... ma sono tutti rilasci molto lenti

nel caso b invece, da subito qualsiasi software semplicemente scritto per scalare in multithread al numero dei core disponibili vola e ti fa risparmiare un sacco di tempo

neh che sto parlando di chissà quali software eh? cioe' anche il + semplice Adobe Lightroom quando renderizza i raw li esporta sfruttando tutti i core disponibili fallo con 4 o con 8 è una cosa fallo con 64 è un'altra :stordita:

Quindi ne i tuoi software di rendering non si sono adattati è perche non potevano farlo non per pigrizia.

praticamente qualsiasi software che codifica massicciamente flussi audio/video può essere accelerato da quelle soluzioni... con i flussi hd e 4k ben più che alle porte la potenza di calcolo non basta mai

anche per filtri e tutto il resto

per i giochi 3d hanno fatto framework allucinanti e sono relativamente vicini come tipo di calcolo anche se gli ambiti sono distanti...

sono pigrizia + incertezza se buttarsi a riscrivere una marea di codice per una soluzione che oggi dura 5 minuti e domani non si sa se sarà uno standard e aggiungiamo anche una bella dose di... scrivo il codice nel linguaggio tot affine a certe gpu perchè ho fatto una bella partnership :\ cosa che poi ti obbliga ad acquistare uno specifico brand

eh no, io dico proprio come uso bruto senza dover scrivere una virgola di codice in +...difficile, anche perchè i 60 core non sono nè di classe Core nè Atom ma a quanto pare si tratta di derivati del P5 (pentium) (quindi niente MMX, (S)SSE-x , niente AVX, e pare niente X87 legacy) a cui è stata aggiunta la compatibilità X64 e un' unità SIMD a 512 bit (IMCI)

quindi come minimo (e a patto di avere caso di codice C / C++ e di appoggiarsi ai tool e performance libraries intel - che incapsulino l' assembly ottimizzato per lo specifico core target) è necessario aggiungere delle direttive che istruiscano il compilatore a fare uso dell' unità IMCI piuttosto che delle varie SIMD attualmente mainstream, e ricompilare

nowadays il problema continua ad essere la pigrizia enorme con cui le software house rilasciano compatibilità con l'hardware sottostantema devi tenere presente che il target a cui questo oggetto è indirizzato non è il sw mainstream, ma quegli ambiti in cui il sw è scritto una tantum per l' architettura del supercomputer / cluster in uso

in questo senso, far girare codice preesistente con minime modifiche è un notevole vantaggio rispetto all' alternativa finora disponibile - doverlo rivedere integrarlmente per migrarlo a soluzioni GPGPU con annesso cambio di paradigma, cosa che in effetti equivale a un progetto sw a sè stante
se è utilizzabile da chiunque come processori extra x86 "quelli nel task manager" (stiamo parlando ovviamente di un potenziale inferiore a quella che potrebbe essere na mobo quad socket con varie cpu multicore seria) sarebbe una "win" per tutti...non funziona così...
in modalità hosted è una periferica PCI Express come un' altra, gestita attraverso driver ed enumerata ad uso delle applicazioni che necessitano di un compute acccelerator - presumibilmente le applicazioni faranno richiesta via librerie e driver di istanziare 1...60 thread di calcolo sul Phi, al che librerie e driver uploaderanno alla scheda segmenti di codice e dati su cui operare - più o meno come adesso funziona per gli shader, ma con codice X86-64+IMCI piuttosto che shader assembly proprietario
in modalità clustered è un nodo indirizzabile con un suo indirizzo IP - in questo caso può esserci maggiore flessibilità visto che molti sistemi facenti uso di calcolo distribuito implementano meccanismi di comunicazione e sincronizzazione interni, quindi basterebbe avviare i thread di calcolo sulla scheda (ma mancando come pare uno storage locale da cui avviare il firmware sarà cmq l' host a occuparsi di farne l' upload, di nuovo attraverso i driver da parte di un processo di controllo )
o in alternativa può essere il sistema operativo a farlo, allora l' OS dovrà supportare protocolli di clustering e thread migration cluster-wise
ma quello che tutti questi casi hanno in comune è che in nessuno dovresti vedere processori (logici) aggiuntivi nel task manager, perchè non si tratterebbero di processori "locali"

in questo senso, far girare codice preesistente con minime modifiche è un notevole vantaggio rispetto all' alternativa finora disponibile - doverlo rivedere integrarlmente per migrarlo a soluzioni GPGPU con annesso cambio di paradigma, cosa che in effetti equivale a un progetto sw a sè stante

sono daccordo... il punto era: essendo molto vicini ad un x86 completo tuttavia creare una scheda che facesse anche quello che dicevo io avrebbe permesso anche di sfondare un altro mercato :D con conseguente aumento dei profitti schede del genere andrebbero a ruba..

L'efficacia di queste schede non si sta neppure a discutere.con questo Intel ha superato se stessa.

..no, aspetta, almeno X87 lo sono, se no sarebbero derivati dal 486!
e' un superscalare che dovrebbe avere almeno una FPU e comunque le SMID 512 sono null'altro che le sse4.1 (dubito nativo sull'X64... probabile che il compilatore dissassembli il codice?).
poi non ho capito perche' ne considerano 60 quando se ne contano 64.
i restanti 4 sono per il coordinamento?

comunque sono giocattolini carini...

in questo documento sembra che sia appunto un x86 e non un x86-64:
http://software.intel.com/sites/default/files/article/299022/fp-control-2012-08.pdf
anche se poi la distro che viene applicata e' su kernel 64bit....
discrepanze..

Questa e' uns scheda video che viene vista come molte cpu ?
Cio' se la installo su windows seven la posso usare per fare dei render che usano la parallelizzazione dei calcoli ?
O la posso instllar ein windows seven ma alla fine comunque bisogna avere un programma scritto per lei se no non si puo' usare in modo adeguato ?

Grazie ciao

http://software.intel.com/en-us/articles/programming-and-compiling-for-intel-many-integrated-core-architecture
magari cosi' e' piu' chiaro...

no, non la puoi usare come periferica di rendering se non hai un programma che ne sfrutta la sua abilita' nei calcoli.

hai windows sulla WS in cui e' istallata questa scheda;
hai un programma che comunica con questa scheda e da' nozione del lavoro che vuoi far fare a questa scheda;
la distribuzione REALE e non virtuale che e' istallata sulla scheda rispondera' come se fosse un server cluster di calcolo;
sulla scheda dev'essere istallato una appendice del software che operi i calcoli che il tuo software di rendering gli ha affidato, sfruttando, con le giuste API, la potenza di calcolo.

e' un server nella tua WS, ma devi istruirlo....
quindi se non c'e' il software d'appoggio non ci fai nulla.

puo' essere programmata nativamente, ma credo solo per ricerca e non per uso professionale (e chi ti si mette a programmarla direttamente per fare un rendering! il solo software ti costa un occhio della testa!)

nella pratica devi aspettare software commerciali che sfruttano tale soluzione (che siano basati su openCL, openGL o nativi).

sembrava troppo bello avevo capito che il software era gia' preinstallato e vedeva qualunque applicazione in automatico .Ma se fosse cosi Intel non venderebbe piu' workstation per render farm..... ;) Pero' un amico che e' un genio che lavora in un agenzia spaziale americana , forse lui.... :D

Questo è un capolavoro, Intel riesce a competere contro le GPU top di gamma con una CPU x86, un primo passo per poter arrivare anche al desktop.

Ah è che l'avevo letto nella news

diciamo allora una via di mezzo?
per niente. Sono 60 core general purpose x86 su unico die, non ci . E a scanso di equivoci tutta quella potenza bruta non è certamente dovuta ai Pentium Pro, architettura del 1995 se non sbaglio...e neanche il consumo.
Sfruttare solo le istruzioni SSE è persino deletiero.. 8 core sb da 3 GHz sono equivalenti a 24 core SB a 1 GHz nell'ipotesi, non tanto errata, di uno sfruttamento totale delle risorse. Ma ci sono cpu da 16 core e 2,3GHz basate su SB...e quindi circa 36 core a 1GHz.
Un core SB va sicuramente meglio di due, ma anche 3 core Pentium Pro. Il fatto che non si possa sfruttare il nuovo coprocessore con applicazioni odierne lo vedo come un non problema. Il fatto che persino nell'ipotesi favorevole, di calcoli fortemente threaded, i Pentium escono battuti, la dice lunga sul come deve essere sfruttata questo XEON PHI.
Questa scheda praticamente è un array di SIMD a 512 bit gestite ciascuno da un core x86. I calcoli veri li farà la SIMD.
pregio principale di questa soluzione è che per sfruttare le prestazioni in virgola mobile non è necessario usare decine di migliaia di cpu basate su architetture mastondontiche come SB o Bulldozer.

per niente. Sono 60 core general purpose x86 su unico die, non ci . E a scanso di equivoci tutta quella potenza bruta non è certamente dovuta ai Pentium Pro, architettura del 1995 se non sbaglio...e neanche il consumo.
Sfruttare solo le istruzioni SSE è persino deletiero.. 8 core sb da 3 GHz sono equivalenti a 24 core SB a 1 GHz nell'ipotesi, non tanto errata, di uno sfruttamento totale delle risorse. Ma ci sono cpu da 16 core e 2,3GHz basate su SB...e quindi circa 36 core a 1GHz.
Un core SB va sicuramente meglio di due, ma anche 3 core Pentium Pro. Il fatto che non si possa sfruttare il nuovo coprocessore con applicazioni odierne lo vedo come un non problema. Il fatto che persino nell'ipotesi favorevole, di calcoli fortemente threaded, i Pentium escono battuti, la dice lunga sul come deve essere sfruttata questo XEON PHI.
Questa scheda praticamente è un array di SIMD a 512 bit gestite ciascuno da un core x86. I calcoli veri li farà la SIMD.
pregio principale di questa soluzione è che per sfruttare le prestazioni in virgola mobile non è necessario usare decine di migliaia di cpu basate su architetture mastondontiche come SB o Bulldozer.

Sbagli di grosso, 8 cores da 3Ghz equivalgono 24 da 1Ghz ? nemmeno col binocolo, l'aumento di frequenza non porta ad un proporzionale aumento di IPC perchè la banda di memoria e le allocazioni dei registri interni sono "limitati" e vi sono colli di bottiglia dovuti alle varie latenze di funzionamento, la cosa in genere vale fino ad una certa frequenza.

Se così fosse allora gli xeon e gli opteron da 12-16 cores dotati ovviamente di frequenze molto minori sono inferiori sarebbero inutili Invece un Opteron Interlagos a 16 cores da 2.1Ghz come IPC assoluto è superiore ad un FX8350 ( 8 cores a 4.2Ghz ).

Sono cores basati sui Pentium Pro ma una banda passante di 320GB/s a bassissima latenza e dotato delle tecnologie attuali.

Ma è Larrabee? :stordita:

Così a prima vista non mi sembra entusiasmante , 60 core che devono condividere 8 Gb (ed immagino un cache non certo abbondante) .
Comunque prima di dare giudizi aspetto dei benchmark di qualche genere .

Anche senza aspettare i bench con quella cifra si comprano 4 cpu opteron a 16 core = 64 , e non credo che si possa dubitare sulla superiorità di questa soluzione .

sicuramente la ricerca e particolari ambiti specifici ne beneficieranno

quelli professionali a meno che non siano molto legati all'informatica e alla possibilità di scriversi software da se dubito :\

l'idea mia poteva essere tranquillamente messa in pratica xo' .) ne avrebbero vendute a pacchi

si sente l'esigenza in alcuni casi di avere una mini workstation con molta potenza di calcolo

tanto più che con buona disponibilità di ram e ssd si finisce facilmente cpu bound

:(

che poi morale della favola non ho capito una cosa...

siamo daccordo ovviamente non si programmerà in cuda... opencl si? oppure no perchè non è una scheda da usare come gpugpu?

Ma è Larrabee? :stordita:

Esatto.

Così a prima vista non mi sembra entusiasmante , 60 core che devono condividere 8 Gb (ed immagino un cache non certo abbondante) .
Comunque prima di dare giudizi aspetto dei benchmark di qualche genere .

Anche senza aspettare i bench con quella cifra si comprano 4 cpu opteron a 16 core = 64 , e non credo che si possa dubitare sulla superiorità di questa soluzione .

Veramente una GPU solitamente esprime in virgola mobile potenza nettamente superiori rispetto alle cpu classiche x86, anche 100 volte di più, comprare 4 opteron interlagos è inutile, verrebbero asfaltati a mani basse in questo tipo di mansioni.
Il fatto che Intel sia riuscito ad un primo colpo a competere in questo campo con un chip x86 è qualcosa di straordinario visti anche i margini di sviluppo che ci saranno sia nella programmazione che nell'hardware.

Esatto.



Veramente una GPU solitamente esprime in virgola mobile potenza nettamente superiori rispetto alle cpu classiche x86, anche 100 volte di più, comprare 4 opteron interlagos è inutile, verrebbero asfaltati a mani basse in questo tipo di mansioni.
Il fatto che Intel sia riuscito ad un primo colpo a competere in questo campo con un chip x86 è qualcosa di straordinario visti anche i margini di sviluppo che ci saranno sia nella programmazione che nell'hardware.

Non stiamo parlando di una gpu , sono 60 core x 86
, non credo che questa soluzione entri in competizione con le soluzioni tesla o fire pro , a meno che oltre ai 60 core x 86 siano state integrate unita di calcolo particolari e dalle potenzialità non ancora note.

Comunque sicuramente in alcuni ambiti sarà molto valida e magari col tempo potrà arrivare qualcosa per il settore desktop dalle cifre umane .

Così a prima vista non mi sembra entusiasmante , 60 core che devono condividere 8 Gb (ed immagino un cache non certo abbondante) .
Comunque prima di dare giudizi aspetto dei benchmark di qualche genere .

Anche senza aspettare i bench con quella cifra si comprano 4 cpu opteron a 16 core = 64 , e non credo che si possa dubitare sulla superiorità di questa soluzione .

la soluzione della controparte nvidia e amd hanno meno memoria e una quantita di cache nettamente inferiore, parlamo di 1,65MB di cache L2 per Kepler GK110 contro 30MB della soluzione intel che quindi per certi workflow sara nettamente avvantagiata.

4 cpu opteron a 16 core no vanno certo veloci come 1 singola scheda come questa nei calcoli a doppia precisione e consumano anche piu del doppio . Senza andare nei dattagli il sistema da te proposto amd ha 32 unita vettoriali a 256bit mentre questa singola scheda ne ha 60 da 512bit peraltro piu performanti per il tipo di calcolo richiesto.

Tanto per farti un esempio dei banchmark pubblicati da intel 1 scheda xeon phi è circa 2,5x piu veloce di un batteria di 2 xeon di ultima generazione nel classici test Linpack.

la soluzione della controparte nvidia e amd hanno meno memoria e una quantita di cache nettamente inferiore, parlamo di 1,65MB di cache L2 per Kepler GK110 contro 30MB della soluzione intel che quindi per certi workflow sara nettamente avvantagiata.

4 cpu opteron a 16 core no vanno certo veloci come 1 singola scheda come questa nei calcoli a doppia precisione e consumano anche piu del doppio . Senza andare nei dattagli il sistema da te proposto amd ha 32 unita vettoriali a 256bit mentre questa singola scheda ne ha 60 da 512bit peraltro piu performanti per il tipo di calcolo richiesto.

Tanto per farti un esempio dei banchmark pubblicati da intel 1 scheda xeon phi è circa 2,5x piu veloce di un batteria di 25 xeon di ultima generazione nel classici test Linpack.
Se sono già noti dati come questi allora non ci sono dubbi sull'utilità del prodotto.

Quindi integrano unita simd a 512 bit , che superano i 256 bit delle avx contenute nelle cpu xeon .

Non stiamo parlando di una gpu , sono 60 core x 86
, non credo che questa soluzione entri in competizione con le soluzioni tesla o fire pro , a meno che oltre ai 60 core x 86 siano state integrate unita di calcolo particolari e dalle potenzialità non ancora note.

Comunque sicuramente in alcuni ambiti sarà molto valida e magari col tempo potrà arrivare qualcosa per il settore desktop dalle cifre umane .

Certo che sì, è nato apposta per competere contro i top di gamma di Tesla e Fire Pro e dai primi bench sembra ottima.
Quello che esalta è il fatto che Intel è riuscita a farlo con un architettura x86 al primi colpo, cosa considerata quasi impossibile.

Ecco una serie di benchmark contro una piattaforma Dual Xeon E5 2670

http://media.bestofmicro.com/F/O/359556/original/Intel%20Xeon%20Phi%202012%20Benchmark%20Performance%20Examples.PNG

ll tutto con un linguaggio di programmazione proprietario ancora agli albori, potrebbe migliorare parecchio.

Se sono già noti dati come questi allora non ci sono dubbi sull'utilità del prodotto.

Quindi integrano unita simd a 512 bit , che superano i 256 bit delle avx contenute nelle cpu xeon .

eratto per citarti altre caratteristiche non standard di questi 60 core x86 sappi che supportano 4 threads per core quindi la scheda da 60 core fa girare al suo interno ben 240 thread separati.

..oltre al fatto che creare un sistema a 4 vie x86 costa un obbrobio ed e' limitato; non e' ne espandibile ne depotenziabile (cioe' se lo fai a 4 vie devi prendere una scheda a 4 vie e no la puoi usare a 2 o a 3 vie soltanto... sempre 4! e poi devi pensare anche al parco "schede" che lo popolano).
questo server cluster, invece, e' espandibile quanto ti pare, in quanto servono solo i PCI-ex 16X per metterlo su, e schede a una sola via con 4 o 8 PCI-ex (condita anche dai vetusti nf200), non e' difficile trovarle a basso prezzo.
la loro effettiva utilita' sara comunque in abbinamento con le mini-itx atom monocore a basso consumo:
una mini-itx, una larrabee;
in un'armadio standard xU3 ce ne andrebbero almeno 24... un cluster decisamente potente, economico e parco nei consumi se confrontato con un sistema da 24 GPGPU, difficile anche da inizializzare.

non credo che sia la soluzione piu' potente, ma sicuramente e' la piu' versatile (sulla carta) fino ad oggi.

rimango perplesso per i 64bit e la doppia precisione...
a quanto ricordo il prototipo era solo a singola precisione (il che lo depotenziava parecchio per alcuni filoni lavorativi).

ah.. chi la immagina come GPU per videogiochi... in raytracing.
credo che per egualiare la potenza di una semplice console ci vorrebbero 2 o 3 di queste.

ma la tecnologia va' avanti.. l'anno prossimo potrebbero uscirsene con una versione a 14nm che conta 512 core...

mi ripeto: e' una porcheria usare il codice X86 per queste cose, ma e' talmente semplice.

rimango perplesso per i 64bit e la doppia precisione...
.

in che senso perplesso?
i 60 core sono a 32bit perche non servirebbe altro visto che il loro scopo è quello di eseguire codice di controlle ma la vera esecuzione viene fatta dal simd a 512bit. Per la doppia precisione la scheda ha un rapporto di 2:1 fra SP to DP.

ah.. chi la immagina come GPU per videogiochi... in raytracing.
credo che per egualiare la potenza di una semplice console ci vorrebbero 2 o 3 di queste.

ma la tecnologia va' avanti.. l'anno prossimo potrebbero uscirsene con una versione a 14nm che conta 512 core...

mi ripeto: e' una porcheria usare il codice X86 per queste cose, ma e' talmente semplice.


E dove l'hai visto questo scusa ?
Larrabee come progetto iniziale era visto come una GPU per desktop che è saltato poi perchè la tempistica d'uscita non è stata quella aspettata e nel frattempo uscirono HD5870 e GTX480 quindi non avrebbe stato competitivo, aveva una potenza elaborativa simile a quella di una GTX280, dubito che le GPU usate nelle attuali console possano risultare superiori.

Usare l'x86 per queste cose non è una porcheria per Intel, è chiaro che un colosso come Intel leader assoluto nel mondo x86 non si lascerà sopraffare dalle nuove architetture quindi cercherà di portare l'x86 a compere sia contro le GPU che contro gli ARM.

Io penso che Intel continui ad investire in questo tipo di soluzioni perché, almeno al momento, continua ad essere molto indietro rispetto ai rivali nVidia ed Amd.

Se questi prodotti riusciranno a sviluppare prestazioni adeguate e le software house decideranno di ottimizzare alcuni prodotti specialistici per poterne trarne vantaggio, direi che è una cosa positiva per tutti, dato che significa più concorrenza.

In ogni modo io non credo che usando questo tipo di approccio sia possibile, neanche in un prossimo futuro, la produzione di un dispositivo sufficientemente economico per usi più diffusi, neanche volendo.

In ogni modo io non credo che usando questo tipo di approccio sia possibile, neanche in un prossimo futuro, la produzione di un dispositivo sufficientemente economico per usi più diffusi, neanche volendo.

la scheda proposta oggi ha prestazioni e prezzi in linea con i 2 concorrenti, che problemi di costo vedi se gia oggi sono appunto allineanti con i concorrenti e gia sono stati prentati i primi sistemi HPC gia funzionanti?

Considera che il sistema con il miglior rendimento potenza/w dell'intera lista dei top 500 è propio uno basato su questa nuova generazione intel. Quindi un buon inizio direi.

..no, aspetta, almeno X87 lo sono, se no sarebbero derivati dal 486!ricontrollato... ricordavo male, my fault :O
in effetti ha due pipeline, una con ALU normale e una con ALU intera/ SIMD /FP X87 appunto..
in questo documento sembra che sia appunto un x86 e non un x86-64:su quello sono perplesso anch' io, avendo la/e scheda/e da 8 GB di memoria GDDR5 a salire, come sarebbe indirizzata?

An Overview of Programming for Intel® Xeon® processors and Intel® Xeon Phi™ coprocessors (http://software.intel.com/en-us/articles/an-overview-of-programming-for-intel-xeon-processors-and-intel-xeon-phi-coprocessors)
Per approfondire un po' l'argomento.

Si tratta di core a 64 bit.
D'altra parte le nuove estensioni SIMD fanno utilizzo di un opcode (quello dell'istruzione BOUND) rimosso da AMD da x64, adesso utilizzato come prefisso per quasi tutte le nuove istruzioni.
Viene utilizzato anche il prefisso introdotto dalle estensioni AVX per la manipolazione degli 8 nuovi registri di maschera (k0..7).

Si tratta di core simili a quelli di Atom, anch'essi derivati (per lo meno concettualmente) dal Pentium, quindi in-order, ma con la caratteristica di poter eseguire un'istruzione "scalare" (general-purpose) e una vettoriale (LNI) per ciclo di clock (le vector store, però, vengono eseguite dalla pipeline "scalare").

Non si tratta di un progetto simile alle GPU. Hanno provato, con Larrabee, a competere in questo campo, e hanno fallito.
Successivamente, e questo è finalmente il prodotto commercializzato, hanno deciso di modificarlo per puntare al GPGPU Computing, verso il quale direi che ci siano ottime prospettive.

.....veramente.... Intel ha da almeno 10 anni la tecnologia per fare cose come questa, solo che puoi permetterti di aspettare se sei l' incontrastato leader di mercato e fai pagare una cpu X volte tanto la sua versione più economica, identica all'altra ma con qualche feature deliberatamente bloccata....
Stesso discorso vale per Nvidia e AMD.
CI vediamo tra 2 anni....
Il futuro è ARM.:banned:

Fammi un fischio quando ARM presenterà una soluzione comparabile/competitiva con questa di Intel...

Fammi un fischio quando ARM presenterà una soluzione comparabile/competitiva con questa di Intel...

Parlano tutti di ARM ma non ha le risorse di Intel.

Nemmeno AMD le aveva, eppure ha tirato fuori tanti bei processori: K5, K6, Athlon, per non parlare poi della nuova architettura a 64 bit x64 (ex AMD64) e della linea di processori server Opteron.

ARM ha notevoli risorse (credo più di AMD negli ultimi anni), anche perché si è dedicata interamente alla progettazione delle CPU, lasciando ai partner/client l'implementazione ed eventuale personalizzazione dei core.

Ma il punto è che ARM ha sposato da sempre la filosofia RISC, tranne per soluzioni come Thumb e, soprattutto, Thumb-2, che sono a tutti gli effetti dei progetti CISC (hanno opcode a lunghezza variabile, caratteristica che li ha sempre distinti dai RISC).

Mentre Intel (e AMD) lavorano da tantissimo tempo con x86, che è un'architettura CISC. Per quanto possa essere "brutta" e con tutte le problematiche "legacy" che si porta dietro (ho scritto parecchi articoli solo per questo, di recente), ha il vantaggio di possedere una codifica degli opcode a lunghezza variabile (oltre a operazioni che possono indirizzare direttamente la memoria, con modalità d'indirizzamento complesse) che le ha consentito di sopravvivere e, alla fine, dominare sui RISC, grazie alle notevoli prestazioni.

E' questa flessibilità che le ha consentito di mettere in piedi progetti come questo (Knights Corner) sulla base della precedente Larrabee, e che altre architetture RISC non si possono permettere (a meno di abbandonare la macrofamiglia RISC e abbracciare quella CISC).

Infatti se andate a controllare nel manuale dell'architettura, potete vedere che le nuove istruzioni fanno uso di un "mega prefisso" di 4 byte (l'ex opcode BOUND, a cui seguono 3 byte che si portano dietro un bel po' di informazioni ed "estensioni" dell'opcode a cui sono applicate), poi c'è il byte dell'opcode vero e proprio, il byte utilizzato per indirizzare la memoria (ci sono due operandi per la precisione: un registro e una locazione di memoria oppure un altro registro), un eventuale altro byte per specificare una modalità d'indirizzamento più complessa (registro base + registro indice * dimensione + offset), gli eventuali i byte dell'offset per indirizzare la memoria, e infine un altro byte con un valore immediato a 8 bit che è presente soltanto per alcune istruzioni che ne fanno uso.

Questo si traduce in istruzioni lunghe minimo 6 byte, ma che hanno il vantaggio di poter specificare una qualunque locazione di memoria per uno degli operandi sorgente, il che consente di risparmiare un'istruzione di load e relativa dipendenza, oltre che un registro in meno da "sporcare" per memorizzare il risultato della load, rispetto a un'equivalente RISC (che, conti alla mano, finirebbe per richiedere più istruzioni e occupare più spazio per fare la stessa cosa).

Senza contare poi le "goodies" che Intel ha aggiunto proprio nell'indirizzamento della memoria: broadcast del valore letto, oppure conversione di tipo (es: conversione da intero a 8 bit con segno intero a 32 bit con segno) al volo, senza bisogno di ulteriori istruzioni, e questo specificabile direttamente in OGNI istruzione della nuova unità SIMD. Le istruzione vere e proprio di load/store consentono, invece, parecchie altre operazioni di conversione (quelle del normale indirizzamento sono 4: le più diffuse per interi o valori in virgola mobile); senza contare poi le operazioni di gather e scatter.

Un RISC che ha un opcode fisso di 32 bit, in cui deve farci stare tutto: istruzioni general purpose e quelle dell'unità SIMD, per cui i progettisti sono costretti a fare un po' di economia sugli opcode e, quindi, sulle istruzioni eseguibili, che hanno per forza di cose dei limiti.
Basti vedere come ARM abbia dovuto riprogettare completamente l'ISA per aggiungere i 64 bit, togliendo di mezzo alcuni cavalli di battaglia dei processori ARM (tutte le istruzioni erano condizionali; istruzioni di load/store multiple di registri, e altro che al momento non mi viene in mente) per far spazio ai 32 registri (quasi) general purpose che ha introdotto; e idem (prima erano soltanto 16) per l'unità SIMD potenziata.
Non poteva fare altrimenti: i bit contano, e quindi certe scelte vanno sempre a scapito di qualcos'altro. Il che, tradotto, vuol dire istruzioni più semplici, in termini di lavoro "utile" eseguibile per la nuova ISA.

Quel che voglio dire, alla fine, è che un CISC consente di eseguire molto più lavoro "utile" per ogni singola istruzione eseguita, e ciò può portare (e con x86 abbiamo visto che... succede!) a prestazioni complessivamente più elevate rispetto a un RISC.
Questo, però, a scapito dei decoder, che sono di gran lunga più complicati rispetto ai RISC, e che richiedono oltre a milioni di transistor in più, consumi molto più elevati.

D'altra parte, tutto è frutto di compromessi. Non esiste l'uovo di Colombo. O forse deve ancora arrivare... ;)

Quel che voglio dire, alla fine, è che un CISC consente di eseguire molto più lavoro "utile" per ogni singola istruzione eseguita, e ciò può portare (e con x86 abbiamo visto che... succede!) a prestazioni complessivamente più elevate rispetto a un RISC.
Questo, però, a scapito dei decoder, che sono di gran lunga più complicati rispetto ai RISC, e che richiedono oltre a milioni di transistor in più, consumi molto più elevati.

D'altra parte, tutto è frutto di compromessi. Non esiste l'uovo di Colombo. O forse deve ancora arrivare... ;)

sono anni che leggo critiche incondizionate sulla tecologia cisc basate principalmente sull'ignoranza o sul fatto che risc è "ovviamente" superiore , il tuo post l'ho condivido pienamente bravo.

Non mi sento nemmeno di biasimare chi fa queste affermazioni. Erano idee che condividevo anch'io, fino a quando non ho cominciato ad avere a che fare seriamente con queste problematiche.

Non si può pretendere che tutti studino le architetture dei processori o che ne progettino qualcuna. Credo che ognuno abbia delle proprie inclinazioni / hobby che segue, e per i quali spende il proprio tempo.

Ciò non toglie che, di fronte ad alcune informazioni, chi ha avuto la possibilità di dedicarsi alle architetture, faccia sentire la propria opinione se rileva delle cose non esatte. Nella speranza che, alla fine, emergano e si facciano strada i concetti e le idee corrette.

vedremo i prossimi Atom 22nm di Intel

Parlano tutti di ARM ma non ha le risorse di Intel.

dal Company Profile di ARM:
"Over 20 billion ARM based chips shipped to date"

per avere i numeri di Intel, dividi per 10......

Cosa non ti è chiaro del concetto di "risorsa" (finanziaria, s'intende) e di quello di "pezzi venduti" (consegnati, in realtà)?

Se si parla di risorse, perché tiri fuori il numero di pezzi di processori ARM venduti (sotto licenza della casa madre)?

Sono due cose completamente diverse, che non c'entrano proprio nulla.

Fammi un fischio quando ARM presenterà una soluzione comparabile/competitiva con questa di Intel...

Simon Segers, presidente di arm, marzo 2012:

“Supercomputers, for ARM, is not a high volume market, it’s not something we spend a lot of time talking about. Ours is a business that is royalty and unit driven, so we’re interested in high-volume markers.”

E' per questo che aspettano a spazzare via intel:read: :Prrr:

@mazinga
per risorse si intende risorse tecnologiche. I dindi non si fanno con la ricerca, ma con la commercializzazione, vedi tordi che comprano a 729 euro un cinafonino che a prodursi ne costa 100.....:asd:

Ho una discreta conoscenza della lingua inglese, ma mi sembra che quello che hai riportato non c'entri proprio nulla con la frase che avevo scritto prima.

Libero di smentirmi, ovviamente.

EDIT. Ho visto che hai editato il tuo messaggio, aggiungendo altro.

Le risorse tecnologiche sai da dove arrivano? Da quelle finanziarie. Se non hai soldi, non puoi investire in ricerca. Mi sembra lapalissiano.

Comunque le tue battutine sul mio avatar dimostrano che sei a corto di argomenti. Com'era facile intuire, vista la "consistenza" delle tue affermazioni...

diciamo che se mi trovi un utilizzo della suddetta scheda che non sia in ambito "supercomputer" te ne fo trovare una sotto l'albero di natale:mc:


EDIT. Ho visto che hai editato il tuo messaggio, aggiungendo altro.

-Le risorse tecnologiche sai da dove arrivano? Da quelle finanziarie. Se non hai soldi, non puoi investire in ricerca. Mi sembra lapalissiano.



a mazzi', nun vorrai mica incominciare un flame?

E ARM, che non fa altro che ricerca, non avrebbe il danaro da investire? Mi sembri allampanato.

Stai nuovamente cambiando argomento. Inoltre le faccine che usi sono un chiaro segnale del tuo disagio nel proseguire in una discussione spinosa in cui ti sei andato a cacciare.

Ciò detto, queste schede non servono esclusivamente per supercomputer, ma in generale in ambiti in cui servono potenze di calcolo superiori a quelle offerte da un normale server.

Infatti vanno a coprire e competere con le soluzioni già esistenti di AMD e, soprattutto, nVidia. Che non sono certo state realizzate esclusivamente per i supercomputer.

Difatti il titolo della news parla chiaro: GPGPU Computing.

Il fatto che l'evento in cui sono state presentate queste nuove soluzioni sia dedicato ai supercomputer NON implica che sia esclusivamente questo il loro ambito di utilizzo.

Logica (banale) alla mano.

Spazzare via intel fa veramente ridere i polli.

Cortex non è in grado di produrre un chip ARM con IPC lontanamente paragonabile ad un i5, figurati contro un fiammante i7 o gli Entusiasth, ma non spariamo cavolate.

ARM vende ? Si i numeri li fanno ma con mobile dove Intel non c'è ancora ( grazie al piffero ), intel è il big del transistors sotto solo a IBM e volendo potrebbe pagare tutti gli OEM per penalizzare gli ARM e mettere a tacere tutti quanti come ha fatto con AMD.

Inoltre credi veramente che Intel non possa andare molto più di come sta andando ora ? Su desktop non ha concorrenza, se ci fosse sarebbe già ora in grado di accelerare la roadmap di 2 annetti, altro che Haswell ..............

@maz
mah, se vuoi ti dò anche ragione, davvero non riesco a pensare a un utilizzo di queste unità SIMD in un server normale di classe enterprise

@paul
boh, Intel non è altro che un successo di mercato che applica logiche di mercato, se il consumatore si accontentasse venderebbero ancora a caro prezzo i 486.
ARM vende una tecnologia che viene implementata e sfruttata al massimo dalle aziende che ne acquistano la licenza, il suo lavoro è pura ricerca.

Quale delle due logiche è vincente?

Spazzare via intel fa veramente ridere i polli.

Cortex non è in grado di produrre un chip ARM con IPC lontanamente paragonabile ad un i5, figurati contro un fiammante i7 o gli Entusiasth, ma non spariamo cavolate.

ARM vende ? Si i numeri li fanno ma con mobile dove Intel non c'è ancora ( grazie al piffero ), intel è il big del transistors sotto solo a IBM e volendo potrebbe pagare tutti gli OEM per penalizzare gli ARM e mettere a tacere tutti quanti come ha fatto con AMD.

Inoltre credi veramente che Intel non possa andare molto più di come sta andando ora ? Su desktop non ha concorrenza, se ci fosse sarebbe già ora in grado di accelerare la roadmap di 2 annetti, altro che Haswell ..............
A parte ciò, ARM non ha nessuna soluzione che possa competere nel campo del GPGPU Computing.

Questo è un dato di fatto incontrovertibile, che non si può smontare semplicemente perché davanti si ha una tastiera e si può scrivere quel che si vuole...

mah, se vuoi ti dò anche ragione, davvero non riesco a pensare a un utilizzo di queste unità SIMD in un server normale di classe enterprise
E' un tuo limite. Altri (http://openlab.web.cern.ch/sites/openlab.web.cern.ch/files/technical_documents/masteroppgave_Lindal.pdf) non la pensano così. E non sono gli unici...

Per il 2015 sarà tutto ARM:mbe:

dal Company Profile di ARM:
"Over 20 billion ARM based chips shipped to date"

per avere i numeri di Intel, dividi per 10......non vuol dire niente, dal momento che ARM ARM fattura con le royalties - che a quanto pare ammontano al 4.6-4.8% (http://www.eetimes.com/electronics-news/4372693/ARM-dominates-10B-unit-CPU-core-market) del costo dei SoC di terze parti (che esistono in tutte le salse e in tutte le fasce di prezzo - ma anche se si trovano OMAP e SnapDragon da 90...140 $ per chip in lotti da 1000 pezzi, il grosso del mercato è fatto da chip da 20-10-5 $ o anche meno) mentre intel dai chip interi, non da royalties

ora non credo di doverti dire quanto è il 5% di 5 dollari anche moltiplicato per miliardi di unità - infatti il fatturato annuo (http://www.technotizie.net/arm-fatturato-in-crescita-del-13-rispetto-allo-scorso-anno.html) di ARM è stato di 189-210 milioni di dollari

intel, ha fatturato 54 miliardi di dollari nel 2011 e 13 nel terzo trimestre di quest' anno
E ARM, che non fa altro che ricerca, non avrebbe il danaro da investire? Mi sembri allampanato.ne ha ma appunto può dedicarsi alla sola architettura del core sostanzialmente demandando l' implementazione della specifica piattaforma (con tutto ciò che al core fa da contorno) agli OEM, mentre intel dispone di una una divisione operativa a sè per ogni tipo di prodotto (processori , chipset, piuttosto che board, networking, o tool sw) per ogni segmento di mercato (desktop, workstation, server, embedded), ed è attiva a latere in progetti legati alla piattaforma hw nel suo complesso (alimentazione, con specifiche -VRM x- e raccomandazioni -come l' uso di power stage integrati drmos inizialmente caldeggiati proprio da intel, form factors, bus ecc)

prima che ARM spazzi via intel passerà un po' di tempo...

boh, Intel non è altro che un successo di mercato che applica logiche di mercato, se il consumatore si accontentasse venderebbero ancora a caro prezzo i 486.
ARM vende una tecnologia che viene implementata e sfruttata al massimo dalle aziende che ne acquistano la licenza, il suo lavoro è pura ricerca.
Quale delle due logiche è vincente? il mercato ha decretato che è vincente la prima

ok ma quando uscira' una scheda del genere o una soluzione del genere per fare calcoli di grafica 3d che normalemente fa una cpu tipo i7 , esempio per fare render con Eon Vue >?

Grazie ciao

dal Company Profile di ARM:
"Over 20 billion ARM based chips shipped to date"

per avere i numeri di Intel, dividi per 10......

e questo cosa centra con il concetto di "risorse" non è mica arm che li ha venduti quei porcessori li ha solo progettati e in vari casi solo in minima parte che è un tantino diverso.

@maz
mah, se vuoi ti dò anche ragione, davvero non riesco a pensare a un utilizzo di queste unità SIMD in un server normale di classe enterprise

@paul
boh, Intel non è altro che un successo di mercato che applica logiche di mercato, se il consumatore si accontentasse venderebbero ancora a caro prezzo i 486.
ARM vende una tecnologia che viene implementata e sfruttata al massimo dalle aziende che ne acquistano la licenza, il suo lavoro è pura ricerca.

Quale delle due logiche è vincente?

Xeon Phi nasce appunto anche per contrastare ARM nel campo server.

ARM rispetto agli x86 vanta solamente il rapporto prestazioni / watt, e riscuote successo nel mobile per questo motivo e anche nel campo server se usato in configurazioni ad alto numero di cores, ma questo non cambia il fatto che non è in grado di raggiungere IPC per core paragonabili agli Intel.

Intel con Phi ha fatto usato lo stesso approccio, ha piazzato un chip con molti cores a basso IPC e il risultato c'è e si stan evolvendo pure loro, resta da vedere chi dei 2 ha più margine di sviluppo, essendo il primo progetto basato su tale concezione, con un linguaggio di programmazione ancora nemmeno definito e i 14nm 3gate alla porta non scherzano.

ok ma quando uscira' una scheda del genere o una soluzione del genere per fare calcoli di grafica 3d che normalemente fa una cpu tipo i7 , esempio per fare render con Eon Vue >?

Grazie ciao

è il motore di rendering che deve essere edattato (se possibile) alla gestione via gpgpu quindi devi andare a vedere cosa fa il produttore. Per esempio io usa 3dsmax e li il motore iray usa le cpu o la gpu se presente ma è nato specificatamente per questo scopo e guardacaso è stato fatto da nvidia solo per le sue schede video e solo in cuda.

In generale pero sappi che usare la gpu introduce vantaggi e svantaggi e solo certi algoritrmi sono adattabili mentre altri è praticamente impossibile nemmeno pensarlo.

Xeon Phi nasce appunto anche per contrastare ARM nel campo server.

ARM rispetto agli x86 vanta solamente il rapporto prestazioni / watt, e riscuote successo nel mobile per questo motivo e anche nel campo server usato in configurazioni ad alto numero di cores, ma questo non cambia il fatto che non è in grado di raggiungere IPC per core paragonabili agli Intel.


in realta arm non ha mai fatto una cpu che venisse usata in nessun server nemmeno nei microserver, per questo devi aspettare almeno il 2014 con la nuova serie a 64bit.

in realta arm non ha mai fatto una cpu che venisse usata in nessun server nemmeno nei microserver, per questo devi aspettare almeno il 2014 con la nuova serie a 64bit.

Si ci aspetta dal top di gamma A57 prestazioni del +20% rispetto agli attuali A15.

E di certo entro il 2014 Intel spingerà al massimo su Phi, sul suo linguaggio di programmazione e con se occorre ricomincieranno le pressioni verso i venditori.

@maz
mah, se vuoi ti dò anche ragione, davvero non riesco a pensare a un utilizzo di queste unità SIMD in un server normale di classe enterprise

@paul
boh, Intel non è altro che un successo di mercato che applica logiche di mercato, se il consumatore si accontentasse venderebbero ancora a caro prezzo i 486.
ARM vende una tecnologia che viene implementata e sfruttata al massimo dalle aziende che ne acquistano la licenza, il suo lavoro è pura ricerca.

Quale delle due logiche è vincente?

bah, io ce li vedo benissimo in sistemi hpc o workstation da calcolo dove la capacità di eseguire efficacemente codice general purpose le rende molto più adatte delle classiche gpu dove se non si riesce a parallizzare molto / hai molte istruzioni logiche non rendono

Inoltre dai tuoi discorsi è palese il fatto che non hai una buona conoscenza dell'argomento ne conosci le architetture arm ne per cosa vengono utilizzate (credi veramente che siano gli smartphone il core business di arm? ) credi veramente che un architettura arm sia adatta ad ambiti di hpc / supercomputer?

Inoltre sei invitato, e questa è un ammonizione ad usare un tono più tranquillo e meno supponente, visto che il modo in cui ti poni non giova di certo alla discussione

Si ci aspetta dal top di gamma A57 prestazioni del +20% rispetto agli attuali A15.

E di certo entro il 2014 Intel spingerà al massimo su Phi, sul suo linguaggio di programmazione e con se occorre ricomincieranno le pressioni verso i venditori.
Ma ARM64 non nasce per competere con Xeon Phi, quanto con gli Xeon "classici".

Ad ARM è sempre mancata una soluzione server, e questo significa mettere a disposizione i 64 bit, che sono arrivati appunto con ARM64.

Xeon Phi nasce per competere sul fronte GPGPU Computing, che in parte si interseca coi server, ma concettualmente è un altro tipo di prodotto.

Ma ARM64 non nasce per competere con Xeon Phi, quanto con gli Xeon "classici".

Ad ARM è sempre mancata una soluzione server, e questo significa mettere a disposizione i 64 bit, che sono arrivati appunto con ARM64.

Xeon Phi nasce per competere sul fronte GPGPU Computing, che in parte si interseca coi server, ma concettualmente è un altro tipo di prodotto.

Si ma ARM comunque come concetto server sfrutterà un concetto basato su un numero molto alto di thread, praticamente non è lo stesso di Phi ? Non credo conti molto la prestazione per core se coinvolgiamo ARM quanto il MT pesante dove poi ci si mette pure l'efficienza energetica, gli Xeon classici sono basati su Ivy Bridge e non credo vi siano speranze, quindi a questo punto ARM non è come Phi ? Parliamo sempre di un x86 quindi in grado di eseguire qualunque tipo di calcolo.

Dove sbaglio ?

(credi veramente che siano gli smartphone il core business di arm? ) credi veramente che un architettura arm sia adatta ad ambiti di hpc / supercomputer?


si e si (barcelona supercomputer dice niente?) (http://www.wired.com/wiredenterprise/2012/04/barcelona/)

Arm guadagna sulle licenze per processore e il prezzo è fatto sulla base del valore percepito, che fa si che un A7 costi meno di un A15.
Perciò mi sembra logico che preferiscano che si producano svariati miliardi di chip per telefonini/controller per hd etc piuttosto che qualche milione di chop per server o console (es cell di IBM).
Il fatto che queste informazioni derivino da un'intervista al presidente stesso di ARM potrebbe anche contare qualcosa.
Forse?

bah, io ce li vedo benissimo in sistemi hpc o workstation da calcolo dove la capacità di eseguire efficacemente codice general purpose le rende molto più adatte delle classiche gpu dove se non si riesce a parallizzare molto / hai molte istruzioni logiche non rendono
2500 dollari per la versione di partenza di una scheda con sistema operativo precaricato e istruzioni proprietarie?
Se ti metti in coda ne fo recapitare una anche a te, da usare esclusivamente come stufetta:asd:

Si ma ARM comunque come concetto server sfrutterà un concetto basato su un numero molto alto di thread, praticamente non è lo stesso di Phi ? Non credo conti molto la prestazione per core se coinvolgiamo ARM quanto il MT pesante dove poi ci si mette pure l'efficienza energetica, gli Xeon classici sono basati su Ivy Bridge e non credo vi siano speranze, quindi a questo punto ARM non è come Phi ? Parliamo sempre di un x86 quindi in grado di eseguire qualunque tipo di calcolo.

Dove sbaglio ?
Non mi pare che sia così. ARM64 dovrebbe avere core non dotati di supporto all'hardware threading (Hyperthreading, CMT, o roba simile a Xeon Phi/Larrabee). Core "normali", insomma.

Quindi ARM64 si posizionerà nella stessa fascia di mercato degli attuali Xeon.

Il vantaggio di ARM64 dovrebbe essere dato dalla possibilità di impacchettare più core normali a parità di silicio utilizzato, rispetto a x64. Questo perché x64 si porta dietro la "x86 tax", che richiede milioni di transistor per la sola decodifica delle istruzioni, rispetto a un processore RISC.

Tutti quei transistor possono essere impiegati per aggiungere qualche nuovo core ARM64, sebbene non sappiamo quanti, perché un core non è certo costituito soltanto dal decoder delle istruzioni, eh!

Comunque anche i core ARM stanno diventando sempre più complessi. ARM64 è retrocompatibile con ARM, perché ha aggiunto una nuova modalità d'esecuzione a 64 bit, esattamente come ha fatto AMD con x64. Questo significa che i decoder devono poter gestire tutte le precedenti modalità d'esecuzione: ARM, Thumb-2, Thumb-EE. Non è certo paragonabile a quello che deve fare x64, ma ha un certo peso (anche nella pipeline).
si e si (barcelona supercomputer dice niente?) (http://www.wired.com/wiredenterprise/2012/04/barcelona/)
Dovresti leggere meglio:

"The Tegra 3 will handle communications between different parts of the system while the actual number crunching will be done by yet-to-be-determined low-power multicore Nvidia graphics processors similar to the GeForce 520MX."

e

"But things get really interesting when Nvidia starts shipping successors to the Tegra 3, including a new 64-bit chip based on a new Cortex A15 design from ARM Holdings. That processor will be able to take on some of the supercomputing workload being done by Ramirez’s GPUs right now and it could give him a real breakthrough in performance: four-times the computer processing for essentially the same 4 watts of power."

Arm guadagna sulle licenze per processore e il prezzo è fatto sulla base del valore percepito, che fa si che un A7 costi meno di un A15.
Il prezzo è fatto sui volumi e/o il tipo di licenza.
Perciò mi sembra logico che preferiscano che si producano svariati miliardi di chip per telefonini/controller per hd etc piuttosto che qualche milione di chop per server o console (es cell di IBM).
Il fatto che queste informazioni derivino da un'intervista al presidente stesso di ARM potrebbe anche contare qualcosa.
Forse?
Che per l'oste il suo vino è buono?

Comunque ARM rimane una piccola realtà paragonata a Intel, proprio a motivo del suo business. Tant'è che potrebbe essere tranquillamente acquisita da qualcuno (tempo fa si parlava di Apple), data la scarsa dimensione (capitalizzazione).
Non lo si fa perché sarebbe un'acquisizione inutile, in quanto il vero potere di ARM è dato proprio da come lavora adesso. Acquisirla per "chiuderla" alla concorrenza farebbe del danno all'acquirente, perché il valore dell'azienda acquisita crollerebbe immediatamente a livelli molto bassi. Soldi buttati, insomma. Come peraltro aveva già spiegato jappilas, se avessi letto con attenzione il suo messaggio...

Per essere chiari, se ho bisogno di un team che mi sviluppi processori ARM "in house", non mi vado a comprare tutta ARM, ma vado a caccia di "teste pregiate" da ingaggiare e far lavorare da me. Che poi è quello che ha fatto Apple, acquisendo P.A. Semi e Intrisity: piccole realtà specializzate nello sviluppo di core (all'epoca PowerPC, ma c'erano ingegneri provenienti da Intel, AMD, ecc.), che adesso tirano fuori i design proprietari dei nuovi core di Apple, con buona pace di Samsung che ormai è ridotta a fungere semplicemente da fonderia, fino a quando Apple non le darà il benservito completo passando a TMSC...
2500 dollari per la versione di partenza di una scheda con sistema operativo precaricato e istruzioni proprietarie?
Cosa ci trovi di strano? ARM non ha le sue istruzioni "proprietarie"? Conosci qualche architettura che non le abbia? Fammi qualche esempio, cortesemente, perché non è affatto chiaro dov'è che vorresti arrivare.
Se ti metti in coda ne fo recapitare una anche a te, da usare esclusivamente come stufetta:asd:
Se non ti va di discutere, evita di scrivere, invece di far ricorso a battutine come questa il cui unico scopo è avvelenare il clima, buttandola in caciara, perché l'argomento ti è indigesto o, molto più probabilmente, non hai le capacità per portarlo avanti...

si e si (barcelona supercomputer dice niente?) (http://www.wired.com/wiredenterprise/2012/04/barcelona/)

Arm guadagna sulle licenze per processore e il prezzo è fatto sulla base del valore percepito, che fa si che un A7 costi meno di un A15.
Perciò mi sembra logico che preferiscano che si producano svariati miliardi di chip per telefonini/controller per hd etc piuttosto che qualche milione di chop per server o console (es cell di IBM).
Il fatto che queste informazioni derivino da un'intervista al presidente stesso di ARM potrebbe anche contare qualcosa.
Forse?

2500 dollari per la versione di partenza di una scheda con sistema operativo precaricato e istruzioni proprietarie?
Se ti metti in coda ne fo recapitare una anche a te, da usare esclusivamente come stufetta:asd:


visto che l'ammonizione non è servita facciamo 5gg per flame

gli Xeon classici sono basati su Ivy Bridge e non credo vi siano speranze, quindi a questo punto ARM non è come Phi ?


gli xeon basati su ivy sono previsti prossimo anno

Phi è un coprocessore quindi non puo prendere le veci di un processore ne x86 ne arm ne altro.

Esattamente. E attenzione a parlare di x86 con Knights Corner, perché mancano delle istruzioni "storiche" / "legacy" (quelle di I/O), quindi non può essere un completo sostituto di un tradizionale processore x86, in quanto alcuni dispositivi richiedono ancora l'uso delle porte di I/O per essere pilotati (anziché mappare i registri in memoria, come ormai si dovrebbe fare da tempo).

gli xeon basati su ivy sono previsti prossimo anno

Phi è un coprocessore quindi non puo prendere le veci di un processore ne x86 ne arm ne altro.

Coprocessore ? è un x86 quindi in grado di svolgere qualunque tipo di calcoli, non è in grado semmai di fornire potenza per ogni thread essendo cores molto elementari tutto quì.

Non mi pare che sia così. ARM64 dovrebbe avere core non dotati di supporto all'hardware threading (Hyperthreading, CMT, o roba simile a Xeon Phi/Larrabee). Core "normali", insomma.

Il vantaggio di ARM64 dovrebbe essere dato dalla possibilità di impacchettare più core normali a parità di silicio utilizzato, rispetto a x64.

Ok ma senza HT, ha comunque 60 cores il Phi in un unico die.

Coprocessore ? è un x86 quindi in grado di svolgere qualunque tipo di calcoli, non è in grado semmai di fornire potenza per ogni thread essendo cores molto elementari tutto quì.
Non è un x86. Come dicevo prima, mancano dei pezzi.

Inoltre per com'è stato concepito e per come viene utilizzato, si tratta di un Co-Processore a tutti gli effetti.
Ok ma senza HT, ha comunque 60 cores il Phi in un unico die.
Certamente, ma Xeon Phi ha pure un multi-threading molto avanzato (ci sono 4 thread hardware per singolo core), perché l'obiettivo è di sfruttare il più possibile le risorse di ogni core. Tenere impegnate le unità di calcolo, per la precisione.

Difatti saranno anche core piccoli, ma non sono elementari, e mettono a disposizione una notevole potenza di calcolo grazie alla nuova, nonché massiccia, unità SIMD integrata.

Mancano dei componenti ?

E allora perchè dicono che è compatibile con le istruzioni x86 ?

Mancano dei componenti ?

E allora perchè dicono che è compatibile con le istruzioni x86 ?
Sì, mancano delle istruzioni, per la precisione: quelle di I/O, caratteristiche di x86 (e dello Z80 :D).

Quindi non può girarci qualunque software x86. Sicuramente non tutti i s.o.; anzi, dubito che i vecchi s.o. possano girarci.

La versione di Linux che gestisce il tutto sarà stata sicuramente adattata per sfruttare soltanto l'I/O mappato in memoria, come avviene con tutte le altre architetture.

Sì, mancano delle istruzioni, per la precisione: quelle di I/O, caratteristiche di x86 (e dello Z80 :D).

Quindi non può girarci qualunque software x86. Sicuramente non tutti i s.o.; anzi, dubito che i vecchi s.o. possano girarci.

La versione di Linux che gestisce il tutto sarà stata sicuramente adattata per sfruttare soltanto l'I/O mappato in memoria, come avviene con tutte le altre architetture.

Ah ok ma siamo sempre in ambito server, magari dovranno essere usati in abbinamento ad uno Xeon classico che si occuperà dell'I/O e della gestione dei moduli Phi ( intendo dire una piattaforma con una cpu e tanti Phi sui PCI-Ex ), non credo cambi molto se valutiamo l'intero rack.

Questo comunque sbaglio o non vuol affatto dire che tale prodotto non possa essere variato per un supporto x86 completo ?

Un conto è magari se mancavano componenti particolarmente esosi da renderne impossibile la realizzazione a causa delle dimensioni che avrebbe avuto il die, ma a livello di istruzioni a questo punto è tale solo per espressa volontà di Intel.

Ah ok ma siamo sempre in ambito server, magari dovranno essere usati in abbinamento ad uno Xeon classico che si occuperà dell'I/O e della gestione dei moduli Phi ( intendo dire una piattaforma con una cpu e tanti Phi sui PCI-Ex ), non credo cambi molto se valutiamo l'intero rack.

Questo comunque sbaglio o non vuol affatto dire che tale prodotto non possa essere variato per un supporto x86 completo ?

Un conto è magari se mancavano componenti particolarmente esosi da renderne impossibile la realizzazione a causa delle dimensioni che avrebbe avuto il die, ma a livello di istruzioni a questo punto è tale solo per espressa volontà di Intel.

sono coprocessori quindi hanno bisogno di un processore, avere un supporto completo imho non è così utile, ovvero questi sono sistemi per calcolo massivo (hpc, workstation da calcolo, mainframe, supercomputer) usati anche in configurazione multipla ma un host ha senso che ci sia

Questo comunque sbaglio o non vuol affatto dire che tale prodotto non possa essere variato per un supporto x86 completo ?

Un conto è magari se mancavano componenti particolarmente esosi da renderne impossibile la realizzazione a causa delle dimensioni che avrebbe avuto il die, ma a livello di istruzioni a questo punto è tale solo per espressa volontà di Intel.
Esattamente. E non penso che Intel torni indietro, perché fino a Larrabee non ho mai letto di istruzioni x86 mancanti. Con Knights Corner / Xeon Phi sì.

Io avrei fatto ben altro. Comunque ormai è andata così...

Esattamente. E non penso che Intel torni indietro, perché fino a Larrabee non ho mai letto di istruzioni x86 mancanti. Con Knights Corner / Xeon Phi sì.

Io avrei fatto ben altro. Comunque ormai è andata così...

in verità non mancano istruzioni solo che i core sono chiusi in una scheda che non parla direttamente con il resto del server quindi sono separati e a gestirli è il linux locale, quindi i core hanno l'IO per quello che gli serve per comunicare con gli altri core il proprio sistema operativo il bus esterno per collegarsi via rete add altre schede phi e la memoria locale.

Ma appunto essendo coprocessori come le schede gpgpu non sono autonome ma richiedono chi le programmi e controlli.
Una cosa e fere un processore con 60 core un altra un comprocessore con 60 core le 2 cose sono molto diverse.

Pag. 657-658 del Knights Corner Instruction Set Reference Manual:
In 64 bit mode, Knights Corner supports a subset of the Intel 64 Architecture instructions. The following sum-marizes Intel 64 Architecture instructions that are not supported in Knights Corner:

• Instructions that operate on MMX registers
• Instructions that operate on XMM registers
• Instructions that operate on YMM registers

GPR and X87 Instructions Not Supported in Knights Corner:

CMOV CMPXCHG16B FCMOVcc FCOMI
FCOMIP FUCOMI FUCOMIP IN
INS INSB INSD INSW
MONITOR MWAIT OUT OUTS
OUTSB OUTSD OUTSW PAUSE
SYSENTER SYSEXIT

La situazione è un po' diversa (http://software.intel.com/en-us/blogs/2012/06/05/knights-corner-micro-architecture-support?page=1).

La modalità a 32 bit è presente, e sembra sia identica a quella del vecchio Pentium. Quindi in grado di eseguire le stesse modalità e istruzioni.

E' la modalità a 64 bit che non è compatibile con quella x64, in quanto mancano quelle istruzioni, e altre cose.

Quindi Xeon Phi è in grado di eseguire il boot come un qualunque s.o. x86 (a 32 bit), ma una volta che passa in modalità a 64 bit è a tutti gli effetti un coprocessore (in quanto incapace di gestire I/O e altro).