Link alla notizia: http://www.businessmagazine.it/news/knights-landing-e-la-futura-gpu-intel-per-il-calcolo-parallelo_52924.html

Anticipate alcune delle caratteristiche tecniche delle soluzioni Xeon Phi della famiglia Knights Landing: oltre 60 core della famiglia Silvermont, la nuova interconnessione Omni Scale Fabric e memorie on package

Click sul link per visualizzare la notizia.

Ho dei seri dubbi sia corretto chiamarle gpu, sono schede (se di scheda si parla e non del chip da inserire direttamente su mobo) acceleratrici per calcolo parallelo, non hanno ne le componenti ne le funzionalità di una gpu.

Detto questo: ma queste soluzioni si usano già o sono ancora dei kit distribuiti più che altro agli sviluppatori per fargli prendere dimestichezza con architettura e api come per le prime versioni?

Ho dei seri dubbi sia corretto chiamarle gpu, sono schede (se di scheda si parla e non del chip da inserire direttamente su mobo) acceleratrici per calcolo parallelo, non hanno ne le componenti ne le funzionalità di una gpu.

Detto questo: ma queste soluzioni si usano già o sono ancora dei kit distribuiti più che altro agli sviluppatori per fargli prendere dimestichezza con architettura e api come per le prime versioni?


se intendi queste nuove versioni credo che siano in mano agli sviluppatori, gli Xeon PHI prima serie invece sono tranquillamente acquistabili.


piu che altro vorrei capire se una volta montate sei socket la ram si somma a quella di sistema e diventa unica o se rimane separata, perchè le Xeon PHI attuali su PCI-EX hanno lo stesso problema delle GPU che devono caricare il tutto nella ram della GPU, niente memoria condivisa :/

ram su cpu? paura!

Questa soluzione fa davvero paura :eek:
Genera più TeraFlops della metà di schede video di fascia medio alta, credo che sia sui livelli di una GTX 770 ed equivalente AMD (prendo le GPU a campione per ovvi motivi)

In un'altra news leggevo che in teoria tutta questa potenza non necessita nemmeno di una revisione del codice (immagino codice comunque scritto per le precedenti versioni di questa scheda).

Davvero tanta roba

Questa soluzione fa davvero paura :eek:
Genera più TeraFlops della metà di schede video di fascia medio alta, credo che sia sui livelli di una GTX 770 ed equivalente AMD (prendo le GPU a campione per ovvi motivi)



no no, qui si parla di 3 TeraFlops Double Precision che è ancora piu paura :D

la FirePro Top gamma S10000 con 2 chip Thaiti fa 1,48 TFlops
la Quadro Top gamma K6000 fa 1,7 TFlops


In un'altra news leggevo che in teoria tutta questa potenza non necessita nemmeno di una revisione del codice (immagino codice comunque scritto per le precedenti versioni di questa scheda).

Davvero tanta roba

ancora meglio, è riferito al codice X86 classico; queste "GPU" hanno i core che sono X86; quindi basta poco per adattare il classico codice X86 a queste schede; deve solo esserci software/calcolo che si presta bene ad essere parallelizzato.

nella prima versione di queste schede erano i core del chip erano i vecchi core del Pentium originale modificati, questa nuova versione sara basata su un massimo di 72 core Silvermont ( gli attuali Atom Bay trail ) modificati per gestire 4 thread per core :eek:

EDIT

sara un mostro di potenza :eekk: :eekk: :eekk: controller SIX-CHANNEL DDR4 2400 Up to 384 GB di RAM

http://www.extremetech.com/extreme/171678-intel-unveils-72-core-x86-knights-landing-cpu-for-exascale-supercomputing

Non avevo letto che era in doppia precisione, davvero un mostro niente da dire.

Non vedo l'ora di leggere qualcosa di più approfondito e magari qualche test. :eek:

Ho dei seri dubbi sia corretto chiamarle gpu, sono schede (se di scheda si parla e non del chip da inserire direttamente su mobo) acceleratrici per calcolo parallelo, non hanno ne le componenti ne le funzionalità di una gpu.
Infatti non lo sono.
Detto questo: ma queste soluzioni si usano già o sono ancora dei kit distribuiti più che altro agli sviluppatori per fargli prendere dimestichezza con architettura e api come per le prime versioni?
A livello di API credo che non dovrebbe cambiare molto rispetto agli attuali Knights Corner, dunque tutto il software già scritto dovrebbe girare tranquillamente.

Comunque per prendere confidenza con lo sviluppo di software per Xeon Phi non ti serve necessariamente avere la scheda o il computer: puoi scrivere codice che gira automaticamente sulla CPU nel caso in cui non venga trovato alcun sistema Xeon Phi. In questo modo puoi già lavorare al codice vero e proprio, e sfruttare le schede o il computer non appena le avrai, senza dover toccare più niente.
piu che altro vorrei capire se una volta montate sei socket la ram si somma a quella di sistema e diventa unica o se rimane separata, perchè le Xeon PHI attuali su PCI-EX hanno lo stesso problema delle GPU che devono caricare il tutto nella ram della GPU, niente memoria condivisa :/
Con Xeon Phi può già mappare in maniera trasparente la memoria di CPU e Xeon Phi in modo che siano condivise. Per essere chiari, puoi, ad esempio, dichiarare un vettore e mapparlo in memoria allo stesso indirizzo sia sulla CPU sia su Xeon Phi. Si occuperà poi il runtime di Xeon Phi a sincronizzare opportunamente le rispettive memoria locali.

Se la CPU scrive qualcosa nel vettore, ad esempio, le modifiche verranno ricopiate nella scheda (o nelle, se le schede/sistemi sono più d'una) memoria di Xeon Phi, in modo che sia CPU sia Xeon Phi abbiano sempre dei dati coerenti.

Questo particolare modello di sviluppo per Xeon Phi (ce ne sono diversi, a seconda del linguaggio e degli obiettivi) si chiama MYO. Qui (https://software.intel.com/en-us/articles/programming-for-multicore-and-many-core-products) trovi informazioni sulle diverse possibilità di sviluppo.

La cosa interessante di MYO è che consente di scambiare velocemente strutture dati anche molto complesse (es: grafi) senza che sia necessaria alcun marshalling per lo scambio di dati (come avviene, invece, per altre modalità di sviluppo / funzionamento, o normalmente con altre architetture GPGPU o GPU).

Comunque se hai già del codice esistente lo puoi convertire velocemente e in maniera molto semplice per sfruttare Xeon Phi, usando delle apposite direttive (#pragma). Oppure Intel mette a disposizione una libreria di funzioni matematiche (MKL) molto usate in ambito scientifico, e che sono già ottimizzate per sfruttare automaticamente Xeon Phi.

Questo è tutto, se il discorso che facevi sulla memoria integrata in Xeon Phi riguardava la condivisione di dati fra CPU e Xeon Phi. Altrimenti dovresti chiarire meglio lo scenario di cui parlavi.
In un'altra news leggevo che in teoria tutta questa potenza non necessita nemmeno di una revisione del codice (immagino codice comunque scritto per le precedenti versioni di questa scheda).
ancora meglio, è riferito al codice X86 classico; queste "GPU" hanno i core che sono X86; quindi basta poco per adattare il classico codice X86 a queste schede; deve solo esserci software/calcolo che si presta bene ad essere parallelizzato.
Rispondo a entrambi. A differenza di Knights Corner, Knights Landing mette a disposizione dei core perfettamente compatibili con IA-32, per cui possono far girare qualunque codice per IA-32 o Intel64/x64 senza alcuna modifica.

Quindi è possibile installare qualunque s.o. e utilizzare qualunque software già esistente, e se questo supporta già adeguatamente la programmazione parallela (multicore/thread) trarrà automaticamente beneficio della moltitudine di core / thread hardware a disposizione (con 72 core fisici ci sono 288 thread hardware).

Questo, però, non consente di sfruttare pienamente la potenza di calcolo che Knights Landing mette a disposizione (in particolare il set d'istruzioni AVX512). Per fare, però, è sufficiente una ricompilazione con un compilatore che generi codice apposito per questa ISA.
nella prima versione di queste schede erano i core del chip erano i vecchi core del Pentium originale modificati, questa nuova versione sara basata su un massimo di 72 core Silvermont ( gli attuali Atom Bay trail ) modificati per gestire 4 thread per core :eek:
Sì, e quindi dovrebbe esserci un notevole aumento prestazionale, similmente a quello ottenuto passando dalla vecchia architettura Atom in-order a quella out-of-order. Anzi, considerato che Xeon Phi utilizzava la vecchia architettura Pentium (adattata), e quindi non erano presenti i diversi miglioramenti presenti in quella Atom in-order, il guadagno a livello prestazionale dovrebbe essere decisamente maggiore.

Comunque aspettiamo i primi benchmark per avere qualche dato concreto.

Questo è tutto, se il discorso che facevi sulla memoria integrata in Xeon Phi riguardava la condivisione di dati fra CPU e Xeon Phi. Altrimenti dovresti chiarire meglio lo scenario di cui parlavi.



premesso che non sono un programmatore e ce l'ho fatta a seguirti solo fino a un certo punto e poi il resto tutto arabo :stordita: :stordita: :D....

quello che ho scritto prima faceva riferimento a quello che mi è capitato l'anno scorso:
ad un evento di grafica dove era presente il creatore di Vray che stava presentando in anteprima Vray 3.0, durante la pausa, ho avuto modo di fargli direttamente 2 domande:

1 - Vray supportera gli Xeon PHI ?
2 - gli Xeon PHI hanno lo stesso problema delle GPU che sono limitate dal quantitativo di ram visto devono caricare tutta la scena 3D in ram ?

le sue risposte sono state.

1 - c'è gia un team di sviluppo che sta testanto gli Xeon PHI, ma abbiamo il problema che quando renderizzano al 100% vanno il protezione termica
2 - si attualmente si

ora non so se quello che hai scritto tu cozza con quello che mi ha detto lui o se potrebbe anche esserci l'eventualita di avergli posto male la domanda con conseguente risposta intesa male da me :fagiano: ( ...non è stata una conversazione in italiano... )

premesso che non sono un programmatore e ce l'ho fatta a seguirti solo fino a un certo punto e poi il resto tutto arabo :stordita: :stordita: :D....
OK. Ma se c'è qualcosa di che t'interessa e non è chiaro posso cercare di spiegarlo diversamente.

Comunque ieri sera ero a pezzi e ho commesso qualche errore nello scrivere. Chiedo venia.
quello che ho scritto prima faceva riferimento a quello che mi è capitato l'anno scorso:
ad un evento di grafica dove era presente il creatore di Vray che stava presentando in anteprima Vray 3.0, durante la pausa, ho avuto modo di fargli direttamente 2 domande:

1 - Vray supportera gli Xeon PHI ?
2 - gli Xeon PHI hanno lo stesso problema delle GPU che sono limitate dal quantitativo di ram visto devono caricare tutta la scena 3D in ram ?

le sue risposte sono state.

1 - c'è gia un team di sviluppo che sta testanto gli Xeon PHI, ma abbiamo il problema che quando renderizzano al 100% vanno il protezione termica
Supportarlo, come dicevo, è davvero molto facile. Ovviamente i risultati migliori li ottieni se ottimizzando il codice tenendo conto delle peculiarità di Xeon Phi, ma in generale è decisamente semplice farlo.

Per quanto riguarda il fatto che vadano in protezione termica, è strano, perché non m'è mai capitato. Bisognerebbe vedere che tipo di Xeon Phi hanno (è disponibile in alcune versioni che variano per numero di core e clock).

Comunque potrebbero selettivamente scegliere quanti core utilizzare, in modo da trovare il giusto bilanciamento che eviti di far andare in protezione termina la scheda. Se utilizzano MPI per distribuire il carico di lavoro sui core & thread è molto semplice specificare quanti core usare, e in generale come distribuire l'esecuzione nei vari core e thread.
2 - si attualmente si
Credo di aver capito. Xeon Phi ovviamente lavora esclusivamente con sua memoria locale, per cui tutto ciò che gli serve (codice, dati) deve risiedere o nella GDDR5 o nella cache L2 o nella cache L1; non si scappa. Ovviamente può anche prelevare dati dalla memoria centrale, ma usando il protocollo PCI-Express, con tutti i limiti del caso (banda e latenza).

Knights Landing non fa eccezione, anche se non credo non ci siano problemi in tal senso, visto che integra moltissima memoria di per sé.

Con le architetture precedenti, però, il problema si pone, perché 8GB di RAM possono essere troppo pochi se c'è da manipolare grosse quantità di dati. In questo caso le applicazioni devono essere sviluppate in modo da cercare di massimizzare l'uso della memoria locale della GPU, suddividendo l'elaborazione in parti che girino interamente in Xeon Phi.

Credo che sia stato questo il problema che hanno avuto con Vray.
ora non so se quello che hai scritto tu cozza con quello che mi ha detto lui o se potrebbe anche esserci l'eventualita di avergli posto male la domanda con conseguente risposta intesa male da me :fagiano: ( ...non è stata una conversazione in italiano... )
Ti sei spiegato perfettamente, e sono abbastanza confidente che la problematica sia quella che ho descritto sopra.

Per cui con Knights Landing chi utilizza VRay può dormire sonni tranquilli. ;)

Trovo molto interessanti i due ultimi interventi,dunque chi si avvale di strumenti come Intel Cluster Studio può creare il proprio codice e compilarlo ottimizzandolo per l'eventuale Phi presente nella sua workstation?Cioè in sostanza, lo sviluppatore si trova davanti uno scenario simile a quello con Parallel Nsight e CUDA(lato Nvidia) se lavora con ICS e librerie tipo IPP o MKL (lato INTEL)?Mi piacerebbe trovare anche qualche fonte autorevole (i links sono bene accetti) in cui viene approfondito quale tipo di algoritmi possono trarre massimo giovamento da una architettura come quella dello Xeon Phi rispetto a quella a Shader Unificati della controparte Nvidia o AMD essendo profondamente diverse.Mi interessa questo perchè proprio un paio di giorni fa leggevo,su documentazione ufficiale Intel,come far sfruttare a un notissimo software di calcolo (MATLAB) appunto una scheda PHI,dal momento che anche nella sua ultima versione uscita a Marzo MatWorks supporta ufficialmente solo CUDA.L'articolo era molto interessante faceva vedere come spostare il calcolo di due matrici (10000x10000 di double) dai processori (un paio di Xeon E5 a 8 cores ciascuno) alla scheda Phi utilizzando una phi della serie 7000.Lo sbattimento non era alla fine eccessivo si doveva forzare Matlab ad utilizzare l'ultima versione delle MKL e il risultato che faceva vedere l'articolo era sorprendende,le due CPU Xeon impiegavano circa 5s per il calcolo mentre la scheda PHI 1,89 secondi(sempre secondo PDF INTEL).Ho provato per curiosità ad eseguire lo stesso calcolo sulla Titan che ho sul mio pc,ma il risultato è stato di 0,002113 s!Da questa differenza elevata scaturisce la mia curiosità di approfondire il confronto tra le due differenti architetture,non credo dipenda dal codice estremamente ottimizzato delle librerie nvidia....

Il risultato di Xeon Phi è decisamente scadente. Evidentemente c'è qualcosa che non consente di sfruttare la potenza di calcolo a disposizione, che specialmente in doppia precisione è molto elevata.
Bisognerebbe analizzare il test e profilare l'applicazione per rilevare i colli di bottiglia, anche perché il calcolo matriciale si presta bene per quest'archutettura.
Comunque non userei Intel Cluster Studio, visto che non c'è un cluster. Intel Conposer XE è lo strumento più adatto allo scenario esposto, che è pure quello più comune.
Al momento non posso aggiungere altro perché sono con lo smartphone e sto andando a lavoro.

Per quanto riguarda il fatto che vadano in protezione termica, è strano, perché non m'è mai capitato. Bisognerebbe vedere che tipo di Xeon Phi hanno (è disponibile in alcune versioni che variano per numero di core e clock).

Comunque potrebbero selettivamente scegliere quanti core utilizzare, in modo da trovare il giusto bilanciamento che eviti di far andare in protezione termina la scheda. Se utilizzano MPI per distribuire il carico di lavoro sui core & thread è molto semplice specificare quanti core usare, e in generale come distribuire l'esecuzione nei vari core e thread.


non è sceso piu di tanto nei particolari ma credo che il loro scopo fosse/sia quello di farla lavorare al 100%, ora non so quanto sia efficiente o meno rispetto alle CPU in questi ambiti, ma visto il costo elevato se vogliono renderla un'opzione percorribile credo che debbano trovare il modo di sfruttarla al 100%, seno tanto vale rimanere su CPU.


Credo di aver capito. Xeon Phi ovviamente lavora esclusivamente con sua memoria locale, per cui tutto ciò che gli serve (codice, dati) deve risiedere o nella GDDR5 o nella cache L2 o nella cache L1; non si scappa. Ovviamente può anche prelevare dati dalla memoria centrale, ma usando il protocollo PCI-Express, con tutti i limiti del caso (banda e latenza).

Knights Landing non fa eccezione, anche se non credo non ci siano problemi in tal senso, visto che integra moltissima memoria di per sé.

Con le architetture precedenti, però, il problema si pone, perché 8GB di RAM possono essere troppo pochi se c'è da manipolare grosse quantità di dati. In questo caso le applicazioni devono essere sviluppate in modo da cercare di massimizzare l'uso della memoria locale della GPU, suddividendo l'elaborazione in parti che girino interamente in Xeon Phi.

Credo che sia stato questo il problema che hanno avuto con Vray.


mmm e no allora parziali brutte notizie :/ perchè es. io attualmente lavoro con 32 Gb di ram, non le uso per tutti i render, pero il fatto di avere un qualcosa che non posso usare sempre non mi piace molto...

pero secondo te, immaginando questo sistema, quale situazione si verifichera:

scheda madre bi-socket, socket 1 Xeon con 32 Gb di ram, socket 2 con Xeon PHI con 16 Gb on-board e 32 Gb di ram come banchi

premessa ( attualmente con le GPU e l'attuale PHI la scena di render deve essere caricata totalmente in ram texture comprese, seno non parte il render )

1- avremo 64 Gb di ram di sistema e separati 16 Gb on-board, quindi la scena di render dovra essere inferiore ai 16 Gb

2- avremo 80 GB di ram+on-board che saranno un tutt'uno quindi scena di render senza limiti

3- avremo 32 Gb di ram dello Xeon CPU classico e poi separati i 48 Gb PHI ( i suoi 16 on-board + i 32 collegati al suo socket ) quindi il limite di 32 Gb


se non ho capito male quello che hai scritto che il limite rimane ci troveremo nella situazione 1 ( brutta :mad: ) o potrebbe essere anche al situazione 3 ( bella :)

Si,avevo citato il Cluster Studio perchè raccoglie un po tutto il necessario(librerie incluse) per scrivere diverso codice ottimizzato anche in distribuito.La cosa mi ha lasciato parecchio perplesso...anche per il fatto che è documentazione ufficiale intel,quindi presumo che abbiano fatto di tutto per esprimere il massimo!Il pc di prova è questo:

"This article was created based on MATLAB R2014a and Intel MKL for Windows* 11.1 update1 and update 2 on the system
Host machine: Intel Xeon CPU E5-2697 v2, 2 Twelve-Core CPUs (30MB LLC, 2.7GHz), 128GB of RAM; OS: Windows Server 2008 R2 Enterprise
Coprocessors: 2 Intel® Xeon Phi™ Coprocessors 7120A, each with 61 cores (30.5MB total cache, 1.2GHz), 16GB GDDR5 Memory
Software: Intel® Math Kernel Library (Intel® MKL) 11.1 update 1 and update 2, Intel Manycore Platform Software Stack (MPSS) 3.2.27270.1".

Per una configurazione così ci vuole una vagonata di euro e poi dopo le opportune mdificazioni suggerite ecco il risultato (un po deludente):

"If you start a MATLAB session after setting MKL_MIC_ENABLE, the MATLAB command window displays:
>> TestBlas
Elapsed time is 1.869576 seconds"

TestBlas crea le due matrici ma calcola il tempo solo per il prodotto delle stesse.Dunque sarà più un cattivo supporto o una deficenza dell'architettura?

Infatti non lo sono.

A livello di API credo che non dovrebbe cambiare molto rispetto agli attuali Knights Corner, dunque tutto il software già scritto dovrebbe girare tranquillamente.

Comunque per prendere confidenza con lo sviluppo di software per Xeon Phi non ti serve necessariamente avere la scheda o il computer: puoi scrivere codice che gira automaticamente sulla CPU nel caso in cui non venga trovato alcun sistema Xeon Phi. In questo modo puoi già lavorare al codice vero e proprio, e sfruttare le schede o il computer non appena le avrai, senza dover toccare più niente.

Con Xeon Phi può già mappare in maniera trasparente la memoria di CPU e Xeon Phi in modo che siano condivise. Per essere chiari, puoi, ad esempio, dichiarare un vettore e mapparlo in memoria allo stesso indirizzo sia sulla CPU sia su Xeon Phi. Si occuperà poi il runtime di Xeon Phi a sincronizzare opportunamente le rispettive memoria locali.

Se la CPU scrive qualcosa nel vettore, ad esempio, le modifiche verranno ricopiate nella scheda (o nelle, se le schede/sistemi sono più d'una) memoria di Xeon Phi, in modo che sia CPU sia Xeon Phi abbiano sempre dei dati coerenti.

Questo particolare modello di sviluppo per Xeon Phi (ce ne sono diversi, a seconda del linguaggio e degli obiettivi) si chiama MYO. Qui (https://software.intel.com/en-us/articles/programming-for-multicore-and-many-core-products) trovi informazioni sulle diverse possibilità di sviluppo.

La cosa interessante di MYO è che consente di scambiare velocemente strutture dati anche molto complesse (es: grafi) senza che sia necessaria alcun marshalling per lo scambio di dati (come avviene, invece, per altre modalità di sviluppo / funzionamento, o normalmente con altre architetture GPGPU o GPU).

Comunque se hai già del codice esistente lo puoi convertire velocemente e in maniera molto semplice per sfruttare Xeon Phi, usando delle apposite direttive (#pragma). Oppure Intel mette a disposizione una libreria di funzioni matematiche (MKL) molto usate in ambito scientifico, e che sono già ottimizzate per sfruttare automaticamente Xeon Phi.

Questo è tutto, se il discorso che facevi sulla memoria integrata in Xeon Phi riguardava la condivisione di dati fra CPU e Xeon Phi. Altrimenti dovresti chiarire meglio lo scenario di cui parlavi.


Rispondo a entrambi. A differenza di Knights Corner, Knights Landing mette a disposizione dei core perfettamente compatibili con IA-32, per cui possono far girare qualunque codice per IA-32 o Intel64/x64 senza alcuna modifica.

Quindi è possibile installare qualunque s.o. e utilizzare qualunque software già esistente, e se questo supporta già adeguatamente la programmazione parallela (multicore/thread) trarrà automaticamente beneficio della moltitudine di core / thread hardware a disposizione (con 72 core fisici ci sono 288 thread hardware).

Questo, però, non consente di sfruttare pienamente la potenza di calcolo che Knights Landing mette a disposizione (in particolare il set d'istruzioni AVX512). Per fare, però, è sufficiente una ricompilazione con un compilatore che generi codice apposito per questa ISA.

Sì, e quindi dovrebbe esserci un notevole aumento prestazionale, similmente a quello ottenuto passando dalla vecchia architettura Atom in-order a quella out-of-order. Anzi, considerato che Xeon Phi utilizzava la vecchia architettura Pentium (adattata), e quindi non erano presenti i diversi miglioramenti presenti in quella Atom in-order, il guadagno a livello prestazionale dovrebbe essere decisamente maggiore.

Comunque aspettiamo i primi benchmark per avere qualche dato concreto.
Davvero notevole, mi piacerebbe un casino provarne uno in futuro ma credo non sarà compatibile con le mie tasche. :P Però grande Intel, via di sto passo probabilmente il futuro sarà in questo senso :O

Davvero notevole, mi piacerebbe un casino provarne uno in futuro ma credo non sarà compatibile con le mie tasche. :P Però grande Intel, via di sto passo probabilmente il futuro sarà in questo senso :O
3 TF in Db vuol dire tutto e niente.
Essendo comunque un ia32 si porterà dietro tutti i limiti x86 dietro, mitigati da accorgimenti vari certamente, ma la prova sul campo metterà in luce l'esatto valore di queste soluzioni.
Troppe volte ho visto specifiche sulla carta mirabolanti e poi prestazioni deludenti in pratica.
L'unica cosa che posso però dire è che vedo sempre più nvidia tagliata fuori dal settore HPC.
Questa soluzione elimina praticamente il bisogno di riscrivere il codice da zero, mentre in situazioni particolari potrebbe essere addirittura consigliabile l'apu AMD per abbattere i costi.

3 TF in Db vuol dire tutto e niente.
Essendo comunque un ia32 si porterà dietro tutti i limiti x86 dietro, mitigati da accorgimenti vari certamente, ma la prova sul campo metterà in luce l'esatto valore di queste soluzioni.
Troppe volte ho visto specifiche sulla carta mirabolanti e poi prestazioni deludenti in pratica.
L'unica cosa che posso però dire è che vedo sempre più nvidia tagliata fuori dal settore HPC.
Questa soluzione elimina praticamente il bisogno di riscrivere il codice da zero, mentre in situazioni particolari potrebbe essere addirittura consigliabile l'apu AMD per abbattere i costi.

bha a me le APU paiono senza senso, sono limitate dalla GPU entry lvl e sono malamente scalabili; con Intel o nVidia ti fai un singolo sistema da 1 a 4 CPU e da 1 a 8 GPU e passi da sistemi entry lvl a Top gamma.

al contrario nVidia si sta ritagliando tutto un suo mercato offrendo soluzioni complete fatte e finite di hardware + software.

bha a me le APU paiono senza senso, sono limitate dalla GPU entry lvl e sono malamente scalabili; con Intel o nVidia ti fai un singolo sistema da 1 a 4 CPU e da 1 a 8 GPU e passi da sistemi entry lvl a Top gamma.

al contrario nVidia si sta ritagliando tutto un suo mercato offrendo soluzioni complete fatte e finite di hardware + software.

Si,credo che lo scenarieo futuro sarà una piattaforma hardware solo INTEL con Xeon classici più PHI e solo NVIDIA cpu ARM e schede TESLA .Sarà interessante questa "battaglia" anche perchè con Maxwell e architetture future Nvidia sta spingendo molto anche sull'efficenza enegetica oltre che sulle prestazioni pure!

Pensare che poco meno di un mese fa mi ero fatto aggiornare la ws con due phi è due xeon 2880....
Però le prove di impatto ringraziano....:stordita:

Pensare che poco meno di un mese fa mi ero fatto aggiornare la ws con due phi è due xeon 2880....
Però le prove di impatto ringraziano....:stordita:

bè dai queste usciranno fra un anno, hai tutto il tempo di fargliele ricomprare :D

bè dai queste usciranno fra un anno, hai tutto il tempo di fargliele ricomprare :D

Anno prossimo schermo 4k :D

Visto che tu te ne intendi di "robe da disegno" :sofico: :sofico: , hai qualche dritta per 16:10 4k?

Anno prossimo schermo 4k :D

Visto che tu te ne intendi di "robe da disegno" :sofico: :sofico: , hai qualche dritta per 16:10 4k?

da quello che ho visto, 16:10 non esistono.... o meglio, esiste questo Canon, ma credo che costi come una BMW e non modello base :asd:
http://www.fotografidigitali.it/news/canon-presenta-dp-v3010-il-primo-monitor-4k-professionale-della-casa_49594.html

non so se ne uscira qualcuno con quella risoluzione, fino ad ora quelli che ho visto che devono uscire avranno tutti la solita risoluzione

credo che il miglio rapporto prezzo prestazioni lo si abbia con il Dell IGZO 32", anche perchè il dotch pitch dei 27" 4K non lo trovo molto confortevole...

da quello che ho visto, 16:10 non esistono.... o meglio, esiste questo Canon, ma credo che costi come una BMW e non modello base :asd:
http://www.fotografidigitali.it/news/canon-presenta-dp-v3010-il-primo-monitor-4k-professionale-della-casa_49594.html

non so se ne uscira qualcuno con quella risoluzione, fino ad ora quelli che ho visto che devono uscire avranno tutti la solita risoluzione

credo che il miglio rapporto prezzo prestazioni lo si abbia con il Dell IGZO 32", anche perchè il dotch pitch dei 27" 4K non lo trovo molto confortevole...

40k dollari, LOL :asd: mi faccio prendere altre 3 ws in leasing.
Ovviamente per il 4k si punta al 32" o anche più :cool:
Il problema è convincere l'amministrazione che mi serva veramente :ops: :ops:

Molto ma molto interessante questa soluzione! Aspettiamo qualche bench!

non è sceso piu di tanto nei particolari ma credo che il loro scopo fosse/sia quello di farla lavorare al 100%, ora non so quanto sia efficiente o meno rispetto alle CPU in questi ambiti, ma visto il costo elevato se vogliono renderla un'opzione percorribile credo che debbano trovare il modo di sfruttarla al 100%, seno tanto vale rimanere su CPU.
Capisco, ma se hanno problemi di protezione termica, vuol dire che comunque non riescono a sfruttare al massimo la scheda. Allora tanto vale trovare il perfetto bilanciamento, senza per questo dover ritornare a usare la CPU.

Per fare un esempio pratico, se su 61 core a disposizione ne disabilitano soltanto 6 per non andare in protezione termica, col 10% in meno di core hai all'incirca il 10% in meno di prestazioni, ma in ogni caso molto più di quello che potrebbe fornirti una CPU.

Comunque potrebbero contattare Intel e chiedere spiegazioni, perché è una situazione che non dovrebbe verificarsi.
mmm e no allora parziali brutte notizie :/ perchè es. io attualmente lavoro con 32 Gb di ram, non le uso per tutti i render, pero il fatto di avere un qualcosa che non posso usare sempre non mi piace molto...
Beh, ma è come con le GPU: puoi utilizzare la loro memoria locale, ma l'operazione di trasferimento dei dati da CPU a GPU, e viceversa, rimane onerosa.

Non penso che ti lamenti del fatto di non poter utilizzare liberamente la memoria della GPU. Con Knights Corner (KC) al momento è così, perché la scheda si trova collegata al PC tramite lo stesso PCI-Express.

Con Knights Landing (KL) sarà diverso, ma ne parlo meglio dopo.
pero secondo te, immaginando questo sistema, quale situazione si verifichera:

scheda madre bi-socket, socket 1 Xeon con 32 Gb di ram, socket 2 con Xeon PHI con 16 Gb on-board e 32 Gb di ram come banchi

premessa ( attualmente con le GPU e l'attuale PHI la scena di render deve essere caricata totalmente in ram texture comprese, seno non parte il render )

1- avremo 64 Gb di ram di sistema e separati 16 Gb on-board, quindi la scena di render dovra essere inferiore ai 16 Gb

2- avremo 80 GB di ram+on-board che saranno un tutt'uno quindi scena di render senza limiti

3- avremo 32 Gb di ram dello Xeon CPU classico e poi separati i 48 Gb PHI ( i suoi 16 on-board + i 32 collegati al suo socket ) quindi il limite di 32 Gb

se non ho capito male quello che hai scritto che il limite rimane ci troveremo nella situazione 1 ( brutta :mad: ) o potrebbe essere anche al situazione 3 ( bella :)
Scusami, ma non ho capito se ti riferisci all'attuale situazione con KC o con KL.

Per tagliare la testa al toro espongo le casistiche per entrambi.

Presupponendo una workstation con due socket dotati ognuno di un "normale" processore Xeon, 32+32 = 64 GB totali di RAM (di sistema), e una scheda Xeon Phi basata su KC con 8GB di memoria (VRAM), gli scenari possibili sono i seguenti:
1) offloading. I 64GB di memoria contengono tutto, e man mano spostano dei dati su e dalla VRAM (sempre tramite il PCI-Express), scaricando buona parte del lavoro su KC. Parlo di buona parte, perché una parte la possono elaborare le due CPU Xeon; infatti è possibile sfruttare qualunque dispositivo, siano esse le CPU o siano le schede Xeon Phi, per portare a termine il carico di lavoro. Si occupa il codice (generato dal compilatore e/o sfruttando OpenMP o MPI) di distribuire i job a tutti questi elementi. La memoria non è unificata, ma i due tipi di memoria sono separati, e il codice generato si occupa di copiare i dati avanti e indietro a seconda di come servono per quel pezzo particolare di codice che dev'essere eseguito.
2) MYO. Si tratta sempre di offloading, ma in questo caso la memoria che dev'essere condivisa fra le due CPU e Xeon Phi viene vista come se fosse unificata, con lo stesso spazio d'indirizzamento (leggi: gli indirizzi dei dati sono identici. Quindi se un vettore è condiviso fra le due CPU e Xeon Phi, avrà esattamente lo stesso indirizzo per tutti e tre i processori, e vi potranno accedere esattamente allo stesso modo). Si occupa il runtime di MYO di sincronizzare opportunamente le letture e scritture che occorrono per tutti e 3 i processori, in modo da mantenere coerenti i dati condivisi. Quindi c'è sempre una copia dei dati usando il PCI-Express, ma è totalmente trasparente all'applicazione.
3) nativo. Si può eseguire nativamente un'applicazione in Xeon Phi, senza interazione con il sistema centrale (le due CPU). Prima di ciò, però, è necessario copiare codice (nativo: l'applicazione viene compilata per girare soltanto su Xeon Phi, e non sulla CPU) e dati sulla scheda (che alla fine è un PC basato su Linux). Questo si realizza tramite un'apposita utility in dotazione del software di supporto di Xeon Phi (si chiama MPSS). Una volta caricato tutto sul filesystem della scheda, tramite una shell SSH si può lanciare l'eseguibile, e da lì in poi il codice andrà avanti da solo, in maniera indipendente da quello che fanno le due CPU. Ovviamente il limite di questa soluzione è rappresentato dallo spazio disponibile su disco, ma soprattutto dagli 8GB di memoria (VRAM) a disposizione. E' chiaro che, girando da solo, il codice non potrà contare sull'applicazione che gira sulle due CPU, e che può fornirgli sempre nuovi dati, recuperando quelli già elaborati. Per questo motivo si tratta di uno scenario poco utilizzato, ma ci sono aziende che lo adoperano, perché ha i suoi vantaggi (non c'è bisogno di alcun protocollo di comunicazione fra CPU e Xeon Phi, e non serve alcuna sincronizzazione fra di loro: Xeon Phi procede al massimo della velocità macinando i dati che si ritrova interamente in locale).

Arriviamo finalmente a KL. Essendo il successore di KC, presumibilmente dovrebbe poter gestire tutti e 3 gli scenari. Sicuramente supporterà il terzo, l'esecuzione nativa, ma questo, a differenza di KC, sarà proprio il suo punto di forza. Il motivo è presto detto: KL non ha bisogno di essere infilato in una scheda di un computer per poter funzionare, ma è in grado da solo di fungere da computer. Si tratta a tutti gli effetti di una normale CPU Intel64 da questo punto di vista, esattamente come tutte le altre (Atom, i3, i5, i7), per cui è possibile costruire computer che hanno soltanto questo processore all'interno. In questo caso non serve l'offloading, perché il computer con KL ha già tutto quello che gli serve. Anzi, ha pure molto di più, visto che la memoria a disposizione non è limitata a 8GB, ma arriva fino a 384GB. Questo significa che cadono di colpo tutti i limiti di cui sopra: hai tanta memoria, e... tutta "unificata" (c'è solo quella!). Quindi non devi sincronizzare proprio nulla, e non ci sono copie avanti e indietro: l'applicazione, all'avvio, carica tutti i dati sui quali deve lavorare, e poi procede spedita a macinarli. In più ha pure fino a 16GB di cache (L4?) a disposizione.
Si,avevo citato il Cluster Studio perchè raccoglie un po tutto il necessario(librerie incluse) per scrivere diverso codice ottimizzato anche in distribuito.La cosa mi ha lasciato parecchio perplesso...anche per il fatto che è documentazione ufficiale intel,quindi presumo che abbiano fatto di tutto per esprimere il massimo!
Sono risalito al PDF, e quello che descrivono è come abilitare Matlab a usare la libreria MKL. Non ci sono, quindi, particolari "cure": è all'incirca quello che si farebbe con altre applicazioni che utilizzano le funzioni BLAS e LAPACK. Semplicemente lo si è fatto per Matlab, che è un software noto e rinomato.
Il pc di prova è questo:

"This article was created based on MATLAB R2014a and Intel MKL for Windows* 11.1 update1 and update 2 on the system
Host machine: Intel Xeon CPU E5-2697 v2, 2 Twelve-Core CPUs (30MB LLC, 2.7GHz), 128GB of RAM; OS: Windows Server 2008 R2 Enterprise
Coprocessors: 2 Intel® Xeon Phi™ Coprocessors 7120A, each with 61 cores (30.5MB total cache, 1.2GHz), 16GB GDDR5 Memory
Software: Intel® Math Kernel Library (Intel® MKL) 11.1 update 1 and update 2, Intel Manycore Platform Software Stack (MPSS) 3.2.27270.1".

Per una configurazione così ci vuole una vagonata di euro e poi dopo le opportune mdificazioni suggerite ecco il risultato (un po deludente):

"If you start a MATLAB session after setting MKL_MIC_ENABLE, the MATLAB command window displays:
>> TestBlas
Elapsed time is 1.869576 seconds"

TestBlas crea le due matrici ma calcola il tempo solo per il prodotto delle stesse.Dunque sarà più un cattivo supporto o una deficenza dell'architettura?
Le prestazioni sono deludenti, come già detto prima, ma dalla sola lettura del documento non sono in grado di formulare un'ipotesi.
Davvero notevole, mi piacerebbe un casino provarne uno in futuro ma credo non sarà compatibile con le mie tasche. :P
Vedremo in futuro cosa arriverà.
Però grande Intel, via di sto passo probabilmente il futuro sarà in questo senso :O
A mio avviso sì, perché è una piattaforma più facile da programmare per scalare, e non richiede skill elevate.

Considera, ad esempio, che soluzioni massicciamente parallele sono utilizzate da scienziati che non nascono programmatori, ma che sono costretti a scrivere codice per i propri lavori. In questo caso offrire uno strumento di facile utilizzo, accompagnato a buone prestazioni, può fare la differenza.
3 TF in Db vuol dire tutto e niente.
Essendo comunque un ia32 si porterà dietro tutti i limiti x86 dietro, mitigati da accorgimenti vari certamente, ma la prova sul campo metterà in luce l'esatto valore di queste soluzioni.
Indubbiamente la sezione di decodifica di un core x86 è ben più complessa di quella di un RISC, e richiede sia transistor sia consumi più elevati. Ma dall'altra parte un'architettura CISC come quella offre anche vantassi in termini di maggior densità del codice e a livello prestazionale.

Puoi vederla in due modi diversi, a seconda della prospettiva: quelli che sono limiti da un lato diventano pregi dall'altro.
Troppe volte ho visto specifiche sulla carta mirabolanti e poi prestazioni deludenti in pratica.
Concordo, ma Xeon Phi viene già utilizzato anche in alcuni supercomputer della TOP 500: se non avesse prestazioni reali interessanti, non ci sarebbe potuto arrivare.
L'unica cosa che posso però dire è che vedo sempre più nvidia tagliata fuori dal settore HPC.
Al momento mi pare difficile, perché è ben radicata. Bisognerà vedere quanto Intel riuscirà a spingere le sue soluzioni in quest'ambito.
Questa soluzione elimina praticamente il bisogno di riscrivere il codice da zero,
Esattamente, anche se per ottenere il meglio bisogna quanto meno ricompilare il codice per sfruttare la nuova unità SIMD (con AVX512), e magari ritoccarlo in alcuni punti critici (ad esempio riutilizzando opportunamente la memoria già trasferita in Xeon Phi, evitando inutili copie avanti e indietro). Non serve molto per tutto ciò, ma sono ottimizzazioni che possono fare la differenza.
mentre in situazioni particolari potrebbe essere addirittura consigliabile l'apu AMD per abbattere i costi.
Certo, non è un'architettura che va bene per tutto.
Si,credo che lo scenarieo futuro sarà una piattaforma hardware solo INTEL con Xeon classici più PHI e solo NVIDIA cpu ARM e schede TESLA .
Lato Intel con Knights Landing si prospetta un futuro in cui ci saranno soltanto CPU Xeon Phi, e nessuno Xeon classico, proprio perché KL è perfettamente in grado di fungere da CPU e, dunque, è possibile costruire interi computer che li contengono (senza ricorrere al PCI-Express). Vedi sopra per maggiori dettagli.
Sarà interessante questa "battaglia" anche perchè con Maxwell e architetture future Nvidia sta spingendo molto anche sull'efficenza enegetica oltre che sulle prestazioni pure!
La battaglia, a mio avviso, sarà anche su un altro piano. Mentre una soluzione basata su core ARM + GPU prevede che il primo scarichi il lavoro sul secondo, usando un particolare protocollo di comunicazione / sincronizzazione fra i due (molto) diversi elementi, con Xeon Phi (anche KC) tutto ciò non serve più, perché ogni singolo lo possiamo vedere come la fusione di un "core" (in realtà sarebbe un'unità di calcolo) scalare e uno vettoriale, le cui istruzioni da eseguire vengono pescate direttamente dall'unico, nonché condiviso, flusso letto dalla memoria. In buona sostanza, in Xeon Phi non c'è nessun protocollo: ci sono le istruzioni che vengono date in pasto al thread hardware, che vengono smistate all'unità scalare e/o vettoriale ed eseguite immediatamente. Per cui praticamente non c'è alcun overhead, come invece capita coi core eterogenei di una soluzione con due processori completamente separati nonché diversi.
Pensare che poco meno di un mese fa mi ero fatto aggiornare la ws con due phi è due xeon 2880....
Il prossimo anno farei festa, al posto tuo. ;)
Però le prove di impatto ringraziano....:stordita:
Bene. Potresti fornire qualche dettaglio? Cos'hai notato? Come ti trovi? Sono curioso di leggere il parere di un customer. :p

Sono risalito al PDF, e quello che descrivono è come abilitare Matlab a usare la libreria MKL. Non ci sono, quindi, particolari "cure": è all'incirca quello che si farebbe con altre applicazioni che utilizzano le funzioni BLAS e LAPACK. Semplicemente lo si è fatto per Matlab, che è un software noto e rinomato.


La Math Kernel Library è quella deputata a velocizzare appunto calcoli,così come le librerire utilizzate dalle gpu nvidia all'interno del toolkit di CUDA,ora,una differenza di ben due ordini di grandezza ci suggerisce solo una cattiva ottimizzazione del codice oppure una differeza architetturale tra un intel core e un cuda core nel maneggiare determinate tipologie di calcoli?Cioè mi interessava capire se queste due architetture così diverse sarenno capaci di gestire più efficentemente determinate operazione piuttosto che altre.

Un altra perplessità poi, nel futuro,KL integrerà una CPU e si infilerà in un socket,vedrà tutta la memoria e la utilizzerà per approvviggionarsi di dati da eseguire sui suoi 70 e oltre core,ho capito bene?.Se così, la memoria di sistema che andrà ad utilizzare non avrà prestazioni come quella impiegata direttamente su una scheda per slot PCI-E e dedicata alla GPU,cioè allora mi chiedo, nella visione unificata della memoria non ci saranno passaggi di dati avanti e indietro tra GPU, CPU e memoria centrale ok,ma non perderemo troppi benefici che possono scaturire da un elevato trasferimento di dati tra appunto la GPU e la sua memoria?

Il prossimo anno farei festa, al posto tuo. ;)

In che senso scusa?:what:

Bene. Potresti fornire qualche dettaglio? Cos'hai notato? Come ti trovi? Sono curioso di leggere il parere di un customer. :p

Diciamo che per compiere determinati lavori il tempo è passato da 10 a 4, ovviamente il merito non è solo di phi ma anche dei due 2880 che hanno sostituito i 2670 che c'erano nella r930, ovviamente non tutti i so che utilizzo permettono quel grado di parallelizzazione, a volte per avere un alto rendimento lavorativo sono "costretto" a lanciare anche due sessioni contemporaneamente, in ufficio abbiamo anche due ws con su delle tesla (non so dirti quale modello) però l'ing (credo fosse un informatico) che ci lavorava su è andato altrove e ora tra meccanici ed aereospaziali non sappiamo come metterci mano. :stordita:, però ricordo che con ansys, nastran e patran ci si faceva bella roba.

Beh, ma è come con le GPU: puoi utilizzare la loro memoria locale, ma l'operazione di trasferimento dei dati da CPU a GPU, e viceversa, rimane onerosa.

Non penso che ti lamenti del fatto di non poter utilizzare liberamente la memoria della GPU. Con Knights Corner (KC) al momento è così, perché la scheda si trova collegata al PC tramite lo stesso PCI-Express.

Con Knights Landing (KL) sarà diverso, ma ne parlo meglio dopo.

Scusami, ma non ho capito se ti riferisci all'attuale situazione con KC o con KL.

Per tagliare la testa al toro espongo le casistiche per entrambi.

Presupponendo una workstation con due socket dotati ognuno di un "normale" processore Xeon, 32+32 = 64 GB totali di RAM (di sistema), e una scheda Xeon Phi basata su KC con 8GB di memoria (VRAM), gli scenari possibili sono i seguenti:
1) offloading. I 64GB di memoria contengono tutto, e man mano spostano dei dati su e dalla VRAM (sempre tramite il PCI-Express), scaricando buona parte del lavoro su KC. Parlo di buona parte, perché una parte la possono elaborare le due CPU Xeon; infatti è possibile sfruttare qualunque dispositivo, siano esse le CPU o siano le schede Xeon Phi, per portare a termine il carico di lavoro. Si occupa il codice (generato dal compilatore e/o sfruttando OpenMP o MPI) di distribuire i job a tutti questi elementi. La memoria non è unificata, ma i due tipi di memoria sono separati, e il codice generato si occupa di copiare i dati avanti e indietro a seconda di come servono per quel pezzo particolare di codice che dev'essere eseguito.



e no, il problema sta proprio li; nel caso delle GPU il trasferimento dei dati puo avvenire solo all'inizio, prima della partenza del render; se la scena+texture+xref, tutto insomma, supera la quantita di memoria on-board non puoi caricarla successivamente, deve stare tutto all'interno.

da quello che diceva il creatore di Vray l'attuale KC ha lo stesso limite, quindi o carichi tutto subito in ram video o ti attacchi.

quello che chiedevo su KL era se era cambiata o meno questa cosa e come veniva vista la memoria, visto il fatto che ora è possibile montarlo su socket normale e mettergli le DDR4;

nel senso, le GPU future avranno al memoria condivisa in hardware, quindi teoricamente non dovrebbe esserci piu questo problema e il render partira indipendentemente dalla quantita di vram.

almeno Vray, e iRay con le GPU funzionano cosi.




Arriviamo finalmente a KL. Essendo il successore di KC, presumibilmente dovrebbe poter gestire tutti e 3 gli scenari. Sicuramente supporterà il terzo, l'esecuzione nativa, ma questo, a differenza di KC, sarà proprio il suo punto di forza. Il motivo è presto detto: KL non ha bisogno di essere infilato in una scheda di un computer per poter funzionare, ma è in grado da solo di fungere da computer. Si tratta a tutti gli effetti di una normale CPU Intel64 da questo punto di vista, esattamente come tutte le altre (Atom, i3, i5, i7), per cui è possibile costruire computer che hanno soltanto questo processore all'interno. In questo caso non serve l'offloading, perché il computer con KL ha già tutto quello che gli serve. Anzi, ha pure molto di più, visto che la memoria a disposizione non è limitata a 8GB, ma arriva fino a 384GB. Questo significa che cadono di colpo tutti i limiti di cui sopra: hai tanta memoria, e... tutta "unificata" (c'è solo quella!). Quindi non devi sincronizzare proprio nulla, e non ci sono copie avanti e indietro: l'applicazione, all'avvio, carica tutti i dati sui quali deve lavorare, e poi procede spedita a macinarli. In più ha pure fino a 16GB di cache (L4?) a disposizione.



se fosse la prima o la terza sarebbe ottimo :D

Nel tuo commento #7 c'è un link che non funziona: Myo e Myc li ho trovati in un mostro pdf di 3 e rotti Mega del Cern riferiti ad un Knights FERRY.
Qual è la roadmap che ha portato a Landing?
E' Ferry il penultimo ed attuale xeon phi disponibile da Intel?
Landing è da paura.

@AceGranger
Con quale rilascio di Knights si è verificato il problema di protezione termica?

La questione dell'efficienza e del surriscaldamento delle schede con i coprocessori è sempre attuale: anche se in Landing si adottano core assai più risparmiosi dipende sempre dal carico di lavoro e dal raffreddamento adottato la possibilità di spingere la performance verso limiti sempre più alti. Fermo restando che aumentando il numero dei core aumentano pure i consumi, per cui penso che l'efficienza vada intesa come la prestazione ottenibile a parità di consumi.

Esiste una diversità significativa fra sustained e peak performance?
Qual è il dato che viene solitamente fornito?

eh non so quale modello di preciso, è stata una conversazione veloce :(; non è sceso in particolari, quindi non so se andava sempre in protezione o solo in particolari situazioni. Comunque l'evento c'è stato a Ottobre 2013, quindi credo uno dei modelli in commercio in versione carentata con ventola perche dovrebbe finire nelle workstation.

"KL non ha bisogno di essere infilato in una scheda di un computer per poter funzionare, ma è in grado da solo di fungere da computer. Si tratta a tutti gli effetti di una normale CPU Intel64 da questo punto di vista, esattamente come tutte le altre (Atom, i3, i5, i7), per cui è possibile costruire computer che hanno soltanto questo processore all'interno".

E come diavolo sarà costruito e costituito un simile mostriciattolo?
Quale mobo e quale sk video?
Quale il sistema di raffreddamento?
Quale OS? Se più di uno in multiboot?


adottera lo stesso socket degli Xeon, quindi come mobo usera quelle.

La Math Kernel Library è quella deputata a velocizzare appunto calcoli,così come le librerire utilizzate dalle gpu nvidia all'interno del toolkit di CUDA,ora,una differenza di ben due ordini di grandezza ci suggerisce solo una cattiva ottimizzazione del codice oppure una differeza architetturale tra un intel core e un cuda core nel maneggiare determinate tipologie di calcoli?
Non avendo altre informazioni, come dicevo, mi è difficile capire dove possa essere il problema.

Escludo che sia un problema architetturale, e per due semplici ragioni.
La prima è logica/pratica, ed è che proprio il calcolo matriciale è alla base della tipologia di calcoli eseguita in sistemi HPC. Se Xeon Phi non avesse prestazioni adeguate non se la sarebbe calcolata nessuno; invece si trova addirittura fra i primi 10 supercomputer.
La seconda riguarda l'analisi tecnica dell'architettura. Proprio per questo tipo di calcoli si possono sfruttare con facilità sia le istruzioni vettoriali (incluse quelle di tipo FMAC, che consentono di eseguire contemporaneamente una moltiplicazione e una somma) per processare un gruppo di elementi sia i numerosi core suddividendo il carico di lavoro. Peraltro sono presenti delle istruzioni di gather/scatter per gestire con scioltezza anche il caso di elementi sparsi in memoria, a cui aggiungo i registri "di maschera(mento)" per le condizioni ai bordi (quando ci sono meno elementi rispetto a quelli necessari per riempire interamente un registro vettoriale).

Per cui, tornando a prima, penso che ci sia qualche problema che impedisce di trarre pieno vantaggio da quest'architettura.
Cioè mi interessava capire se queste due architetture così diverse sarenno capaci di gestire più efficentemente determinate operazione piuttosto che altre.
E' normale che una particolare architettura sia più portata per certi tipi di calcoli piuttosto che per altri. Lo vedi anche con le normali CPU: fra Intel e AMD a parità di FLOPS erogabili ci sono delle differenze prestazionali.
Un altra perplessità poi, nel futuro,KL integrerà una CPU e si infilerà in un socket,vedrà tutta la memoria e la utilizzerà per approvviggionarsi di dati da eseguire sui suoi 70 e oltre core,ho capito bene?.
Esattamente.
Se così, la memoria di sistema che andrà ad utilizzare non avrà prestazioni come quella impiegata direttamente su una scheda per slot PCI-E e dedicata alla GPU,cioè allora mi chiedo, nella visione unificata della memoria non ci saranno passaggi di dati avanti e indietro tra GPU, CPU e memoria centrale ok,ma non perderemo troppi benefici che possono scaturire da un elevato trasferimento di dati tra appunto la GPU e la sua memoria?
Veramente la memoria utilizzata è proprio quella tipicamente in uso nelle GPU, e dunque con una banda elevata. Con KC la banda è già di per sé molto elevata, ma con KL la situazione dovrebbe essere ancora migliore grazie all'adozione della DDR4.

Quindi c'è sicuramente di che star tranquilli: niente trasferimenti inutili, e banda estremamente elevata.
In che senso scusa?:what:
Perché con KL l'incremento prestazionale è ancora più marcato, per cui hai tutto da guadagnarci aggiornando a KL.

Ma intanto ti godi KC...
Diciamo che per compiere determinati lavori il tempo è passato da 10 a 4, ovviamente il merito non è solo di phi ma anche dei due 2880 che hanno sostituito i 2670 che c'erano nella r930,
Senz'altro.
ovviamente non tutti i so che utilizzo permettono quel grado di parallelizzazione, a volte per avere un alto rendimento lavorativo sono "costretto" a lanciare anche due sessioni contemporaneamente, in ufficio abbiamo anche due ws con su delle tesla (non so dirti quale modello) però l'ing (credo fosse un informatico) che ci lavorava su è andato altrove e ora tra meccanici ed aereospaziali non sappiamo come metterci mano. :stordita:, però ricordo che con ansys, nastran e patran ci si faceva bella roba.
Perché queste architetture si prestaziono bene per le problematiche di cui hai parlato.
e no, il problema sta proprio li; nel caso delle GPU il trasferimento dei dati puo avvenire solo all'inizio, prima della partenza del render; se la scena+texture+xref, tutto insomma, supera la quantita di memoria on-board non puoi caricarla successivamente, deve stare tutto all'interno.

da quello che diceva il creatore di Vray l'attuale KC ha lo stesso limite, quindi o carichi tutto subito in ram video o ti attacchi.
Non è così: dipende tutto dalla modalità in cui lo utilizzi. Come dicevo prima, sfruttando MYO puoi mappare tutta la memoria condivisa fra CPU e Xeon Phi in uno spazio d'indirizzamento comune e in maniera trasparente all'applicazione. La sincronizzazione dei dati è automatica, e quindi se Xeon Phi non trova un dato nella sua memoria locale, internamente si attiva il meccanismo di caricamento di quel dato, che al completamento del quale consente a Xeon Phi di riprendere l'esecuzione esattamente da dov'era stato interrotto.

Il problema, però, è che ci sono dei costi da pagare: quello del page fault (che fa andare la CPU in kernel space; e poi deve ovviamente ritornare) e quello della lettura dei dati dalla memoria principale tramite PCI-Express.

Per questo motivo MYO è sconsigliabile nei casi in cui si accede in maniera troppo poco sequenziale / locale alla memoria, mentre va bene quando si possa sfruttare la località dei dati (e, dunque, minimizzare page fault & sincronizzazioni).
quello che chiedevo su KL era se era cambiata o meno questa cosa e come veniva vista la memoria, visto il fatto che ora è possibile montarlo su socket normale e mettergli le DDR4;

nel senso, le GPU future avranno al memoria condivisa in hardware, quindi teoricamente non dovrebbe esserci piu questo problema e il render partira indipendentemente dalla quantita di vram.

almeno Vray, e iRay con le GPU funzionano cosi.
E' come ho già detto prima: è un solo tipo di memoria, che quindi è, per forza di cose, "condivisa". Dunque non avrai più alcun problema di sincronizzazione dei dati, perché KL può essere usato, ed è a tutti gli effetti, come un computer "normale".
se fosse la prima o la terza sarebbe ottimo :D
La terza è il dominio d'elezione di KL. La prima modalità (offload "classico") è, invece, quello per KC.
Nel tuo commento #7 c'è un link che non funziona:
E' strano, perché ho appena controllato: c'è un link e si apre.
Myo e Myc li ho trovati in un mostro pdf di 3 e rotti Mega del Cern riferiti ad un Knights FERRY.
Esiste solo MYO. MYC non è un modello di utilizzo di Xeon Phi.
Qual è la roadmap che ha portato a Landing?
In tutta onestà non ne sono a conoscenza, e comunque, anche se lo fossi, mi spiace, ma non ne potrei parlare.
E' Ferry il penultimo ed attuale xeon phi disponibile da Intel?
Knights Ferry è il predecessore di KC, ma che io sappia (da utente comune: non ho altre informazioni in merito, perché quando sono arrivato c'era già da tempo KC, e io ho lavorato soltanto a questo) è stato distribuito soltanto a poche aziende che lavorano nell'ambito dell'HPC.
Landing è da paura.
:)
"KL non ha bisogno di essere infilato in una scheda di un computer per poter funzionare, ma è in grado da solo di fungere da computer. Si tratta a tutti gli effetti di una normale CPU Intel64 da questo punto di vista, esattamente come tutte le altre (Atom, i3, i5, i7), per cui è possibile costruire computer che hanno soltanto questo processore all'interno".

E come diavolo sarà costruito e costituito un simile mostriciattolo?
Come una workstation e/o rack server, immagino.
Quale mobo e quale sk video?
Non ne ho idea. Ma non penso che serva una scheda video, visto l'ambito di utilizzo. Al più se ne potrebbe integrare qualcuna (nella scheda madre, nel southbridge, oppure all'interno della CPU) soltanto per il controllo / monitoraggio del mostriciattolo, ma è soltanto la mia opinione "da utente qualunque" che sto esprimendo in questo momento.
Quale il sistema di raffreddamento?
Boh. :D Non è il mio campo e non mi sono informato.
Quale OS?
Supporta sicuramente una particolare versione di Linux, visto che XC la usa già.

Non so se supporti Windows. In linea teorica dovrebbe funzionare tranquillamente con qualunque s.o. esistente per IA-32 e Intel64/x64.
Se più di uno in multiboot?
Non lo so, mi spiace, ma non vedo alcun limite a ciò, essendo praticamente un computer.
adottera lo stesso socket degli Xeon, quindi come mobo usera quelle.
Su questo non ho letto notizie.

Questo tipo di architettura se la può permettere solo Intel con il suo PP avanzato.
Infatti FLops/W non è meglio di una GPU Kepler che però è costruita con un PP peggiore.
Ciò che avvantaggia Intel inoltre è il fatto che può farsi un canale di comunicazione ad-hoc tra questo coprocessore e le sue CPU in modo da condividere la memoria, cosa che sulle GPU oggi non è possibile fare.

Io non vedo alcuna "mostruosità" in questo progetto. A metà 2015 si scontrerà con la mattonella nvidia Maxwell based che sarà fatta a 16nm vs i 14 di Intel, entrambi Finfet (oggi Intel a 22 Finfet vs nvidia 28nm planare).
Visto che Kepler già è meglio in GFlops/W, direi che Intel deve fare davvero ben per riuscire a competere con Maxwell che per il poco che abbiamo visto con il minuscolo GM107 promette di essere fino a 3/4x più veloce nel calcolo GPGPU con lo stesso consumo di energia con lo stesso PP.

Non fosse sufficiente la questione della forza bruta esprimibile dalla GPU nvidia, c'è da tenere conto che per quanto riguarda la connettività con la CPU IBM integrerà un bus apposta per le GPU sulla sua nuova architettura Power, architettura che già ora senza particolari "aiuti da acceleratrici" compete alla grande per prestazioni/W.

Infine nvida ha questo fantomatico progetto Denver in cantiere che sta per venire finalmente realizzato che prevede CPU ARM a diretto contatto con le unità di elaborazione vettoriale della GPU. Anche in questo caso, data abbastanza RAM, è possibile rendere la scheda un micro computer completamente indipendente che non deve richiedere nulla all'host che la o
ospita (se ha un host, potrebbe benissimo essere anch'essa un computer a sé stante).

Il problema dell'architettura Intel lo vedo sul lato prestazioni/W. E' sempre vero che integrando sempre più unità di calcolo è possibile ottenere prestazioni sempre più alte, ma i consumi esplodono. E quando hai unità di calcolo meno efficienti di quelle piccole delle GPU perché ti porti dietro un fardello che nulla aiuta a eseguire più velocemente i calcoli, quando le unità integrabili diventano davvero tante (vedi l'esplosione del loro numero con le ultime generazioni di GPU) la differenza si fa sentire sempre di più.
Se consideriamo che quello che fa Intel lo potrebbe fare un qualunque produttore di CPU con licenza ARM che accanto ad ogni micro core ARM può mettergli un'unità di calcolo vettoriale dedicata (che è quello che poi effettivamente fa il calcolo, il resto è un di più di gestione che non ha alcun senso portarsi dietro in un sistema HPC), il problema efficienza diventa un vero problema. Soprattutto quando i rivali arrivano competere con te con un processo produttivo che può considerarsi quasi alla pari.

Vedremo cosa ne verrà, ma se oggi devo puntare su una architettura in grado di scalare e di essere super efficiente io punterei all'architettura Power di IBM + GPU collegata con bus ad-hoc per la condivisione della memoria.
In seconda battuta, per sistemi di dimensioni minori al sistema all-in-one di nvidia (ARM+GPU).
Sempre che da qui al 2016 qualcuno non se ne esca con un'altra architettura simile a quella Intel su base AM (come detto centinaia di micro core ARM + enorme unità di calcolo vettoriale x ciascuna di esse). Anche questa potrebbe dire la sua.

Questo tipo di architettura se la può permettere solo Intel con il suo PP avanzato.
Infatti FLops/W non è meglio di una GPU Kepler che però è costruita con un PP peggiore.
"Meglio" in cosa? Le architetture sono diverse, e alla fine conta quello che riescono a fare, quanto costano, quanto dissipano, e pure quanto costa realizzare o portarci del software (aspetto, questo, tutt'altro che trascurabile, anche se spesso non viene considerato).
Ciò che avvantaggia Intel inoltre è il fatto che può farsi un canale di comunicazione ad-hoc tra questo coprocessore e le sue CPU in modo da condividere la memoria, cosa che sulle GPU oggi non è possibile fare.
Al momento KC condivide le stesse limitazioni delle GPU nello scenario di offload (e MYO), perché l'applicazione principale gira sulla CPU principale (che non è uno Xeon Phi), che si occupa poi di smistare il codice di offload alle schede Xeon Phi. Il tutto utilizzando il lento bus (in realtà collegamento punto-punto) PCI-Express.

Soltanto nella modalità nativa tutto ciò sparisce, perché il codice gira già all'interno di Xeon Phi, nei suoi core. Ed è questo scenario che verrà ulteriormente esaltato da KL, in quanto sarà disponibile come computer "standalone", in grado di operare interamente da solo, e non come coprocessore.

Ma in questa modalità non possiamo parlare di CPU e coprocessori, perché non esiste alcuna distinzione: un core è costituito da un'unità scalare (la parte "intera" / "scalare" / general purpose) e da una vettoriale, che fanno parte di un tutt'uno. E' esattamente come un normale processore che esegue istruzioni che utilizzano l'ALU oppure l'unità SIMD: vengono eseguite nella stessa pipeline (per lo meno la parte comune, quella iniziale) e utilizzano le stesse risorse (cache L1/L2/L3/memoria, TLB, unità di load/store con annesse AGU, e perfino i registri general-purpose quando servono all'unità vettoriale). Anche la memoria, per le stesse ragioni, non è "condivisa": è unica, e viene utilizzata esattamente allo stesso modo, con le stesse risorse, e le stesse modalità.

Con ciò voglio dire che non esiste alcuna differenza fra unità scalare/intera e vettoriale: sono fuse nello stesso core esattamente come oggi una normalissima CPU fonde nello stesso core l'unità intera e quella SIMD (MMX/SSE/AVX). Per cui non c'è bisogno di alcun canale di comunicazione ad-hoc: si utilizzano gli stessi bus interni.

Discorso diverso per i core che devono sincronizzarsi o contendersi l'accesso alla memoria, dove c'è un arbiter che gestisce il tutto, in maniera simile a quanto avviene anche con le GPU o con altre piattaforme multicore (ad esempio il Cell della PS3).

Spero che adesso sia più chiaro.
Io non vedo alcuna "mostruosità" in questo progetto. A metà 2015 si scontrerà con la mattonella nvidia Maxwell based che sarà fatta a 16nm vs i 14 di Intel, entrambi Finfet (oggi Intel a 22 Finfet vs nvidia 28nm planare).
Visto che Kepler già è meglio in GFlops/W, direi che Intel deve fare davvero ben per riuscire a competere con Maxwell che per il poco che abbiamo visto con il minuscolo GM107 promette di essere fino a 3/4x più veloce nel calcolo GPGPU con lo stesso consumo di energia con lo stesso PP.
Anche KL avrà una (micro-)architettura di gran lunga migliore rispetto a KC, essendo basata sul core Silvermont (che trovi in BayTrail). Non so se hai presente il passaggio dai vecchi Atom in-order ai nuovi out-of-order: c'è da aspettarsi qualcosa di migliore, visto che KC è, invece, basato sostanzialmente su un Pentium (mentre Atom è basato su core Bondwell, che su questa base ha poi introdotto tante altre migliorie).
Non fosse sufficiente la questione della forza bruta esprimibile dalla GPU nvidia, c'è da tenere conto che per quanto riguarda la connettività con la CPU IBM integrerà un bus apposta per le GPU sulla sua nuova architettura Power, architettura che già ora senza particolari "aiuti da acceleratrici" compete alla grande per prestazioni/W.
Questo, come dicevo prima, non serve a KL, che ha già "tutto incluso".
Infine nvida ha questo fantomatico progetto Denver in cantiere che sta per venire finalmente realizzato che prevede CPU ARM a diretto contatto con le unità di elaborazione vettoriale della GPU. Anche in questo caso, data abbastanza RAM, è possibile rendere la scheda un micro computer completamente indipendente che non deve richiedere nulla all'host che la o
ospita (se ha un host, potrebbe benissimo essere anch'essa un computer a sé stante).
Rimane il fatto che il core ARM deve comunicare con il core della GPU, mentre ciò non è affatto necessario con KL (e con KC operando nativamente).
Il problema dell'architettura Intel lo vedo sul lato prestazioni/W. E' sempre vero che integrando sempre più unità di calcolo è possibile ottenere prestazioni sempre più alte, ma i consumi esplodono.
Anche le GPU integrano sempre più core.
E quando hai unità di calcolo meno efficienti di quelle piccole delle GPU perché ti porti dietro un fardello che nulla aiuta a eseguire più velocemente i calcoli, quando le unità integrabili diventano davvero tante (vedi l'esplosione del loro numero con le ultime generazioni di GPU) la differenza si fa sentire sempre di più.
Se il fardello a cui ti riferisci è la cosiddetta "x86 tax", questo vale sostanzialmente per la sezione di decodifica, che è più complessa, per cui richiede più transistor e consuma di più (anche se da quest'ultimo punto di vista Intel ha fatto un gran lavoro negli ultimi con le ultime micro-architetture).

Ma, per contro, essendo un processore x86, è anche un CISC che consente di ottenere codice mediamente più veloce e compatto, perché in grado di eseguire molto più lavoro "utile" nelle istruzioni, quando un RISC ne richiede mediamente di più (e il codice è meno denso -> più spazio in memoria e nelle cache -> meno TLB hit -> meno prestazioni; inoltre esistono più dipendenze nella pipeline fra le istruzioni -> prestazioni più ridotte).
Se consideriamo che quello che fa Intel lo potrebbe fare un qualunque produttore di CPU con licenza ARM che accanto ad ogni micro core ARM può mettergli un'unità di calcolo vettoriale dedicata (che è quello che poi effettivamente fa il calcolo,
E perché non lo fanno allora? Tra l'altro proprio ARM ha una ricca tradizione di estensioni (anche vettoriali) alla sua architettura, non ultima la versione ARM64 dell'unità SIMD NEON, che però non ha portato poi molto, se non un raddoppio dei registri e qualche istruzione in più.

Comunque ne parlo meglio dopo.
il resto è un di più di gestione che non ha alcun senso portarsi dietro in un sistema HPC),
Non mi è chiara questa parte. Potresti specificare meglio, cortesemente?
il problema efficienza diventa un vero problema. Soprattutto quando i rivali arrivano competere con te con un processo produttivo che può considerarsi quasi alla pari.
Al momento i segnali in tal senso non sono incoraggianti per i concorrenti di Intel. Basti vedere i ritardi annunciati di recente, causa problemi di TSMC...
Vedremo cosa ne verrà, ma se oggi devo puntare su una architettura in grado di scalare e di essere super efficiente io punterei all'architettura Power di IBM + GPU collegata con bus ad-hoc per la condivisione della memoria.
In seconda battuta, per sistemi di dimensioni minori al sistema all-in-one di nvidia (ARM+GPU).
In entrambi i casi devi condividere la memoria fra le due diverse tipologie di unità di calcolo, e mettere in piedi appositi canali di comunicazione.

Tutte cose non necessarie con KL, e che tra l'altro richiedono silicio, fanno aumentare i consumi, e impattano sulle prestazioni.
Sempre che da qui al 2016 qualcuno non se ne esca con un'altra architettura simile a quella Intel su base AM (come detto centinaia di micro core ARM + enorme unità di calcolo vettoriale x ciascuna di esse). Anche questa potrebbe dire la sua.
Non è semplicemente aumentando la dimensione dei registri dell'unità di calcolo vettoriale (peraltro in controtendenza con le GPU, che hanno tante unità che operano su registri di piccola dimensione; per cui bisognerebbe proprio ripensare l'intera architettura) che si ottengono miglioramenti prestazionali.

Se dai un'occhiata al funzionamento dell'unità AVX-512 (che sarà alla base di KL, e che dovrebbe arrivare poi su desktop & mobile con Skylake), già soltanto la struttura del prefisso utilizzato negli opcode mostra quando "lavoro utile" è possibile effettuare eseguendo una singola istruzione vettoriale.

Ecco qui un po' di documentazione in merito:
http://en.wikipedia.org/wiki/EVEX_prefix
https://software.intel.com/en-us/blogs/2013/avx-512-instructions
http://www.agner.org/optimize/blog/read.php?i=288

L'ultimo è una comoda sintesi (anche se troppo sintetica: mancano dei dettagli importanti, come la conversione al volo in int32/64 o float32/64 di un valore "ridotto" caricato dalla memoria).

Come puoi notare (in particolare del primo link), ogni istruzione occupa almeno 6 byte (quindi ben più dei 4 di PowerPC o ARM & ARM64), ma col vantaggio non indifferente di poter fare molto più operazioni allo stesso tempo. Molto importante è, a mio avviso, la possibilità di poter prelevare un valore dalla memoria come prima sorgente per l'istruzione eseguita, che consente di risparmiare una load, un registro, ed evita dipendenze nella pipeline. Comunque anche le altre feature selezionabili sono decisamente utili.

Per quanto possano mettersi d'impegno, i produttori di chip RISC non posso competere su questo fronte, perché il loro paradigma è molto rigido: load/store solo tramite apposite istruzioni che fanno soltanto questo; opcode a lunghezza fissa e con spazio limitato (32 bit in tutto) che costringe a notevoli compromessi in termini di informazioni/feature "impacchettabili" in una singola istruzione.

Intel usando i famigerati prefissi è riuscita a estendere la sua architettura, permettendosi anche il lusso di realizzare unità SIMD all'avanguardia (AVX prima, ma soprattutto AVX-512 adesso). E il tutto senza ricorrere a coprocessori (come si dovrebbe fare per "unire in matrimonio" i core PowerPC/ARM coi core GPU di nVidia)...

"Meglio" in cosa? Le architetture sono diverse, e alla fine conta quello che riescono a fare, quanto costano, quanto dissipano, e pure quanto costa realizzare o portarci del software (aspetto, questo, tutt'altro che trascurabile, anche se spesso non viene considerato).
Pronti via siamo già partiti con il piede sbagliato. Migliore è scritto lì. Flops/W.

Al momento KC condivide le stesse limitazioni delle GPU nello scenario di offload (e MYO), perché l'applicazione principale gira sulla CPU principale (che non è uno Xeon Phi), che si occupa poi di smistare il codice di offload alle schede Xeon Phi. Il tutto utilizzando il lento bus (in realtà collegamento punto-punto) PCI-Express.

Soltanto nella modalità nativa tutto ciò sparisce, perché il codice gira già all'interno di Xeon Phi, nei suoi core. Ed è questo scenario che verrà ulteriormente esaltato da KL, in quanto sarà disponibile come computer "standalone", in grado di operare interamente da solo, e non come coprocessore.
Al momento KC non è meglio dell'architettura usata con le GPU per quanto riguarda l'efficienza dei calcoli. Intel prevede di ridurre la cosa portando il coprocessore KL a fianco degli XEON con canale ad-hoc e memoria condivisa.

Questo darebbe un bel boost prestazionale.
L'avere l'intero codice che gira all'interno di KL non lo vedo come positivo. Porterebbe via risorse a quello che il processore deve fare: calcoli a manetta, non gestire codice "di contorno" o eseguire istruzioni secondarie. Il coprocessore con le sue decine di unità di calcolo vettoriale è lì per fare i conti vettoriali. Il resto è inutile. Vedi dopo


Ma in questa modalità non possiamo parlare di CPU e coprocessori, perché non esiste alcuna distinzione: un core è costituito da un'unità scalare (la parte "intera" / "scalare" / general purpose) e da una vettoriale,...

bla bla bla,

Per cui non c'è bisogno di alcun canale di comunicazione ad-hoc: si utilizzano gli stessi bus interni.

L'affiancamento con bus dedicato è riferito a die CPU al die coprocessore.
Internamente al processore tutti sono liberi di fare quello che vogliono. Esternamente invece bisogna connettersi con la memoria il cui controller è sul die della CPU per Intel. Le terze parti sono quindi tagliate fuori. nvidia ha pensato bene di rimuovere questo svantaggio usando un bus ad hoc su architettura Power.

Anche KL avrà una (micro-)architettura di gran lunga migliore rispetto a KC, essendo basata sul core Silvermont (che trovi in BayTrail). Non so se hai presente il passaggio dai vecchi Atom in-order ai nuovi out-of-order: c'è da aspettarsi qualcosa di migliore, visto che KC è, invece, basato sostanzialmente su un Pentium (mentre Atom è basato su core Bondwell, che su questa base ha poi introdotto tante altre migliorie).
Dell'architettura migliore della parte non dedicata al calcolo poco ce ne facciamo. Quello che conta in queste architetture è che facciano i conti vettoriali moooolto velocemente. E questo lo fa un'unità di calcolo estremamente potente o un aumento del loro numero. L'uso del core Silvermont serve solo per cercare di diminuire in qualche modo il consumo di energia "parassita" al quella necessaria per il calcolo.

Rimane il fatto che il core ARM deve comunicare con il core della GPU, mentre ciò non è affatto necessario con KL (e con KC operando nativamente).
Certo che ci deve comunicare, ma un conto è farlo attraverso un bus di comuncazione strozzato in banda e con la necessità di ricopiare nella memoria della GPU quello che serve, un conto è farlo attraverso un bus interno, con la memoria condivisa.
La differenza tra l'architettura Intel e quella delle GPU è tutta qui: da un parte hai un sistema formato da una coppia CPU+SIMD che comunica uno a uno che richiede che ogni istruzione sia decodificata su tutte le copie presenti, dall'altra hai un sistema formato da poche CPU e molte unità di calcolo (SIMD, MIMD, pippo, caio e folletti vari non ha importanza) che decodificano una sola volta l'istruzione che poi viene sparata in parallelo su tutte le unità di calcolo.

Mentre nel primo caso per aumentare il numero delle unità di calcolo devi anche portarti dietro la sua relativa CPU che non fa molto se non "dipacciare" i comandi di calcolo (un passa carte) ad una unità molto grande e complessa, con le seconde architetture ti puoi permettere di mantenere lo stesso numero di CPU che "dispacciano" la stessa identica istruzione su un numero di unità di calcolo piccole e semplici sempre maggiore.
L'aumento di prestazioni per l'aumento di unità di calcolo sulla stessa area è in quest'ultimo caso molto ma molto maggiore.

Anche le GPU integrano sempre più core.
Che sono una frazione della dimensione di un core x86+relativa unità di calcolo SIMD. Il fattore scaling avvantaggia l'architettura delle GPU.

Se il fardello a cui ti riferisci è la cosiddetta "x86 tax", questo vale sostanzialmente per la sezione di decodifica, che è più complessa, per cui richiede più transistor e consuma di più (anche se da quest'ultimo punto di vista Intel ha fatto un gran lavoro negli ultimi con le ultime micro-architetture).

Ma, per contro, essendo un processore x86, è anche un CISC che consente di ottenere codice mediamente più veloce e compatto, perché in grado di eseguire molto più lavoro "utile" nelle istruzioni, quando un RISC ne richiede mediamente di più (e il codice è meno denso -> più spazio in memoria e nelle cache -> meno TLB hit -> meno prestazioni; inoltre esistono più dipendenze nella pipeline fra le istruzioni -> prestazioni più ridotte).
As before, se devo calcolare la moltiplicazione di due matrici 10000x10000 dell'enorme efficienza delle istruzione x86 non me ne può fregare di meno. Serve che siano le unità vettoriali a lavorare alla massima efficienza. L'energia usata dal modulo di decodifica x86 per ogni istruzione che arriva alla coppia x86+SIMD non serve a nulla in termini di potenza di calcolo. E' tutta energia che va persa. E va persa ad ogni istruzione su ogni coppia CPU+SIMD. Nelle GPU una sola decodifica, decine o centinaia di unità d'esecuzione. Efficienza massima.

E perché non lo fanno allora? Tra l'altro proprio ARM ha una ricca tradizione di estensioni (anche vettoriali) alla sua architettura, non ultima la versione ARM64 dell'unità SIMD NEON, che però non ha portato poi molto, se non un raddoppio dei registri e qualche istruzione in più.
Perché progettare questo tipo di "mostri" (sia in termini di HW e di SW) non costa 4 lire e chi se lo può permettere non sono molti oltre che non sono molti quelli che troverebbero spazio nel mercato?
Persino IBM ha avuto problemi a sviluppare il Cell che per potenza ed efficienza ha dimostrato di non essere secondo a nessuno. Anzi.

Sarà nvidia a portare ARM nel mondo server HPC. Sia con la soluzione ARM custom + GPU sia con la soluzione legata all'architettura Power di IBM.

Al momento i segnali in tal senso non sono incoraggianti per i concorrenti di Intel. Basti vedere i ritardi annunciati di recente, causa problemi di TSMC...
Saranno incoraggianti per Intel il ritardo di 9 mesi e i 6 miliardi di dollari extra sul costo dei 14nm. Che non sa cosa produrci, visto che ogni anno produce sempre meno processori. Guarda caso, tanto non è importante il suo processo produttivo per colmare il gap con l'architettura ARM che non si azzarda nemmeno a proporre di usare la sua inutile nuova fabbrica 14nm per la produzione di SoC ARM. Avrebbe la fila fuori dalla porta per usarla. Ovviamente dall'altra parte il calo di vendita della sua inefficiente architettura avrebbe un'accelerazione stratosferica.

Tutte cose non necessarie con KL, e che tra l'altro richiedono silicio, fanno aumentare i consumi, e impattano sulle prestazioni.
Con l'architettura KL ogni impatto ce l'hai nella coppia CPU+SIMD. Non è che questi parlino "gratis per volere del Signore".

Non è semplicemente aumentando la dimensione dei registri dell'unità di calcolo vettoriale (peraltro in controtendenza con le GPU,

Intel usando i famigerati prefissi è riuscita a estendere la sua architettura, permettendosi anche il lusso di realizzare unità SIMD all'avanguardia (AVX prima, ma soprattutto AVX-512 adesso). E il tutto senza ricorrere a coprocessori (come si dovrebbe fare per "unire in matrimonio" i core PowerPC/ARM coi core GPU di nVidia)...
Bla bla bla, parlando di come qualcun altro potrebbe fare la stesa cosa di Intel vieni a parlarmi di quanto sia bella l'architettura dell'unità vettoriale? Perché gli altri non potrebbero farla? E' esclusiva Intel? La potenza di Intel è nell'aver abbinato un'unità di calcolo vettoriale con una che esegue il codice x86? Che cambia se invece che una CPU x86 ci metto una con istruzione ARM/MIPS/Power/Spark o zio peppino? Chi compie effettivamente il calcolo?
Non hai capito la differenza che c'è tra l'architettura messa in piedi da Intel e quella messa in piedi dai GPUari. O meglio, fai tanta confusione perché non la si capisca.
Con l'architettura delle GPU non serve che vi sia un forte legame tra la parte scalare e quella vettoriale della CPU, ma sono due cluster separati che comunicano per sincronizzarsi. Senza un bus ad-hoc ma su PCI c'è un forte overhead per la comunicazione. Se hai un bus ad-hoc con condivisione delle risorse ottieni un sistema super scalabile ed efficiente dove bilanci il carico di lavoro tra scalare e vettoriale come vuoi a seconda di quante unità monti di qui o di là.

"Meglio" in cosa? Le architetture sono diverse, e alla fine conta quello che riescono a fare, quanto costano, quanto dissipano, e pure quanto costa realizzare o portarci del software (aspetto, questo, tutt'altro che trascurabile, anche se spesso non viene considerato).
Cut..



Un consiglio, visto il tuo interlocutore lascia stare fin d'ora e non perder tempo.

Un consiglio, visto il tuo interlocutore lascia stare fin d'ora e non perder tempo.
Quando l'inutilità comincia a fare la sua presenza...

Pronti via siamo già partiti con il piede sbagliato. Migliore è scritto lì. Flops/W.
Che non vuol dire nulla di per sé. La soluzione "migliore" è rappresentata dal miglior compromesso raggiungibile per risolvere un determinato problema. Se un'architettura con minore rapporto Flops/Watt mi permette di risolvere il mio problema più velocemente e/o economicamente di un'altra con un miglior rapporto Flops/Watt, è la prima a risultare "migliore" della seconda.

L'ingegneria non è fatta di misure astratte, ma di soluzioni adeguate ai problemi concreti che capita di affrontare.

Ciò precisato, KL è accreditato di 14-16GFLOPS/W. Hai informazioni sulla prossima Tesla basata su Maxwell?
Al momento KC non è meglio dell'architettura usata con le GPU per quanto riguarda l'efficienza dei calcoli.
Vedi sopra.
Intel prevede di ridurre la cosa portando il coprocessore KL a fianco degli XEON con canale ad-hoc e memoria condivisa.
Assolutamente no. E' scritto anche nella slide allegata alla news: KL è in grado di funzionare come CPU standalone. Quindi da sola, senza alcun altra CPU Xeon da utilizzare.

KL è perfettamente in grado di ricoprire il ruolo che aveva prima KC E anche quello di uno Xeon.
Questo darebbe un bel boost prestazionale.
Non c'è bisogno di Xeon per avere un gran boost prestazionale. Al contrario, è proprio svincolandosi da una CPU con la quale perde tempo a dialogare (tramite il lentissimo PCI-Express) che le prestazioni saranno di gran lunga migliori.
L'avere l'intero codice che gira all'interno di KL non lo vedo come positivo.
Al contrario: è la chiave di volta per ottenere le migliori prestazioni. Vedi sopra.
Porterebbe via risorse a quello che il processore deve fare: calcoli a manetta, non gestire codice "di contorno" o eseguire istruzioni secondarie. Il coprocessore con le sue decine di unità di calcolo vettoriale è lì per fare i conti vettoriali. Il resto è inutile. Vedi dopo
KC integra 61 core, e in genere uno di essi viene deputato a gestire la comunicazione con la CPU. Funge, insomma, da "CPU" per coordinare le richieste di lettura / scrittura (in particolare con MYO) e per smistare i carichi di lavoro. Ma non è necessario riservare un core soltanto per questo; infatti può benissimo essere utilizzato al pari degli altri core per macinare numeri. Tutto è a livello programmatico, insomma.

Con KL non vedo differenze da questo punto di vista: un core potrebbe essere riservato per fungere da master. Senza, per questo, avere bisogno di una CPU come Xeon, con la quale ci sarebbero i problemi che ha già KC, come pure le GPU.
L'affiancamento con bus dedicato è riferito a die CPU al die coprocessore.
Internalmente al processore tutti sono liberi di fare quello che volgiono. Esternamente invece bisogna connettersi con la memoria che è sul die della CPU per Intel. Le terze parti sono quindi tagliate fuori. nvidia ha pensato bene di rimuovere questo svantaggio usando un bus ad hoc su architettura Power.
Scusami, ma questo riguarda, per l'appunto, nVidia che deve interfacciare i SUOI core con quelli POWER.

KL, come ho già ripetuto diverse volte, NON ne ha bisogno, perché l'unità vettoriale è parte integrante, assieme a quella "scalare" / "intera" / general purpose, del core Intel64. Non serve alcun canale per far comunicare unità vettoriale e scalare. Non serve alcun bus dedicato per interfacciare l'unità vettoriale con la memoria, perché usa quello in comune con l'unità scalare. Non c'è bisogno di alcuna comunicazione fra i due (a parte in alcuni contesti, ma evito di scendere in dettagli di troppo basso livello, che sono totalmente trasparenti al programmatore) perché sono unità che semplicemente eseguono i compiti smistati loro tramite il normalissimo flusso di istruzioni eseguite.

Spero sia chiaro questa volta. Non so come altro spiegarlo.
Dell'architettura migliore della parte non dedicata al calcolo poco ce ne facciamo. Quello che conta in queste architetture è che facciano i conti vettoruiali moooolto velocemente. E questo lo fa un'unità di calcolo estremamente potente o un aumento del loro numero.
Anche le applicazioni che fanno massiccio uso di calcoli vettoriali hanno bisogno di eseguire altri tipi di istruzione. Se fosse possibile concentrarsi esclusivamente sul calcolo vettoriale, avremmo risolto tutti i problemi di scalabilità: basterebbe integrare enormi unità di calcolo vettoriale, riducendo la parte "scalare" ai minimi termini.

Infatti se vai a vedere lo schema di Maxwell (http://www.hwupgrade.it/articoli/skvideo/3925/geforce-gtx-750ti-e-radeon-r7-265-le-novita-di-nvidia-e-amd_2.htm), risulta lampante la presenza di un'unità scalare (e un'altra di load / store) OGNI QUATTRO core. Il rapporto, quindi, è di 4 a 1.

Un core Xeon Phi (http://www.extremetech.com/extreme/133541-intels-64-core-champion-in-depth-on-xeon-phi) ha, invece, un'unità scalare ogni unità vettoriale. Quest'ultima, però, è in grado di eseguire 16 operazioni FMAC a 32-bit (e 8 a 64-bit) alla volta, dunque è rozzamente equivalente a 16 core delle GPU. Il rapporto, quindi, è di 16 a 1: ben più efficiente rispetto a Maxwell.
L'uso del core Silvermont serve solo per cercare di diminuire in qualche modo il consumo di energia "parassita" al quella necessaria per il calcolo.
Cioé? Potresti chiarire questa parte, cortesemente?
Certo che ci deve comunicare, ma un conto è farlo attraverso un bus di comuncazione strozzato in banda e con la necessità di ricopiare nella memoria della GPU quello che serve, un conto è farlo attraverso un bus interno, con la memoria condivisa.
Su questo ho già chiarito sopra: KL non ha alcun bus interno fra unità scalare e vettoriale né un bus per accedere alla memoria condivisa. Non serve alcun protocollo di comunicazione addizionale per gestire entrambe le cose, perché sono un tutt'uno.
La differenza tra l'architettura Intel e quella delle GPU è tutta qui: da un parte hai un sistema formato da una coppia CPU+SIMD che comunica uno a uno che richiede che ogni istruzione sia decodificata su tutte le copie presenti,
Potresti chiarire anche questa parte?
dall'altra hai un sistema formato da poche CPU e molte unità di calcolo (SIMD, MIMD, pippo, caio e folletti vari non ha importanza) che decodificano una sola volta l'istruzione che poi viene sparata in parallelo su tutte le unità di calcolo.
Non è così. Anche gli SMM decodificano istruzioni diverse che poi danno in pasto ai core che contengono.

A parte questo, ogni unità vettoriale contenuta in un core Xeon Phi ha bisogno di decodificare UNA sola istruzione SIMD, la cui operazione verrà poi ripetuta per tutti e 16 i dati (a 32 bit) da elaborare. Niente decoder complicati per ogni operazione da eseguire, quindi, con un netto risparmio in termini di silicio e calore. D'altra parte Intel ha introdotto un'unità SIMD così ampia (512 bit per ogni registro vettoriale) proprio per questo motivo...
Mentre nel primo caso per aumentare il numero delle unità di calcolo devi anche portarti dietro la sua relativa CPU che non fa molto se non "dipacciare" i comandi di calcolo (un passa carte) ad una unità molto grande e complessa, con le seconde architetture ti puoi permettere di mantenere lo stesso numero di CPU che "dispacciano" la stessa identica istruzione su un numero di unità di calcolo piccole e semplici sempre maggiore.
L'aumento di prestazioni per l'aumento di unità di calcolo sulla stessa area è in quest'ultimo caso molto ma molto maggiore.
A parte che la CPU è una, mentre ciò che dici si riferisce ai core, ho già precisato sopra un po' di cose.

Aggiungo che un core non deve eseguire alcun dispatching, se non delle istruzioni da instradare all'unità scalare o a quella vettoriale: esattamente ciò che fa la GPU all'interno di un'unità SMM, che decodifica le istruzioni da eseguire (perché anche le SMM eseguono liste di istruzioni) e poi smista alle varie unità di calcolo.
Ma mentre una GPU ha bisogno una CPU esterna che la coordini, KL fa tutto da sola perché è lei stessa la CPU.
Che sono una frazione della dimensione di un core x86+relativa unità di calcolo SIMD. Il fattore scaling avvantaggia l'architettura delle GPU.
Forse non hai visto com'è fatta una GPU. Dai un'occhiata al link di sopra, e noterai che la GPU integra un GigaThread Engine e un Raster Engine per ogni Cluster. Ogni SMM integra un Polymorph Engine, 4 Warp scheduler, e 8 Texture unit.

Molta di quella roba NON viene utilizzata nei calcoli GPGPU, oppure è sovradimensionata per quello che serve.

Come enormemente sovradimensionati sono 4 register file contenuti in ogni SMM: 65536 registri distribuiti su 32 * (4 + 1) = 160 core fa un rapporto di 410 registri (a 32-bit) per ogni singolo core.

Per contro, un core Xeon Phi possiede un'unità scalare e una vettoriale che processa 16 valori a 32-bit. Abbiamo 16 registri GP (a 64-bit; ma sono registri "unici") + 8 registri di maschera (a 16-bit; ma anche questi sono registri "unici") + 6 segmenti (a 16 bit; la vecchia x64 tax) + 32 registri da 512 bit (16 valori a 32-bit). Tirando le somme, abbiamo 16 + 8 + 6 + 32 * 16 = 542 registri distribuiti su 17 "core" (1 + 16) che fa un rapporto di 32 registri per singolo core.

Ecco, adesso con qualche numero concreto in mano magari abbiamo un quadro più chiaro di quale "tasse" devono pagare le rispettive architetture, e non mi pare che Xeon Phi sia messo tanto male; tutt'altro.
As before, se devo calcolare la moltiplicazione di due matrici 10000x10000 dell'enorme efficienza delle istruzione x86 non me ne può fregare di meno. Serve che siano le unità vettoriali a lavorare alla massima efficienza. L'energia usata dal modulo di decodifica x86 per ogni istruzione che arriva alla coppia x86+SIMD non serve a nulla in termini di potenza di calcolo. E' tutta energia che va persa. E va persa ad ogni istruzione su ogni coppia CPU+SIMD. Nelle GPU una sola decodifica, decine o centinaia di unità d'esecuzione. Efficienza massima.
E con questo abbiamo capito che non sai proprio nulla di come funzioni l'architettura x86 (e meno che meno quella di Xeon Phi), oltre che di come dal codice di un algoritmo si passi poi alla generazione delle istruzioni che eseguono effettivamente il calcolo.

Qui pagina 21 c'è un frammento di codice assembly di Larrabee (https://software.intel.com/sites/default/files/m/d/4/1/d/8/GDC09_Abrash_Larrabee_final.pdf) (il progetto da cui è nato Xeon Phi).

Cortesemente, mi faresti vedere quali di quelle istruzioni NON fanno uso della "x86-tax"? Così, giusto per capire quanta energia venga persa "inutilmente". Grazie.

Se non ti piace quell'esempio puoi prenderne un altro. Lo si compila, si analizzano le istruzioni generate, e mi farai vedere perché e dov'è che ci sarebbe tutta quest'energia sprecata nella famigerata x86-tax. Io non ho problemi a metterci le mani, visto che ci lavoro spesso con Xeon Phi.
Perché progettare questo tipo di "mostri" (sia in termini di HW e di SW) non costa 4 lire e chi se lo può permettere non sono molti oltre che non sono molti quelli che troverebbero spazio nel mercato?
Se fosse una questione di soldi, multinazionali del calibro di IBM e Sun/Oracle avrebbero potuto tranquillamente farlo.

Ma non è una questione, e infatti anche aziende di gran lunga più piccole hanno realizzato architetture innovative e che gestiscono il parallelismo meglio di core PowerPC, SPARC, e altre architetture più rinomate.

Il punto è che questo tipo di unità SIMD NON si sposa con le architetture RISC già esistenti.
Persino IBM ha avuto problemi a sviluppare il Cell che per potenza ed efficienza ha dimostrato di non essere secondo a nessuno. Anzi.
Infatti era così potente che Sony ha deciso di rimpiazzarlo con una CPU x86 nella PS4. :asd:

Cell si portava PARECCHIE pecche. Infatti i programmatori hanno impiegato ANNI per cercare di sfruttarlo al meglio, tra l'altro cercando di scaricare su Cell parte dei calcoli visto che la GPU che aveva in dotazione non era il massimo quanto a prestazioni e funzionalità.
Sarà nvidia a portare ARM nel mondo server HPC. Sia con la soluzione ARM custom + GPU sia con la soluzione legata all'architettura Power di IBM.
In entrambi i casi abbiamo core eterogenei (ARM/PowerPC e Maxwell) che devono comunicare fra di loro. Cosa che con KL NON è necessaria, come già detto diverse volte.
Saranno incoraggianti per Intel il ritardo di 9 mesi e i 6 miliardi di dollari extra sul costo dei 14nm. Che non sa cosa produrci, visto che ogni anno produce sempre meno processori. Guarda caso, tanto non è importante il suo processo produttivo per colmare il gap con l'architettura ARM che non si azzarda nemmeno a proporre di usare la sua inutile nuova fabbrica 14nm per la produzione di SoC ARM. Avrebbe la fila fuori dalla porta per usarla. Ovviamente dall'altra parte il calo di vendita della sua inefficiente architettura avrebbe un'accelerazione stratosferica.
Intel non ha interesse a favorire la concorrenza, per cui è ovvio che si comporti così. Poi i PC hanno smesso di scendere, e ci sono segnali di ripresa. Tra l'altro Intel non è ferma soltanto ai PC, e infatti l'ultimo quarto ha visto un'impennata del settore business che ha sollevato non poco il bilancio rispetto alle stime.

Quanto al processo a 14nm, arriverà a breve. Nel frattempo ha il 22nm FinFET, mentre gli altri il classico 28nm, e non sanno quando la situazione cambierà.
Con l'architettura KL ogni impatto ce l'hai nella coppia CPU+SIMD. Non è che questi parlino "gratis per volere del Signore".
A parte il fatto che continui a confondere il concetto di CPU con quello di core, l'unità scalare e quella vettoriale fanno parte dello stesso core, per cui "si parlano" ovviamente, ma in maniera di gran lunga più efficiente rispetto a quanto farebbe un core ARM con un core CUDA. Lo fanno, per essere chiari, nella stessa misura in cui un core CUDA "parla" col core SFU che si trova nello stesso modulo SMM (vedi lo schema di Maxwell di cui ho passato il link).

Ti è chiara una buona volta la differenza fra le due cose? Io non posso fare più niente, perché non so in quale altro modo dirtelo...
Bla bla bla, parlando di come qualcun altro potrebbe fare la stesa cosa di Intel vieni a parlarmi di quanto sia bella l'architettura dell'unità vettoriale?
Ma non lo dico mica io. Puoi chiedere anche a Tim Sweeney cosa ne pensa. Sempre se conosci il personaggio in questione.
Perché gli altri non potrebbero farla?
Forse perché hanno architetture RISC?
E' esclusiva Intel?
AVX-512 sì. Ma potrebbero realizzare altre unità SIMD con concetti simili. SE fossero integrabili con la loro architettura RISC.
La potenza di Intel è nell'aver abbinato un'unità di calcolo vettoriale con una che esegue il codice x86?
Anche, ma non solo: è l'ecosistema che rende meglio, potendo l'unità vettoriale contare sulle caratteristiche CISC che x86 si porta dietro, e che sono state sfruttate quando è stata progettata.
Che cambia se invece che una CPU x86 ci metto una con istruzione ARM/MIPS/Power/Spark o zio peppino? Chi compie effettivamente il calcolo?
L'ecosistema, come già detto. Non puoi dividere l'unità SIMD dal resto, perché non è un'unità totalmente indipendente, che puoi trapiantare dove vuoi.

Hai visto il codice d'esempio di cui ho postato il link prima? E' lampante come le istruzioni vettoriali siano intimamente legate alla natura x86 del core in cui vengono eseguite. Lampante per chi, ovviamente, conosce sia x86 sia AVX-512 (basta LBi, in realtà, che è il predecessore).

Ma puoi sempre dirmi come faresti a realizzare qualcosa di simile con le altre architetture. Il codice d'esempio ce l'hai: mostrami pure quello che sai fare e che altri ingegneri più titolati non ne sono stati in grado.
Non hai capito la differenza che c'è tra l'architettura messa in piedi da Intel e quella messa in piedi dai GPUari. O meglio, fai tanta confusione perché non la si capisca.
Davvero? Lasciamo che siano gli altri utenti a giudicare come stiano le cose.

Io i miei dati e FATTI li ho riportati, e non mi sono fermato a delle vuote parole.
Con l'architettura delle GPU non serve che vi sia un forte legame tra la parte scalare e quella vettoriale della CPU, ma sono due cluster separati che comunicano per sincronizzarsi.
Infatti sono talmente separati che l'unità scalare di Maxwell (e predecessori), l'SFU, si trova appiccicata a 4 CUDA core... :asd:

Già, il legame è così debole che Maxwell si porta dietro 1 SFU ogni 4 CUDA core, mentre Xeon Phi 1 ogni 16 "core", come mostrano i rispettivi schemi. Per chi li ha esaminati, ovviamente.
Senza un bus ad-hoc ma su PCI c'è un forte overhead per la comunicazione. Se hai un bus ad-hoc con condivisione delle risorse ottieni un sistema super scalabile ed efficiente dove bilanci il carico di lavoro tra scalare e vettoriale come vuoi a seconda di quante unità monti di qui o di là.
Tante parole talmente generiche che vogliono dire tutto e niente.

Gli schemi di Maxwell e di Xeon Phi te li ho forniti, e mi pare che la situazione sia BEN DIVERSA da quella che stai fantasiosamente cercando di stravolgere.

Anche quando ci sarà un core ARM o PowerPC collegati ai core (cluster, immagino) tramite un bus speciale, la situazione sarà certamente migliore rispetto all'attuale che fa uso del PCI-Express, ma in ogni caso NON paragonabile a quella che metterà a disposizione KL.

Continuare a ripetere discorsi irreali e inutili non cambierà di una virgola questa situazione. Che ti piaccia o meno.

Tra l'altro sei talmente arrogante e presuntuoso quanto ignorante. Hai dimostrato di sconoscere x86 e Xeon Phi, ma persino come funziona una GPU. Ed è evidente che i link che ho postato non li hai nemmeno calcolati, visto che non sei in grado di comprenderne il contenuto. Infatti se non hai la minima idea di come funzioni un core Xeon Phi, figuriamoci se riesci a capire in che modo sono strutturati gli opcode dell'unità vettoriale, di cui t'avevo fornito link abbastanza potabili, dai quali traspare l'evidentissimo e profondissimo legame dell'unità SIMD con x86.

Come per la questione Amiga vs PC, continui a parlare di cose che sconosci del tutto, e i risultati si vedono.

Datti una calmata e mettiti a studiare. Io con queste cose ci lavoro quasi tutti i giorni, e mi occupo di architetture degli elaboratori da più di 30 anni. Non mi faccio mettere sotto dal pinco pallino di turno che fonda la sua conoscenza sulla raccolta, a destra e a manca, di informazioni sulla rete, per spacciarsi poi come esperto...

Un consiglio, visto il tuo interlocutore lascia stare fin d'ora e non perder tempo.
Troppo tardi, ormai avevo cominciato a scrivere, ma in ogni caso gente così va messa con le spalle al muro per impedirle di continuare a seminare falsità, generando e alimentando le solite leggende metropolitane.

Adesso sono curioso di leggere le sue risposte alle precise questioni che ho posto. SE arriveranno, perché arrivati a questo punto si dileguano, o passano sul piano personale, o tagliano le risposte, o cambiando discorso. E soprattutto fanno la parte delle vittime che sono state trucidate dall'orco brutto e cattivo.
Insomma tutto fuorché rispondere tecnicamente e con fatti alla mano a questioni prettamente tecniche.

Brutta cosa il fanatismo...

Troppo tardi, ormai avevo cominciato a scrivere, ma in ogni caso gente così va messa con le spalle al muro per impedirle di continuare a seminare falsità, generando e alimentando le solite leggende metropolitane.

Adesso sono curioso di leggere le sue risposte alle precise questioni che ho posto. SE arriveranno, perché arrivati a questo punto si dileguano, o passano sul piano personale, o tagliano le risposte, o cambiando discorso. E soprattutto fanno la parte delle vittime che sono state trucidate dall'orco brutto e cattivo.
Insomma tutto fuorché rispondere tecnicamente e con fatti alla mano a questioni prettamente tecniche.

Brutta cosa il fanatismo...
A differenza vostra io lavoro e ho una vita sociale vera, per cui scrivere e leggere queste pappardelle mi costa tanta fatica e sopratutto tanto preziosissimo tempo sottratto ad altre cose più importanti.
Il fanatismo ce l'ha chi vuole difendere qualcosa di prezioso (per sé stesso). Io non ho nulla da difendere di mio nel fare un confronto tra uno scenario e un altro. Al massimo quello che ha voglia a tutti i costi di dimostrare che a la soluzione migliore sei tu che ci devi campare (e devi far fare bella figura all'azienda per cui lavori).
Diciamo pure che io non ho sponsor. E se le mie imprecisioni sono "da povero fanatico ignorante" le tue possono essere considerate "da bugiardo che mente sapendo di mentire". Non so chi dei due è meglio.

Trovo comunque la discussione abbastanza sterile. Da dipendente Intel ti senti subito attaccato e in dovere di difendere la casa madre (quella che ti paga lo stipendio) per ogni cosa.

Io ho messo in evidenza la differenza che c'è tra l'architettura di una GPU e quella di KL. Il fatto che tu sia così profondamente convinto che KL sia la soluzione finale globale definitiva e non plus ultra a quello che è il problema del calcolo parallelo mi sembra abbastanza palese. Che sia una convinzione che va ben oltre ai meriti propri dell'architettura anche, visto che fai parte dell'azienda che l'ha creata r di cui devi difendere il nome da attacchi "di fanatici rozzi e ignoranti".

Però come da buona scuola Intel (vi passano i manuali con le indicazioni su come tenere i confronti con i prodotti concorrenti?) il paragone lo fai sempre tra quello che Intel proporrà tra 6 mesi/un anno e quello che la concorrenza ha sul mercato già da qualche tempo (parecchio considerando che di elettronica che si parla).
E' successo più volte con le fantasmagoriche architetture mobile di Intel, le cui slide promettevano cose mai viste, inennarrabili ai comuni (ignoranti) mortali che storcevano il naso, per poi essere ovviamente smentite al momento della comparsa del prodotto sul mercato, quando invece che confrontarsi con la soluzione vecchia dove comunque faticava a prevalere, contro quella nuova non ha mai offerto nulla di meglio. Anzi.
E succede ance qui, dove ti ostini a confrontare KL in arrivo se va bene tra un anno e l'architettura Kepler che è vecchia di 2. Architettura che KC, il precursore di KL, non ha battuto in alcun modo ripeto, pur avvantaggiandosi di un processo produttivo decisamente migliore di quello su cui si basa l'architettura nvidia.
L'architettura Maxwell, non solo internamente come capacità computazionale, ma anche come sistema di comunicazione verso la CPU (quella che io forse prima ho definito la parte "scalare") è completamente diversa.

Ora, parlare è bello e fantastico perché la libertà di parola dà tanto potere e permette di creare molte fantasie. Però alla mia veneranda età fare 2+2 sono ancora capace.
Kepler, basato su un sistema super inefficiente come quello in adozione oggi che ha da una parte del bus la CPU e la memoria di sistema e dall'altra la GPU e la memoria chiamiamola "di calcolo" o locale, tiene a bada KC. Nell'efficienza Flops/W senza alcun dubbio. Efficienza che non la stabilisci tu con il test che vuoi (come solitamente piace fare a d Intel) ma da un ente che crea i bench standard che determinano i numeri di capacità elaborativa. Magari sono numeri senza senso, astratti, svincolati dall'uso vero dell'attrezzo, però essendo fatti da un consorzio credo che qualche verità la mostrino. I numeri mostrano che Kepler a parità di energia fa più conti di KC. Tutto compreso, dall'energia "parassita" delle CPU a quello dei bus di comunicazione stretti e dei tempi stratosfericamente geologici di trasferimento dei dati dalla memoria di sistema a quella locale della (o delle) unità di calcolo vettoriale vera e propria.

Ora arriva KL che è una evoluzione di KC. Più potenza vettoriale, "core interi" (così magari ci capiamo meglio) migliorati, supper bus, suppper memoria etc.. che sono tutte belle cose.
Ma arriva anche Maxwell che dovrebbe (dico dovrebbe perché la teoria su carta è una cosa, la pratica un'altra) rimuovere il vincolo del bus stretto di comunicazione tra la CPU e la GPU così come con KL.
Il risultato è che tutta la potenza di calcolo che prima era strozzata ora è libera di fare più o meno quello che si preannuncia poter fare KL.

Quale miracolo, rispetto alla concorrenza, dovremmo aspettarci? Che andrà meglio del predecessore nessuno lo mette in dubbio. Che vada meglio delle soluzioni che altri hanno trovato per aggirare i cancelli chiusi di Intel è un'altra. Affianchiamoci la questione, che non so se hai visto, che l'architettura Power di IBM già sprigiona una quantità di potenza di calcolo a una frazione dell'energia delle soluzioni Intel (e quindi forse questo non induce IBM a fare alcun tipo di acceleratrice esterna alla sua CPU usando tecnologia di altri), con l'affiancamento di una ulteriore architettura super efficiente con la quale può dialogare liberamente si ha un aumento spaventoso della capacità di calcolo per W a disposizione.

Nei sistemi più piccoli, nvidia può proporre la sua architettura ARM+GPU interna allo stesso die (project Denver), anche qui potendo far in modo che entrambi "i cluster" eterogenei siano in grado di parlarsi senza strozzature e di condividere i dati senza continui copia e incolla. Se funzionava così bene prima quando erano separati da un bus lumaca, come potrebbero andare peggio ora?
Saranno meglio di KL? Saranno peggio? Mah, vedremo, dico solo che KL non è questo miracolo della fantascienza che Intel sbandiera. KF/KC/KL come le tre generazioni di Atom precedenti che dovevano aprire il cu*o al resto del mondo mobile? Boh, non so. So che comunque rimane questo vizio aziendale abbastanza radicato di paragonare il prodotto nuovo in arrivo in 6/12 mesi con uno che è già sul mercato da 12/18 mesi. In questo caso si arriva al paragone con uno sul mercato da 27 mesi. E si fa finta che gli altri non abbiano fatto niente nel frattempo.

Le filosofie tra un'architettura come quella Intel (che ripeto solo Intel può permettersi per altri motivi che non sono quelli di usare un set di istruzioni CISC, dato che anche ARM ha un set di istruzione estensibile proprio per i coprocessori) e quelle di una GPU sono radicalmente diverse. Entrambe hanno punti a favore e a sfavore. Far finta che la concorrenza non abbia eliminato buona parte dei punti che fino a ieri li sfavoriva è quello che falsa tutto il discorso.
Venir qui e dipingere un immagine tutta rosa e fiori per un'architettura che sopravvive oggi sopratutto perché colma la propria inefficienza grazie ad un processo produttivo migliore è altrettanto "seminare falsità".
Negare che tra non molto il processo produttivo di Intel e il resto del mondo sarà così vicino che Intel dovrà fare qualcosa di più è "negare l'evidenza". Dire "i 14nm tra un po' saranno realtà" (dovevano esserlo 9 mesi fa a 6 o più miliardi di dollari di costo in meno e con una fabbrica in più in funzione) mentre la concorrenza non c'è è un po' prendersi in giro.
Lo è anche fingere che KL a 14nm non si scontrerà con Maxwell a 16nm (entrambi FinFet questa volta).

2+2 per me significa che quando una architettura estremamente inefficiente come CPU e GPU separate da un bus strettissimo dove quest'ultima è costruita con un PP decisamente peggiore ha tenuto testa (e anzi è meglio) di una che è costruita con un PP migliore e che risente molto meno (o può addirittura annullare) il problema del bus stretto, non può fare peggio quando le si toglie il principale collo di bottiglia, fa prevedere che c'è un 3 o 4x di capacità computazionale a parità di unità di calcolo (vedere come si comporta il GM107 in GPGPU che non contiene i core ARM) e sarà basato su un nuovo PP che permette almeno il raddoppio delle unità di calcolo nello stessa area (vedesi il discorso precedente, raddoppiare le unità di calcolo di una GPU non significa portarsi dietro una unità "integer" x86 con tutto quello che ne deriva in termini di spazio e energia consumata).

Se vuoi continuare a polemizzare su cosa sia un core o una CPU, sul numero di registri per unità di calcolo, che il sistema CISC può permettersi di interfacciarsi meglio con unità esterne, fai pure. Non era quello in mio intento. Ed è inutile sciovinare una serie di conoscenze su argomenti che poi molto probabilmente (come la storia insegna ma che poi ci si dimentica) non danno il risultato sperato. Mi pare che hai argomentato a lungo anche sulle capacità incredibili delle ultime generazioni di Atom. Infatti ne vedo ben i progressi rispetto a quelli ARM. Ah, be' sì scusa, tu paragonavi l'ultimo Atom con le capacità dell'A9. Sì, certo, è decisamente migliore. Non c'è dubbio.
Ah, per finire, tanto è un problema estendere le capacità di interazione tra un set di istruzioni RISC e un coprocessore che la CPU PowerPC del Cell (RISC) ne governava 8 di unità esterne. A una frazione dell'energia di un x86. Con oltre il triplo di efficienza energetica a parità di capacità computazionale (vedere cosa consumava il RoadRunner di IBM a 1 PetaFlop e il primo server only x86 based che è riuscito a superare tale soglia).

Ho esaurito il mio tempo a disposizione per oggi.
Se vuoi puoi continuare liberamente a fare propaganda aziendale. Almeno tu qualcosa da dire ce l'hai anche se altamente opinabile. Però cerca tu di moderare i termini. o, come detto sono un povero "fanatico ignorante". Tu un dipendente di una azienda. Sia tu che la tua azienda avete già dimostrato più volte che i bellissimi e argomentatissimi bla bla sono risultati in fail clamorosi. Sii almeno consapevole di questo quando fai affermazioni assolutistiche sulle capacità divinatorie della azienda tua padrona.

A differenza vostra io lavoro e ho una vita sociale vera, per cui scrivere e leggere queste pappardelle mi costa tanta fatica e sopratutto tanto preziosissimo tempo sottratto ad altre cose più importanti.
Ciò non ti ha impedito di scrivere nuovamente un bel papiro: evidentemente anche questa discussione è importante per te.
Il fanatismo ce l'ha chi vuole difendere qualcosa di prezioso (per sé stesso).
Omettendo di analizzare TUTTI i fatti. Questa parte mancava.
Io non ho nulla da difendere di mio nel fare un confronto tra uno scenario e un altro.
Se avessi voluto un confronto serio avresti tenuto conto di TUTTE le variabili in gioco, anziché esaltarne soltanto una parte, eliminare quelle scomode, e puntare il dito contro i difetti del nemico costituito, ingigantendoli. Ma ne parlo meglio dopo.
Al massimo quello che ha voglia a tutti i costi di dimostrare che a la soluzione migliore sei tu che ci devi campare (e devi far fare bella figura all'azienda per cui lavori).
E adesso comincia il valzer delle falsità, mistificazioni, e fallacie logiche con annesso attacco personale.

Cominciamo a smontare le menzogne.
Da qui (http://www.hwupgrade.it/forum/showpost.php?p=41242920&postcount=12): "Il risultato di Xeon Phi è decisamente scadente."
Da qui (http://www.hwupgrade.it/forum/showpost.php?p=41246486&postcount=25): "Le prestazioni sono deludenti, come già detto prima [...]
Indubbiamente la sezione di decodifica di un core x86 è ben più complessa di quella di un RISC, e richiede sia transistor sia consumi più elevati. [...]
Certo, non è un'architettura che va bene per tutto."
Da qui (http://www.hwupgrade.it/forum/showpost.php?p=41250556&postcount=33): "E' normale che una particolare architettura sia più portata per certi tipi di calcoli piuttosto che per altri. [...]
Il problema, però, è che ci sono dei costi da pagare: quello del page fault (che fa andare la CPU in kernel space; e poi deve ovviamente ritornare) e quello della lettura dei dati dalla memoria principale tramite PCI-Express.

Per questo motivo MYO è sconsigliabile nei casi in cui si accede in maniera troppo poco sequenziale / locale alla memoria"
Da qui (http://www.hwupgrade.it/forum/showpost.php?p=41254382&postcount=35): "Se il fardello a cui ti riferisci è la cosiddetta "x86 tax", questo vale sostanzialmente per la sezione di decodifica, che è più complessa, per cui richiede più transistor e consuma di più"

Come vedi non ho avuto e non ho alcuna difficoltà ad ammettere le problematiche dei prodotti della mia azienda. Perché non sono un bambino che deve nascondere i propri difetti. Pur facendo parte di Intel, rimango comunque un professionista.

Ciò precisato, l'aver tirato in ballo la mia azienda in questo modo dimostra l'uso, da parte tua, di una ben nota fallacia logica: Ad hominem circostanziale (http://www.linux.it/~della/fallacies/ad-hominem-circostanziale.html). Tipico di chi non è in grado di sostenere una discussione rimanendo sul piano dei fatti e delle argomentazioni.
Diciamo pure che io non ho sponsor.
Non pagato, ma è come se ce l'avessi: sistematicamente dai addosso ad AMD ed esalti nVidia quando si parla di GPU, e fai lo stesso con Intel quando si parla di HPC, e idem quando si confrontano processori in ambito mobile (esaltando ARM, ovviamente, soprattutto perché nVidia ha tirato fuori prodotti su di essa basati).

Sei decisamente prevedibile...
E se le mie imprecisioni sono "da povero fanatico ignorante"
Beh, hai fatto tutto tu: hai parlato di CPU e SIMD senza avere la minima idea di come funzionano (e non si tratta di lapsus, ma di errori sistematici, visto quante volte hai parlato di CPU+SIMD, oltre a scambiare anche CPU e core), non conosci nemmeno come funzionano le GPU della tua marca del cuore (fenomenale la presunta separazione di unità scalare e vettoriale, addirittura su due cluster diversi, quando in realtà sono incollate una all'altra), e dulcis in fundo pretendi di spiegare a me come funzionano i processori x86 e Xeon Phi che li studio da e anni e adesso ci lavoro pure.

Tu come lo chiameresti uno che le spara così grosse?
le tue possono essere considerate "da bugiardo che mente sapendo di mentire".
Puoi sempre dimostrarlo: i miei commenti sono lì, e aspettano te per essere smontati...
Non so chi dei due è meglio.
Lascia che a decidere siano gli altri utenti. I FATTI sono lì a disposizione per farsi un'idea e giudicare.

Intanto il "bugiardo che mente sapendo i mentire" ha appena dimostrato sopra, con tanto di link e quote, le tue menzogne sul mio conto.
Trovo comunque la discussione abbastanza sterile.
Allora non partecipare: non te lo prescrive il medico di stare qui quando hai pure cose più importanti da fare.
Da dipendente Intel ti senti subito attaccato e in dovere di difendere la casa madre (quella che ti paga lo stipendio) per ogni cosa.
Altro attacco ad homimen. Come da manuale.

Se hai qualcosa da dire su quello che ho scritto puoi benissimo quotarmi e sbugiardarmi. Non sono forse un "bugiardo che mente sapendo di mentire"? Dovresti avere vita facile a dimostrarlo, no? Accomodati pure...
Io ho messo in evidenza la differenza che c'è tra l'architettura di una GPU e quella di KL.
Peccato che non abbia capito nulla né di KL né delle GPU (in particolare di casa nVidia). L'unica cosa che hai messo in evidenza è proprio questa...
Il fatto che tu sia così profondamente convinto che KL sia la soluzione finale globale definitiva e non plus ultra a quello che è il problema del calcolo parallelo mi sembra abbastanza palese.
Mi sembra palese, dai link e dai quote che ho riportato sopra, che non sia così.

Poi è chiaro che sono convinto che KL porterà tante interessanti novità, ma da qui a definirla come l'unica soluzione per il mercato HPC farei il passo più lungo della gamba. E, infatti, non l'ho fatto e non lo faccio.
Che sia una convinzione che va ben oltre ai meriti propri dell'architettura anche, visto che fai parte dell'azienda che l'ha creata r di cui devi difendere il nome da attacchi "di fanatici rozzi e ignoranti".
Altro attacco Ad hominem circostanziale. Chi l'avrebbe mai detto.

Io ho riportato dei FATTI e delle ARGOMENTAZIONI, che tali rimangono a prescindere che io sia un dipendente Intel oppure no. Che ti piacciano, oppure no. E se non ti piacciono, puoi sempre provare a smontarli, magari riportando altri fatti e argomentazioni anziché scadere in una banale fallacia logica...
Però come da buona scuola Intel (vi passano i manuali con le indicazioni su come tenere i confronti con i prodotti concorrenti?)
Altro attacco ad hominem circostanziale...
il paragone lo fai sempre tra quello che Intel proporrà tra 6 mesi/un anno e quello che la concorrenza ha sul mercato già da qualche tempo (parecchio considerando che di elettronica che si parla).
E un'altra falsità. Si vede che sei particolarmente in vena, non avendo altro a tua disposizione.

Ma ne parlo meglio dopo.
E' successo più volte con le fantasmagoriche architetture mobile di Intel, le cui slide promettevano cose mai viste, inennarrabili ai comuni (ignoranti) mortali che storcevano il naso, per poi essere ovviamente smentite al momento della comparsa del prodotto sul mercato, quando invece che confrontarsi con la soluzione vecchia dove comunque faticava a prevalere, contro quella nuova non ha mai offerto nulla di meglio. Anzi.
Mi sembra che le prove su strada dimostrino tutt'altra cosa. Comunque puoi sempre riportare le slide e le prove su strada che le smentiscono. Visto che questa "tesi" l'hai tirata fuori tu, l'onere della prova rimane sempre a tuo carico, come da metodologia scientifica.
E succede ance qui, dove ti ostini a confrontare KL in arrivo se va bene tra un anno e l'architettura Kepler che è vecchia di 2.
Altra menzogna, come dicevo sopra. KL l'ho messo a confronto con Maxwell, e Kepler non l'ho mai confrontato con KL.

Ecco qui (http://www.hwupgrade.it/forum/showpost.php?p=41254382&postcount=35) l'unico mio commento in cui appare Kepler, in risposta a uno tuo in cui l'avevi tirato in ballo.

La prima replica è generica: ""Meglio" in cosa? Le architetture sono diverse, e alla fine conta quello che riescono a fare, quanto costano, quanto dissipano, e pure quanto costa realizzare o portarci del software (aspetto, questo, tutt'altro che trascurabile, anche se spesso non viene considerato)."

La seconda NON si riferisce a Kepler, ma a Maxwell. Infatti:
TU -> "Visto che Kepler già è meglio in GFlops/W, direi che Intel deve fare davvero ben per riuscire a competere con Maxwell che per il poco che abbiamo visto con il minuscolo GM107 promette di essere fino a 3/4x più veloce nel calcolo GPGPU con lo stesso consumo di energia con lo stesso PP."
IO -> "Anche KL avrà una (micro-)architettura di gran lunga migliore rispetto a KC, essendo basata sul core Silvermont (che trovi in BayTrail)."
Direi che è chiarissimo: TU hai tirato in ballo Maxwell, e io ho citato KL in proposito.

Questo confronto fra Kepler e KL non si sa dov'è che tu l'abbia visto, ma non mi sorprende affatto: fa parte delle mistificazioni che stai costruendo per cercare di disperatamente di portare un po' di acqua al tuo mulino... a secco.
Architettura che KC, il precursore di KL, non ha battuto in alcun modo ripeto, pur avvantaggiandosi di un processo produttivo decisamente migliore di quello su cui si basa l'architettura nvidia.
Su questo ti risposi tempo fa in un altro thread, con tanto di link. Ovviamente sei sparito e non hai mai più replicato, salvo tornare alla carica adesso con lo stesso argomento. Segno di grande onestà intellettuale...
L'architettura Maxwell, non solo internamente come capacità computazionale, ma anche come sistema di comunicazione verso la CPU (quella che io forse prima ho definito la parte "scalare") è completamente diversa.
Forse? Non hai nemmeno idea se la balla che hai riportato sia questa?

Comunque di com'è fatto Maxwell t'avevo riportato un link. Ma ne parlo meglio dopo.
Ora, parlare è bello e fantastico perché la libertà di parola dà tanto potere e permette di creare molte fantasie. Però alla mia veneranda età fare 2+2 sono ancora capace.
Diciamo che finora, sarà magari complice proprio la veneranda età, più che fare 2 + 2 ti sei dato molto da fare con la fantasia...
Kepler, basato su un sistema super inefficiente come quello in adozione oggi che ha da una parte del bus la CPU e la memoria di sistema e dall'altra la GPU e la memoria chiamiamola "di calcolo" o locale, tiene a bada KC. Nell'efficienza Flops/W senza alcun dubbio. Efficienza che non la stabilisci tu con il test che vuoi (come solitamente piace fare a d Intel) ma da un ente che crea i bench standard che determinano i numeri di capacità elaborativa. Magari sono numeri senza senso, astratti, svincolati dall'uso vero dell'attrezzo, però essendo fatti da un consorzio credo che qualche verità la mostrino. I numeri mostrano che Kepler a parità di energia fa più conti di KC.
Allora non avrai difficoltà a riportarli nel thread di cui sopra, in modo da confrontarli coi numeri che ho già riportato.
Tutto compreso, dall'energia "parassita" delle CPU
Scusami se è la seconda volta che te lo chiedo, ma potresti darmi la definizione di "energia parassita" di una CPU? Così almeno capiamo di cosa stai parlando.
a quello dei bus di comunicazione stretti e dei tempi stratosfericamente geologici di trasferimento dei dati dalla memoria di sistema a quella locale della (o delle) unità di calcolo vettoriale vera e propria.
Questi problemi sono comuni a KC, Kepler, e in generale a qualunque scheda che si trova collegata alla CPU tramite PCI-Express.
Ora arriva KL che è una evoluzione di KC. Più potenza vettoriale, "core interi" (così magari ci capiamo meglio) migliorati, supper bus, suppper memoria etc.. che sono tutte belle cose.
E' meglio parlare di unità scalare / intera / general purpose. I core sono un'altra cosa.

Comunque è l'architettura globalmente a essere migliorata, visto che KL erogherà anche il triplo dei FLOPS rispetto a KC, e questa potenza di calcolo è sviluppata dall'unità vettoriale, non da quella scalare.
Ma arriva anche Maxwell che dovrebbe (dico dovrebbe perché la teoria su carta è una cosa, la pratica un'altra) rimuovere il vincolo del bus stretto di comunicazione tra la CPU e la GPU così come con KL.
Il risultato è che tutta la potenza di calcolo che prima era strozzata ora è libera di fare più o meno quello che si preannuncia poter fare KL.
Nell'altro commento ho cercato di spiegarti in tutte le salse che NON è così. Anche se continui a non capire, io ho esaurito tutti gli esempi che ti potevo portare, per cui rinuncio a spiegarti per l'n-esima volta perché sono diversi.
Quale miracolo, rispetto alla concorrenza, dovremmo aspettarci? Che andrà meglio del predecessore nessuno lo mette in dubbio. Che vada meglio delle soluzioni che altri hanno trovato per aggirare i cancelli chiusi di Intel è un'altra.
Quali sarebbero questi cancelli? Non è chiaro il riferimento.
Affianchiamoci la questione, che non so se hai visto, che l'architettura Power di IBM già sprigiona una quantità di potenza di calcolo a una frazione dell'energia delle soluzioni Intel (e quindi forse questo non induce IBM a fare alcun tipo di acceleratrice esterna alla sua CPU usando tecnologia di altri),
Veramente è proprio quello che ha fatto con RoadRunner (http://it.wikipedia.org/wiki/IBM_Roadrunner).

PowerCell è perfettamente in grado di fungere da CPU, per cui, da quello che scrivi, IBM non avrebbe avuto bisogno di appoggiarsi a nessuno. Ma tant'è...
con l'affiancamento di una ulteriore architettura super efficiente con la quale può dialogare liberamente si ha un aumento spaventoso della capacità di calcolo per W a disposizione.
Non può dialogare "liberamente" come KL. Ma, come già detto, non te lo rispiego di nuovo: ho finito le cartucce.
Nei sistemi più piccoli, nvidia può proporre la sua architettura ARM+GPU interna allo stesso die (project Denver), anche qui potendo far in modo che entrambi "i cluster" eterogenei siano in grado di parlarsi senza strozzature e di condividere i dati senza continui copia e incolla. Se funzionava così bene prima quando erano separati da un bus lumaca, come potrebbero andare peggio ora?
Ma infatti, e come già detto anche in precedenza, non ho nulla da dire su questo: è certamente un miglioramento per nVidia.
Saranno meglio di KL? Saranno peggio? Mah, vedremo, dico solo che KL non è questo miracolo della fantascienza che Intel sbandiera. KF/KC/KL come le tre generazioni di Atom precedenti che dovevano aprire il cu*o al resto del mondo mobile? Boh, non so.
Ecco, se non sai perché scrivi?
So che comunque rimane questo vizio aziendale abbastanza radicato di paragonare il prodotto nuovo in arrivo in 6/12 mesi con uno che è già sul mercato da 12/18 mesi. In questo caso si arriva al paragone con uno sul mercato da 27 mesi. E si fa finta che gli altri non abbiano fatto niente nel frattempo.
Su questo ho già dimostrato prima che hai raccontato un'altra falsità.
Le filosofie tra un'architettura come quella Intel (che ripeto solo Intel può permettersi per altri motivi che non sono quelli di usare un set di istruzioni CISC, dato che anche ARM ha un set di istruzione estensibile proprio per i coprocessori)
Anche? No, Intel NON ha un'ISA estensibile tramite coprocessori, a parte l'unica (opcode di escape) dedicata esclusivamente all'FPU. Per cui, questa cosa dov'è che l'hai vista?

E comunque lo sai che ARM, introducendo la sua nuova ISA a 64 bit (ARMv8 aka AMR64), ha completamente rimosso il supporto ai coprocessori? Denver, "casualmente", sarà basato su ARM a 64 bit... Quanto faceva 2 + 2? :D

Adesso perché non mi spieghi come farà nVidia a far dialogare il core ARM a 64 bit coi suoi core Maxwell? Così, tanto per gradire...
e quelle di una GPU sono radicalmente diverse. Entrambe hanno punti a favore e a sfavore. Far finta che la concorrenza non abbia eliminato buona parte dei punti che fino a ieri li sfavoriva è quello che falsa tutto il discorso.
A parte il fatto che, come ho riportato sopra, qui nessuno ha negato che l'architettura x86 si porti dietro le sue pacche.

Ma a fronte di questo prezzo da pagare ci sono anche dei notevoli vantaggi, e basti vedere AVX-512 per rendersene conto...
Venir qui e dipingere un immagine tutta rosa e fiori per un'architettura che sopravvive oggi sopratutto perché colma la propria inefficienza grazie ad un processo produttivo migliore è altrettanto "seminare falsità".
Non mi sembra di aver negato che Intel tragga vantaggio del suo processo produttivo migliore. Né ho negato che x86 si porti la sua bella tassa in termini di consumi.

Ma i numeri dimostrano che, al di là delle problematiche, le prestazioni ci sono. Queste sarebbero "falsità"? E dove? Dimostralo pure...
Negare che tra non molto il processo produttivo di Intel e il resto del mondo sarà così vicino che Intel dovrà fare qualcosa di più è "negare l'evidenza".
Ecco, se magari riportassi quand'è che avrei espresso qualcosa del genere, mi faresti un favore: almeno ci sarà qualcosa di concreto di cui parlare.
Dire "i 14nm tra un po' saranno realtà" (dovevano esserlo 9 mesi fa a 6 o più miliardi di dollari di costo in meno e con una fabbrica in più in funzione) mentre la concorrenza non c'è è un po' prendersi in giro.
Ci sono le notizie a riguardo: la roadmap di Intel per i 14nm NON ha subito cambiamenti. I prodotti, dunque, arriveranno a breve.

Per contro, le ultime notizie su AMD e Nvidia riportano che per i prossimo prodotti continueranno a usare lo stesso processo produttivo attuale, causa problemi di TSMC, e che non si sa quando saranno risolti.

Questi sono FATTI, non prese in giro. Ma se hai informazioni nuove a riguardo, non hai che da postarle...
Lo è anche fingere che KL a 14nm non si scontrerà con Maxwell a 16nm (entrambi FinFet questa volta).
Di KL si sa che uscirà a 14nm, non foss'altro perché arriverà ben dopo che uscirà Broadwell.

Per Maxwell... no. Come già detto prima, hai informazioni nuove in merito? Riportale pure.
2+2 per me significa che quando una architettura estremamente inefficiente come CPU e GPU separate da un bus strettissimo dove quest'ultima è costruita con un PP decisamente peggiore ha tenuto testa (e anzi è meglio) di una che è costruita con un PP migliore e che risente molto meno (o può addirittura annullare) il problema del bus stretto,
Fammi vedere in che modo lo "annullerebbe". Riporta pure, non ti fare problemi: io sono qui che aspetto di leggere queste meraviglie tecnologiche.
non può fare peggio quando le si toglie il principale collo di bottiglia,
Lapalissiano.
fa prevedere che c'è un 3 o 4x di capacità computazionale a parità di unità di calcolo (vedere come si comporta il GM107 in GPGPU che non contiene i core ARM)
Questo 3 / 4x dov'è che l'hai letto? Riporta pure.
e sarà basato su un nuovo PP che permette almeno il raddoppio delle unità di calcolo nello stessa area
Da 28 a 16nm ci dovrebbe essere ben più di un raddoppio.
(vedesi il discorso precedente, raddoppiare le unità di calcolo di una GPU non significa portarsi dietro una unità "integer" x86 con tutto quello che ne deriva in termini di spazio e energia consumata).
No? Se raddoppiano i core, significa che raddoppiano ANCHE le unità scalari (SFU) di Maxwell, visto che ne hanno una ogni QUATTRO core (CUDA).

E significa pure aumentare il numero di Texture Unit, Polymorph engine, ecc. ecc. Ma su questo "stranamente" non hai avuto nulla da dire, avendo tagliato completamente il discorso. Chissà perché...
Se vuoi continuare a polemizzare su cosa sia un core o una CPU, sul numero di registri per unità di calcolo, che il sistema CISC può permettersi di interfacciarsi meglio con unità esterne, fai pure. Non era quello in mio intento.
Lo credo bene, visto che hai ampiamente dimostrato di non averne conoscenza.
Ed è inutile sciovinare una serie di conoscenze su argomenti che poi molto probabilmente (come la storia insegna ma che poi ci si dimentica) non danno il risultato sperato.
Almeno io conosco ciò di cui parlo. Non campo di fantasie mettendo assieme informazioni lette chissà dove e tirate fuori perché c'è una discussione tecnica.

Come sempre, bisognerebbe parlare di cose che si conoscono.
Mi pare che hai argomentato a lungo anche sulle capacità incredibili delle ultime generazioni di Atom. Infatti ne vedo ben i progressi rispetto a quelli ARM. Ah, be' sì scusa, tu paragonavi l'ultimo Atom con le capacità dell'A9. Sì, certo, è decisamente migliore. Non c'è dubbio.
Ti pare male, e non mi sorprende affatto, dopo tutte le falsità che hai riportato.

Ma puoi sempre riportami il link alla discussione, e quotare ciò che avrei scritto in merito. Io sono qui che aspetto...
Ah, per finire, tanto è un problema estendere le capacità di interazione tra un set di istruzioni RISC e un coprocessore che la CPU PowerPC del Cell (RISC) ne governava 8 di unità esterne.
Ma chi ha parlato di coprocessore riguardo a Xeon Phi? Chi ha affermato che i RISC non possano interfacciarsi con dei coprocessori? Ma soprattutto... perché continui a parlare e mettere assieme cose che sconosci?
A una frazione dell'energia di un x86. Con oltre il triplo di efficienza energetica a parità di capacità computazionale (vedere cosa consumava il RoadRunner di IBM a 1 PetaFlop e il primo server only x86 based che è riuscito a superare tale soglia).
Peccato che proprio RoadRunner è basato anche su x86 (Opteron di AMD). Vedi sopra il link...
Ho esaurito il mio tempo a disposizione per oggi.
Visto il contenuto, è stato tempo perso: avresti fatto meglio a impiegarlo per cose "più interessanti".
Se vuoi puoi continuare liberamente a fare propaganda aziendale.
Grazie per avermi dato il permesso...
Almeno tu qualcosa da dire ce l'hai anche se altamente opinabile.
Detto da uno che non sa distinguere un coprocessore esterno da un'unità di calcolo integrata, lo prendo come un complimento.
Però cerca tu di moderare i termini. o, come detto sono un povero "fanatico ignorante".
Adesso non cercare di rigirare la frittata. La discussione è stata tranquilla e pacata finché non hai deciso, come tuo solito, di farla fuori dal vaso con questo commento (http://www.hwupgrade.it/forum/showpost.php?p=41259441&postcount=36): "Pronti via siamo già partiti con il piede sbagliato.
[...]
Non hai capito la differenza che c'è tra l'architettura messa in piedi da Intel e quella messa in piedi dai GPUari. O meglio, fai tanta confusione perché non la si capisca."

Per cui hai ricevuto la risposta che ti meriti. La prossima volta prendi esempio dagli altri, che non hanno avuto alcuna difficoltà a discutere civilmente rispettando il proprio interlocutore, e vedrai che sarai trattato allo stesso modo.
Tu un dipendente di una azienda.
Che ci posso fare: la gente non è tutta come te che si può permettere il lusso di non lavorare alle dipendenze di qualcuno per portare a casa il pane per la famiglia...
Sia tu che la tua azienda avete già dimostrato più volte che i bellissimi e argomentatissimi bla bla sono risultati in fail clamorosi.
Errare humanum est. Non tutte le ciambelle riescono col buco. Ecc. ecc. ecc. Ma fortunatamente un po' di prodotti buoni riusciamo a tirarli fuori, e... siamo ancora qui a giocarcela.
Sii almeno consapevole di questo quando fai affermazioni assolutistiche sulle capacità divinatorie della azienda tua padrona.
A parte il fatto che all'inizio ho ampiamente dimostrato quanto sia falso quello che continui a riportare, io non sono uno schiavo, ma un impiegato. Se poi i dipendenti ti fanno schifo, beh, non mi stupisce dal disprezzo che trasuda da tutti i pori, ma mi scuserai se ti dico che uno che ragiona così mi fa semplicemente schifo.

Comunque tutti questi attacchi ad hominem & circostanziali mettono in evidenza la tua incapacità di affrontare la discussione sul campo puramente tecnico, e siccome rimani un fanatico che deve difendere la sua marca del cuore, ricorri a questi mezzucci dialettici da due soldi per appagare il tuo ego violato.

D'altra parte che non capisci nulla di CPU e GPU l'hai ampiamente dimostrato. Come hai pure dimostrato che non te ne frega nulla delle argomentazioni degli altri, visto che non fai che tagliare ciò che ti è scomodo (vedi la "GPU-tax", sulla quale "stranamente" non hai MAI replicato eliminando integralmente la parte che avevo scritto).

A ulteriore prova di ciò, c'è il link su Maxwell, che non hai nemmeno aperto. Se c'avessi provato ti saresti accorto che avresti ottenuto questo messaggio:
Errore 404 :

La pagina che hai cercato non è più disponibile a questo indirizzo.

Prova ad usare il motore di ricerca !

Mandaci una mail per segnalare il link errato !!!
Per cui mi permetto di riportare la stessa frase di prima, visto che calza perfettamente: brutta cosa il fanatismo...

Dimenticavo. Ovviamente hai perso un sacco di tempo a scrivere un messaggio in cui hai cercato, malamente e inutilmente, di replicare a quello che ti pareva, evitando accuratamente di rispondere alle precise domande che prima ti avevo posto e alle numerose parti scomode.
I commenti sono lì a testimonianza del tuo comportamento intellettualmente disonesto: a te non frega nulla di discutere e confrontarti, perché vuoi soltanto lasciar passare le fantasie che ti sei inventato e a cui ti aggrappi...

Ci sono le notizie a riguardo: la roadmap di Intel per i 14nm NON ha subito cambiamenti. I prodotti, dunque, arriveranno a breve.

Per contro, le ultime notizie su AMD e Nvidia riportano che per i prossimo prodotti continueranno a usare lo stesso processo produttivo attuale, causa problemi di TSMC, e che non si sa quando saranno risolti.

Questi sono FATTI, non prese in giro. Ma se hai informazioni nuove a riguardo, non hai che da postarle...

Di KL si sa che uscirà a 14nm, non foss'altro perché arriverà ben dopo che uscirà Broadwell.

Per Maxwell... no. Come già detto prima, hai informazioni nuove in merito? Riportale pure.


fra l'altro Maxwell oltre che in ritardo è pure stato tarpato perchè doveva portare con se la Unified Memory che ora, dopo il cambio di roadmap, arrivera nel 2016 con Pascal.... sempre ammesso che non si arrivi al 2017 visto com'è l'andazzo di TSMC.

VECCHIA
http://www.custompcreview.com/wp-content/uploads/2013/03/nvidia-gtc-2013-gpu-roadmap-maxwell-volta-custom-pc-review-1.jpg

NUOVA
http://www.enterprisetech.com/wp-content/uploads/2014/03/nvidia-gpu-roadmap.jpg

cut...
Parlo da profano, ma mi chiedevo:
Intel con quest'architettura cerca di elevare la capacità computazionale sia lato fpu che unità vettoriali creando difatti una cpu strana che funziona ne più ne meno come uno xeon classico, ma super ottimizzata solo per alcuni tipi di calcolo.
Gia mi vedo rack con 4 slot occupati da 2+2 o addirittura 1+3 (xeon-phi)

Lo stesso tentativo lo trovo in amd ma fatto in modo diverso (cmd-apu).

Credo che l'approccio Amd sia più dispendioso in fase di realizzazione-studio, mentre quello intel più dispendioso in termini di costo hardaware.

Credi che AMD possa sostituire in toto le unità fpu dei suoi core (cmd) con la parte apu?
Oppure questa strada è senza uscita.
Solo la tua opinione personale.

Va be', per risponderti ruberò un po' di tempo al mio datore di lavoro, io che disprezzo i dipendenti ma dipendente sono.

Non c'è molto da dire se nonché non riusciamo a sintonizzarci sulla stessa frequenza comunicativa. Ti sei appigliato come un polipo a una definizione infelice "sull'unita scalare" dell'archiettura CPU+GPU che per me è la CPU, quella che sta fuori dal die della GPU, quella che esegue le istruzioni in maniera sequenziale (appunto scalare), non le unità interne agli SMM.
Prendi tutto il mio commento precedente e sostituisci le parole "unità scalare" riferita all'architettura GPU+CPU con il "core delle CPU a cui la GPU è collegata tramite bus PCI-e" e vedi se ti torna tutto il ragionamento. Così come per me l'unità scalare (o CPU) all'interno di KC/KL è la parte che esegue codice x86 collegata alla unità vettoriale.

Infine per la questione del confronto con i prodotti vecchi della concorrenza, lo hai fatto perché considerando Maxwell hai bellamente "dimenticato" che Maxwell verrà con core ARM all'interno dello stesso die del cluster di unità di calcolo vettoriale e ne potrà condividere le risorse senza passare dal suddetto bus stretto, quando prima (cioè con Kepler) ogni gestione di un flusso di istruzioni sequanziali è un problema da esegire su GPU ed eseguire un branch del codice comporta una penalità non indifferente. Con un core in grado di eseguire codice sequenziale a fianco del cluster vettoriale usato come "semplice coprocessore" i giochi potrebbero cambiare.
Anche nvidia può costruire una unità di calcolo indipendente come lo sarà KL perché al suo interno ci sono delle CPU in grado di far girare il normale flusso di codice "seriale" e delegare i calcoli vettoriali agli SMM il tutto condividendo la memoria.
Tu invece continui a sostenere che questa è una prerogativa di KL che si permette di poter condividere le risorse tra il core "scalare" (il pezzo che decodifica ed esegue istruzioni x86 per internderci, che altrimenti parti ancora per la tangente) e l'unità AVX.

Come è fatta una GPU lo so bene. Se ti fossi fermato a cercare di capire i termini che ho usato (magari non propriamente, per la cui cosa mi scuso) non saresti partito per una filippica intorno alla definizione ma ti saresti concentrato di più a discutere sul merito delle cose.
Comprenderai che le due architetture hanno approcci tremendamente differenti e che le GPU scalano meglio in termini di quantità di unità di calcolo integrabili. Il 3x, 4x del GK107 è estratto dalle prove eseguite da Anantech della 750Ti. Vedi come si comporta rispetto al GK104.
Per la questione KL andrà meglio perché usa core Saltwell invece che i vecchi Pentium è tutta da dimostrare. Come detto la potenza di calcolo la fa l'unità vettoriale, non quella scalare.

E no, non ho adorazione per nvidia o ARM. La prima è l'unica per ora sta cercando di innovare il mercato usando tecnologia fino a ieri "aliena" all'uso che oggi si sta tentando di fare. Ma se ci fosse anche AMD con le sue GPU sarebbe la stessa cosa, dato che architetturalmente sono molto simili. AMD è già più avanti di nvidia con le sue APU, soluzione simile che nvidia realizzerà con project Denver (cioè avere finalmente una CPU che collabora con il cluster vettoriale localmente e non diviso da un bus strettissimo, che è il cancello che Intel si è costruita per le sue CPU se non era chiaro prima). Il problema di AMD è che nel campo professionale e come supporto allo sviluppo SW vale zero, tant'è che è un peccato che le sue GPU come Tahiti o Hawaii stiano solo nelle schede consumer (il numero delle FirePro che vende sono risibili e non stanno all'interno di nessun super computer).

ARM semplicemente ha dimostrato in diversi anni di non aver sbagliato un colpo e si ritrova con una archiettura molto più efficiente di quel mattone di x86 che ha fermato il progresso tecnologico per anni. Sarei contento (anzi stra contento) che assieme a ARM ci fosse anche MIPS o qualsiasi altra cosa che dimostra (se ce ne fosse ancora bisogno) che l'approccio monolitico di Intel del mega super huber core general purpose che vuole fare tutto da solo non è stata la soluzione migliore e che molto si sarebbe già potuto fare se il monopolio non avesse fatto la sua parte.
Apprezzo ARM (come sarebbe potuto essere il PowerPC, MIPS, Spark, cippalippa) perché oggi finalmente si vede la luce al fondo del tunnel Wintel che ci siamo dovuto sorbire per quasi 30 anni.
Se vuoi ti chiarisco meglio la cosa, così mi sarai più amico di prima: Intel con il suo approccio general purpose spreca transistor/energia ma con PP più avanzato ha rotto le palle. Il progresso si fa in altro modo. E oggi si vede la possibilità di realizzarlo da parte di altri che le stanno erodendo piano piano il mercato.

Riguardo al RoadRunner non hai capito una cosa: tutto il mostro consumava 1/3 di un equivalente PC basato esclusivamente su x86. La parte x86 nel RoadRunner, oltre che essere molto più inefficiente di quella di Intel (gli Opteron di AMD non sono certo famosi per la loro efficienza energetica rispetto agli Xeon Intel) è usata solo per la gestione e la connessione con il resto del sistema e non partecipa alla generazione della potenza di calcolo. Fai tu una estrapolazione per vedere quanto era efficiente la soluzione IBM rispetto a quella Intel al netto dell'energia parassita degli Opteron.

Per quanto riguarda il fatto che il 14nm siano in tabella di marcia... suvvia, chi stai prendendo in giro? I 14nm dovevano essere pronti l'anno scorso e costare 6 miliardi in meno.
Oltrettutto avrebbero dovuto coprire una produzione maggiore vista la nuova fabbrica ora designata come in disuso ancora prima di essere partita. Nel secondo semestre del 2015 i 16nm Finfet dovrebbero essere pronti (si spera).
Se non vuoi credere che nvidia farà un chip Maxwell da 12/14 miliardi di transistor a 28nm, non c'è altro che pensare che la mattonella Maxwell la vedremo a 16nm.
Ma la questione è un'altra e lo stai chiaramente sottolineando: Intel campa ancora perché ha un processo produttivo migliore della concorrenza, non perché sforni dei prodotti che siano migliori nella parte funzionale. E la sua fortuna continuerà fintanto che questo processo produttivo rimarrà avanti agli altri. Cosa che, vista le vicessitudini dei 14nm e i proventi che la concorrenza sta avendo dalla produzione di miliardi di SoC mobile, non è destinata a durare a lungo.

Ora devo veramente smettere o mi licenziano. Beato te che hai un'azienda multimega miliardaria alle spalle che ti permette di avere tutto questo tempo a disposizione.

Per la questione KL andrà meglio perché usa core Saltwell invece che i vecchi Pentium è tutta da dimostrare. Come detto la potenza di calcolo la fa l'unità vettoriale, non quella scalare.

:read: guarda che Saltwell è il die hrink a 32nm di Bonnell, ovvero l'architettura dei vecchi Atom... KL si basera su Silvermont, l'archittura dei nuovi Atom che è come passare dal giorno alla notte e basta prendere in mano uno dei bench dell'Atom Z3770 per capire il salto mostruoso che ha fatto l'architettura Atom fra la vecchia e l'attuale.


Per quanto riguarda il fatto che il 14nm siano in tabella di marcia... suvvia, chi stai prendendo in giro? I 14nm dovevano essere pronti l'anno scorso e costare 6 miliardi in meno.
Oltrettutto avrebbero dovuto coprire una produzione maggiore vista la nuova fabbrica ora designata come in disuso ancora prima di essere partita.


questa è una stupidata; i 14 nm erano previsti da tabella di marcia nel 2014, a fine H1, esattamente in questi mesi al posto di Devil's Canyon e le altre Heswell Refresh.

in un'intervista di luglio a Brian Krzanich ha esplicitamente detto che le prime CPU Broadwell debutteranno a fine di quest'anno, e il resto nei primi mesi del 2015; quindi il ritardo è di circa 6 mesi.

Maxwell doveva essere gia fuori anche lui e da parecchi mesi, e invece non si è ancora visto ( la 750 non conta nulla ) ed è stato pure depotenziato...


Nel secondo semestre del 2015 i 16nm Finfet dovrebbero essere pronti (si spera).


non sappiamo quando arriveranno le GPU a 20 nm, figuriamoci i 16nm; probabilmente li vedremo nel 2016 con Pascal.

:read: guarda che Saltwell è il die hrink a 32nm di Bonnell, ovvero l'architettura dei vecchi Atom... KL si basera su Silvermont, l'archittura dei nuovi Atom che è come passare dal giorno alla notte e basta prendere in mano uno dei bench dell'Atom Z3770 per capire il salto mostruoso che ha fatto l'architettura Atom fra la vecchia e l'attuale.

Sì, scusa ieri ero in super ritardo e mi sono accorto dopo di aver scritto il nome dell'architettura Intel sbagliata. Anche CdMauro lo aveva scritto precedentemente. A scrivere in tempi ristretti non si riesce mai ad essere precisi.
Ciò non toglie che per il calcolo vettoriale cosa ci sia montato a monte/valle/fianco dell'unità AVX conti poco. Che migliori tutta un'altra serie di cose (come la gestione dell'eventuale OS sulla scheda stessa) non ci sono dubbi. Ma sopratutto a parità di prestazioni la nuova archiettura consumerà decisamente meno, che vuol dire che i W risparmiati possono essere spesi per migliorare le capacità dell'unità di calcolo vettoriale.

questa è una stupidata; i 14 nm erano previsti da tabella di marcia nel 2014, a fine H1, esattamente in questi mesi al posto di Devil's Canyon e le altre Heswell Refresh.

in un'intervista di luglio a Brian Krzanich ha esplicitamente detto che le prime CPU Broadwell debutteranno a fine di quest'anno, e il resto nei primi mesi del 2015; quindi il ritardo è di circa 6 mesi.
http://www.hwupgrade.it/news/cpu/roadmap-intel-per-il-2015-broadwell-e-skylake-s-assieme_53023.html

e su un altro sito il recensore scrive:
"Questa sovrapposizione è frutto del ritardo della gamma Broadwell, che sarebbe già dovuta essere sul mercato, lasciando a Skylake il 2015.".

Non è che le dichiarazioni dell'ultimo momento di un dirigente Intel per raddrizzare il tiro sui ritardi accumulati facciano testo.

Inoltre ti invito a fare questa semplice ricerca in google "14nm roadmap". Troverai slide dove si vede che i 14nm sarebbero dovuto essere pronti nel 2013. Una ricerca con "14nm delay" porta a questo recente articolo: http://www.extremetech.com/computing/182660-intel-confirms-14nm-broadwell-shipping-in-time-for-the-holidays.
Dichiarazione evidentemente falsa se la roadmap precedente è vera.
Puoi trovarne decine di questi articoli sul ritardo dei 14nm vecchi anche di diversi mesi comunque.

Infine la nuova roadmap indica i nuovi processori a 14nm per il secondo semestre 2015, quindi altro che 6 mesi di ritardo. La sovrapposizione tra Broadwell e Skylake indica chiaramente che alla fine si arriverà ad almeno 1 anno di ritardo.

Maxwell doveva essere gia fuori anche lui e da parecchi mesi, e invece non si è ancora visto ( la 750 non conta nulla ) ed è stato pure depotenziato...
non sappiamo quando arriveranno le GPU a 20 nm, figuriamoci i 16nm; probabilmente li vedremo nel 2016 con Pascal.
Eh, purtroppo nvidia e AMD non hanno il controllo sul processo produttivo realizzato dagli altri, per cui si prendono quello che è disponibile. Facendo conto che TSMC ha pure deciso che i 20nm non saranno per architetture ad alto consumo ma solo per SoC direi che per vedere una nuova GPU mattonella si dovrà aspettare i 16nm (che TMSC ha dichiarato essere disponibili 12 mesi dopo i 20nm).
Quindi non ci saranno (almeno di rivoluzioni del PP) GPU a 20nm.
Se i 14nm fossero già stati pronti il problema per nvidia e le sue GPU per server HPC sarebbe stato evidente. Con il ritardo dei 14nm di Intel e l'obbligo per nvidia di aspettare i 16nm di TMSC, la differenza di tempi non sarà più così marcata (e forse potrebbe anche arrivare prima TSMC) e il salto prestazionale rispetto ai 28nm con cui oggi realizza Kepler dovrebbe essere enorme.
Da qui, ribadisco, che i numeri di KL non sono per nulla miravigliosi rispetto alle potenzialità che ha la concorrenza, il cui unico problema è da sempre il PP rispetto ad Intel (che novità delle novità, comincia ad avere problemi pure lei).

http://www.hwupgrade.it/news/cpu/roadmap-intel-per-il-2015-broadwell-e-skylake-s-assieme_53023.html

e su un altro sito il recensore scrive:
"Questa sovrapposizione è frutto del ritardo della gamma Broadwell, che sarebbe già dovuta essere sul mercato, lasciando a Skylake il 2015.".

Non è che le dichiarazioni dell'ultimo momento di un dirigente Intel per raddrizzare il tiro sui ritardi accumulati facciano testo.

Inoltre ti invito a fare questa semplice ricerca in google "14nm roadmap". Troverai slide dove si vede che i 14nm sarebbero dovuto essere pronti nel 2013. Una ricerca con "14nm delay" porta a questo recente articolo: http://www.extremetech.com/computing/182660-intel-confirms-14nm-broadwell-shipping-in-time-for-the-holidays.
Dichiarazione evidentemente falsa se la roadmap precedente è vera.
Puoi trovarne decine di questi articoli sul ritardo dei 14nm vecchi anche di diversi mesi comunque.

Infine la nuova roadmap indica i nuovi processori a 14nm per il secondo semestre 2015, quindi altro che 6 mesi di ritardo. La sovrapposizione tra Broadwell e Skylake indica chiaramente che alla fine si arriverà ad almeno 1 anno di ritardo.


Broadwell è SEMPRE stato atteso per il 2014, non nel 2013, visto che è stato il lancio di Haswell.

la roadmap di oggi e l'altro articolo possono essere entrambi validi perchè anche Brian Krzanich aveva accennato a qualche CPU Broadwell non a tutta la linea.

ritardo è in ritardo, su li no nci piove, ma mi sembra messa molto megli oIntel come tempistiche/ritardi piuttosto che nVidia o AMD, visto che loro non hanno il controllo di nulla.

Intel è sempre stata messa meglio per quanto riguarda le tempistiche dei suoi processi produttivi.

Però il ritardo dei 14nm, che non è una sciocchezza come quella avvenuta per i 22nm, dimostra che Intel sta rallentando là dove ha il suo punto di forza massimo.
nvidia non ha mai avuto alcun controllo del processo produttivo, e AMD non ce l'ha più da quando ha venduto le sue fabbriche (vale solo per le CPU, il reparto GPU acquistato da ATI ha sempre fatto prodotti usando processi produttivi fuori dal controllo di AMD).

Questo però non mette Intel in una posizione migliore. nvidia, AMD e tutti i produttori di SoC ARM non devono guadagnare oltre al necessario per mantenere delle fabbriche e aggiornarle ogni 2 anni almeno. Tuttavia, tutte insieme collaborano a pagare i costi di TSMC per farlo.

Non confondere la disponibilità del processo produttivo con la messa in vendita dei prodotti. I 14nm dovevano essere pronti nel 2013, produzione 1Q 2014 e vendita dei prodotti agli OEM in Q3, come sempre fatto. Oggi invece non abbiamo i 14nm pronti e la produzione non è partita, il ritardo ad oggi sarebbe di 6 mesi se la produzione cominciasse domani, ma non sembra sarà così.
Prima del ritardo dei 14nm la situazione a inizio 2014 sarebbe stata Intel a 14nm, TMSC ancora a 28nm, con una differenza sostanziale di processo produttivo a tutto vantaggio dei prodotti Intel.
Con il ritardo secondo l'ultima roadmap con prodotti in uscita il Q2 dell'anno prossimo la situazione per il mercato CPU (che conta per il mercato mobile dove Intel ha concorrenza, su desktop può tenersi ancora i 22nm per altri 2 anni senza problema) sarà: Intel 14nm, TSMC (quindi tutti i SoC ARM) 20nm.
Il che taglia di netto tutti i vantaggi che Intel ha fatto con gli Atom, dato che si scontrerà con SoC a 64 bit molto più efficienti di quanto già oggi sia l'A7 di Apple (che dà abbastanza la polvere agli Atom a 28nm).
Per il mercato extra CPU, Intel 14nm resto du mundo moolto vicino ai 16nm (che sono in realtà i 20nm Finfet). Se non già disponibili (da vedere i problemi di TMSC che ad oggi non sappiamo).
Sempre che i 16nm non vengano usati pure per fare SoC, il chè sarebbe ancora peggio per Intel.
Vedi che la situazione processi produttivi tende a schiacciare notevolmente il vantaggio che Intel è riuscita a sfruttare in tutti questi anni.
Gli strabilianti vantaggi che Intel vanta per la sua archiettura KL (o le linee Atom destinate al mobile) a 14nm si scontreranno violentemente contro i vantaggi ancora migliori che la concorrenza potrà godere (sempre che TSMC non sbarelli completamente come ha fatto Intel con il suo processo produttivo, ma pensarlo è sola speculazione o speranza che accada).
Quindi, là dove Intel non riesce oggi a superare le qualità degli altri, è difficile pensare che possa fare meglio con la prossima linea di prodotti. Sopratutto là dove non c'è alcuna rivoluzione, ma solo un raffinamento di quel che ha già proposto.

Tutto qui, non era necessario fare alcun tipo di filippica su documenti e valori spacciati per strabilianti ma che dicono nulla se non rapportati a quello che gli altri possono fare (e in questo momento i fatti dicono che possono migliorare di più di quanto potrà fare Intel).

Intel è sempre stata messa meglio per quanto riguarda le tempistiche dei suoi processi produttivi.

Però il ritardo dei 14nm, che non è una sciocchezza come quella avvenuta per i 22nm, dimostra che Intel sta rallentando là dove ha il suo punto di forza massimo.
nvidia non ha mai avuto alcun controllo del processo produttivo, e AMD non ce l'ha più da quando ha venduto le sue fabbriche (vale solo per le CPU, il reparto GPU acquistato da ATI ha sempre fatto prodotti usando processi produttivi fuori dal controllo di AMD).

Questo però non mette Intel in una posizione migliore. nvidia, AMD e tutti i produttori di SoC ARM non devono guadagnare oltre al necessario per mantenere delle fabbriche e aggiornarle ogni 2 anni almeno. Tuttavia, tutte insieme collaborano a pagare i costi di TSMC per farlo.

Non confondere la disponibilità del processo produttivo con la messa in vendita dei prodotti. I 14nm dovevano essere pronti nel 2013, produzione 1Q 2014 e vendita dei prodotti agli OEM in Q3, come sempre fatto. Oggi invece non abbiamo i 14nm pronti e la produzione non è partita, il ritardo ad oggi sarebbe di 6 mesi se la produzione cominciasse domani, ma non sembra sarà così.
Prima del ritardo dei 14nm la situazione a inizio 2014 sarebbe stata Intel a 14nm, TMSC ancora a 28nm, con una differenza sostanziale di processo produttivo a tutto vantaggio dei prodotti Intel.
Con il ritardo secondo l'ultima roadmap con prodotti in uscita il Q2 dell'anno prossimo la situazione per il mercato CPU (che conta per il mercato mobile dove Intel ha concorrenza, su desktop può tenersi ancora i 22nm per altri 2 anni senza problema) sarà: Intel 14nm, TSMC (quindi tutti i SoC ARM) 20nm.
Il che taglia di netto tutti i vantaggi che Intel ha fatto con gli Atom, dato che si scontrerà con SoC a 64 bit molto più efficienti di quanto già oggi sia l'A7 di Apple (che dà abbastanza la polvere agli Atom a 28nm).
Per il mercato extra CPU, Intel 14nm resto du mundo moolto vicino ai 16nm (che sono in realtà i 20nm Finfet). Se non già disponibili (da vedere i problemi di TMSC che ad oggi non sappiamo).
Sempre che i 16nm non vengano usati pure per fare SoC, il chè sarebbe ancora peggio per Intel.
Vedi che la situazione processi produttivi tende a schiacciare notevolmente il vantaggio che Intel è riuscita a sfruttare in tutti questi anni.
Gli strabilianti vantaggi che Intel vanta per la sua archiettura KL (o le linee Atom destinate al mobile) a 14nm si scontreranno violentemente contro i vantaggi ancora migliori che la concorrenza potrà godere (sempre che TSMC non sbarelli completamente come ha fatto Intel con il suo processo produttivo, ma pensarlo è sola speculazione o speranza che accada).
Quindi, là dove Intel non riesce oggi a superare le qualità degli altri, è difficile pensare che possa fare meglio con la prossima linea di prodotti. Sopratutto là dove non c'è alcuna rivoluzione, ma solo un raffinamento di quel che ha già proposto.

Tutto qui, non era necessario fare alcun tipo di filippica su documenti e valori spacciati per strabilianti ma che dicono nulla se non rapportati a quello che gli altri possono fare (e in questo momento i fatti dicono che possono migliorare di più di quanto potrà fare Intel).
La parte più importante che non hai proprio analizzato è il fatto che la maggiorparte del software ricompilato gia sfrutta queste schede (praticamente senza mettere mano al codice).
Solo questo può far risparmiare tanti $ che praticamente il costo energetico di due anni di lavoro diventerebbero gratis.
Mettici che lo stesso software praticamente sarà in grado di girare anche per 2-3 generazioni di queste schede e vedi il vantaggio reale che avrà chi adotterà tale soluzione.

La parte più importante che non hai proprio analizzato è il fatto che la maggiorparte del software ricompilato gia sfrutta queste schede (praticamente senza mettere mano al codice).
Solo questo può far risparmiare tanti $ che praticamente il costo energetico di due anni di lavoro diventerebbero gratis.
Mettici che lo stesso software praticamente sarà in grado di girare anche per 2-3 generazioni di queste schede e vedi il vantaggio reale che avrà chi adotterà tale soluzione.

Ni, nel senso che è vero che la programmazione per l'architettura Intel è più semplice, ma non è detto che questo ripaghi dei costi o delle prestazioni ottenibili.
Facciamo un caso, mettiamo che per ottimizzare il codice per l'architettura NVIDIA ci voglia un anno uomo (ammettendo quindi un costo e un tempo abbastanza contenuti). Se però le prestazioni su questa archiettura sono il doppio, significa avere risposte in metà tempo, o a parità di tempo di svolgono il doppio delle simulazioni o simulazioni più complete/complesse. Se poi si aggiunge che magari l'archiettura è più efficiente serve meno della metà dell'energia (a parità di risultato). Si parla di MW per i server di calcolo, che è la componente più costosa di tutto il mantenimento della struttura operativa. Usarne metà significa risparmiare molto di più di quanto costi l'ottimizzazione del codice.

Questo ovviamente è un esempio con numeri a caso, ma non fantascientifici. Puoi pensare ad una efficienza uguale ma la densità permessa dalla soluzione GPU sia maggiore (risparmio in spazio e numero di cluster da collegare alla network). Che vuol dire che a parità di densità si ottiene maggiore potenza elaborativa (con equivalemte aumento dei consumi ma una diminuzione dei tempi di risposta o come detto, stesso tempo ma simulazioni più complesse).

Io lavoro in un centro di R&D. Posso assicurarti che il costo della ricerca e sviluppo è minimo rispetto ai costi di produzione poi del prodotto e quindi spesso e volentieri la ricetta è quella di rendere più difficile la vita all'R&D per poi risparmiare qualcosa in produzione. Risparmio che sembra piccolo, ma che su grandi numeri signifca diverse centinaia di migliaia di euro che vanno molto più che a coprire il delta dei costi di uno sviluppo più complesso/meno lineare.

Se hai 10 persone che in un mese o due ti ottimizzano il codice e poi risparmi 1MW al giorno o dimezzi i tempi di simulazione puoi stare sicuro che la scelta non è avere un SW che è facile da compilare ma rende meno. Finché il costo dei centri di elaborazione è per la maggior parte quella energetica questa è la necessità. Non è un caso, per esempio, che i neo nati server ARM sono visti tutti con grande interesse proprio per il risparmio energetico che possono portare. Altrimenti, per le prestazioni che offrono rispetto ai mostri Intel/Oracle/IBM non li prenderebbe nessuno in considerazione.

Ni...

cut

Non è un caso, per esempio, che i neo nati server ARM sono visti tutti con grande interesse proprio per il risparmio energetico che possono portare.

Ma hai presente in che ambito vengono usati i server Arm?
Per il momento usare un server arm per interrogazioni in DB (che teoricamente dovrebbe essere il suo campo di impiego più congeniale) porta vantaggi miseri a livello energetico (da test indipendenti fatti risulatava che 64 core arm A9 raggiungevano lo stesso carico medio di uno xeon 10 core+ht), ma con un costo dell'hardware molto più alto.

Quindi quel ni è da considerare in molti modi diversi, ed il principale è:
In hpc, che cercano le massime prestazioni, aggiornare facilmente hardware e software con costi relativi bassi può favorire quest'architettura?
Per il resto le preferenze delle aziende (e relative bustarelle da parte di chicchesia) possono decretare il successo di una tecnologia non per forza migliore della rivale.
(E le bustarelle non erano riferite a nessuno in particolare, ma mi è venuta in mente a causa di un trascorso di una famosa azienda italiana produttrice di elicotteri).

Ma hai presente in che ambito vengono usati i server Arm?
Per il momento usare un server arm per interrogazioni in DB (che teoricamente dovrebbe essere il suo campo di impiego più congeniale) porta vantaggi miseri a livello energetico (da test indipendenti fatti risulatava che 64 core arm A9 raggiungevano lo stesso carico medio di uno xeon 10 core+ht), ma con un costo dell'hardware molto più alto.

Quindi quel ni è da considerare in molti modi diversi, ed il principale è:
In hpc, che cercano le massime prestazioni, aggiornare facilmente hardware e software con costi relativi bassi può favorire quest'architettura?
Per il resto le preferenze delle aziende (e relative bustarelle da parte di chicchesia) possono decretare il successo di una tecnologia non per forza migliore della rivale.
(E le bustarelle non erano riferite a nessuno in particolare, ma mi è venuta in mente a causa di un trascorso di una famosa azienda italiana produttrice di elicotteri).

Lascia stare, tanto se non sei dell'opinione che nVidia rulez andrai avanti per giorni. cdimauro mi pare abbia esposto tutta la situazione argomentandola per bene, per contro ha ricevuto solo tanti caratteri senza una minima argomentazione.

Ma hai presente in che ambito vengono usati i server Arm?
Per il momento usare un server arm per interrogazioni in DB (che teoricamente dovrebbe essere il suo campo di impiego più congeniale) porta vantaggi miseri a livello energetico (da test indipendenti fatti risulatava che 64 core arm A9 raggiungevano lo stesso carico medio di uno xeon 10 core+ht), ma con un costo dell'hardware molto più alto.

Quindi quel ni è da considerare in molti modi diversi, ed il principale è:
In hpc, che cercano le massime prestazioni, aggiornare facilmente hardware e software con costi relativi bassi può favorire quest'architettura?
Per il resto le preferenze delle aziende (e relative bustarelle da parte di chicchesia) possono decretare il successo di una tecnologia non per forza migliore della rivale.
(E le bustarelle non erano riferite a nessuno in particolare, ma mi è venuta in mente a causa di un trascorso di una famosa azienda italiana produttrice di elicotteri).
Non fare anche tu l'errore di usare test e comparazioni vetuste per determinare le capacità di qualcosa. I core A9 sono stati usati come esperimento e in certi contesti si sono rivelati decisamente migliori degli Xeon, mostrando diverse potenzialità. Ma sono a 32bit e quindi per l'accesso a grandi database non possono esseere usati. L'azienda che aveva fatto l'HW apposta come pioniere in questo campo è infatti fallita.
Viste comunuqe le grandi potenzialità altre aziende stanno ora investendo nell'archiettura 64 bit di ARM. AMD compresa. Il tuo serverino nell'armadio aziendale potrà continuare a usare gli Xeon, ma i gradi datacenter (Amazon, Google, Facebook) stanno tutte cercando alternative per risparmiare. Il risparmio non è sul costo dell'HW, ma su quello energetico. Infatti ci sono anche esperimenti fatti con tecnologie "astruse" come l'utilizzo delle FPGA. Che hanno costi esorbitanti rispetto ai microprocessori, ma consumano una frazione dell'energia per fare lo stesso lavoro. Se ci stanno facendo degli studi vuol dire che il costo dell'HW non è il problema, no?

Per gli HPC, ripeto, dipende tutto dalla differenza tra i costi di sviluppo e il risparmio del costo energetico. O in certi contensti, solo dalla potenza bruta ottenibile. Se risparmio 100MW ma ci metto 2 anni invece che 1 a trovare la soluzione, oppure le simulazioni possibili in un detrerminato tempo non possono essere esaustive può essere che non riesca a stare sul mercato come azienda o non riesca ad essere efficace nei controlli o a costruire la prossima bomba atomica prima del nemico. O non riesca a fare il reattore a fusione fredda prima di qualcun altro.

La questione bustarelle la lascerei perdere, perché ultimamente l'azienda che ha dimostrato di usare la leva finanza (accordi con produttori/distributori e vendita sottocosto di HW che non compete con il resto del mercato) invece che il merito tecnologico è la stessa di cui stiamo dicutendo il prodotto qui.
Ma non apriamo un altro sterile dibattito che poi a qualcuno viene la tachicardia :D
Io parlo di merito tecnologico sul campo.

Non fare anche tu l'errore di usare test e comparazioni vetuste per determinare le capacità di qualcosa. I core A9 sono stati usati come esperimento e in certi contesti si sono rivelati decisamente migliori degli Xeon, mostrando diverse potenzialità. Ma sono a 32bit e quindi per l'accesso a grandi database non possono esseere usati. L'azienda che aveva fatto l'HW apposta come pioniere in questo campo è infatti fallita.
Viste comunuqe le grandi potenzialità altre aziende stanno ora investendo nell'archiettura 64 bit di ARM. AMD compresa. Il tuo serverino nell'armadio aziendale potrà continuare a usare gli Xeon, ma i gradi datacenter (Amazon, Google, Facebook) stanno tutte cercando alternative per risparmiare. Il risparmio non è sul costo dell'HW, ma su quello energetico. Infatti ci sono anche esperimenti fatti con tecnologie "astruse" come l'utilizzo delle FPGA. Che hanno costi esorbitanti rispetto ai microprocessori, ma consumano una frazione dell'energia per fare lo stesso lavoro. Se ci stanno facendo degli studi vuol dire che il costo dell'HW non è il problema, no?

Per gli HPC, ripeto, dipende tutto dalla differenza tra i costi di sviluppo e il risparmio del costo energetico. O in certi contensti, solo dalla potenza bruta ottenibile. Se risparmio 100MW ma ci metto 2 anni invece che 1 a trovare la soluzione, oppure le simulazioni possibili in un detrerminato tempo non possono essere esaustive può essere che non riesca a stare sul mercato come azienda o non riesca ad essere efficace nei controlli o a costruire la prossima bomba atomica prima del nemico. O non riesca a fare il reattore a fusione fredda prima di qualcun altro.

La questione bustarelle la lascerei perdere, perché ultimamente l'azienda che ha dimostrato di usare la leva finanza (accordi con produttori/distributori e vendita sottocosto di HW che non compete con il resto del mercato) invece che il merito tecnologico è la stessa di cui stiamo dicutendo il prodotto qui.
Ma non apriamo un altro sterile dibattito che poi a qualcuno viene la tachicardia :D
Io parlo di merito tecnologico sul campo.
Ok un atom consuma il doppio rispetto un corrispettivo arm, ma quanto incide questo su tutto l'hardware (anche moltiplicato per milioni di pezzi)?
Praticamente a parità di prestazioni la differenza di consumo è minima, perché non è che mettendoci un arm sulla mb l'hd dimezza i consumi, o le schede di rete o tutto il resto.
La ricerca all'estero, e supratutto in USA è vantaggiosa farla anche solo per fini fiscali (che poi porta anche innumerevoli altri vantaggi è indiscutibile), cosa che i politici italiani e l'italiano medio ancora non capisce.
Quindi secondo la tua opinione Intel dovrebbe acquistare una licenza arm e sviluppare tale architettura in una famiglia di cpu dal design custom (ed a quanti soldi e capacità produttive ha potrebbe anche farlo).
Probabilmente però i loro vertici (ed il reparto ricerca e sviluppo) credono ancora in x86 e sue declinazioni, e non credo che siano persone non capaci di valutare tale scenario.

Ok un atom consuma il doppio rispetto un corrispettivo arm, ma quanto incide questo su tutto l'hardware (anche moltiplicato per milioni di pezzi)?.

mica vero, Anandtech ha gia fatto test in passato che mostravano gli Atom reggere benissimo il confronto con gli Arm, e la contropova l'avremo a fine anno quando arriveranno gli Opteron 8 core Arm che si scontreranno con gli Atom 8 core Xeon, dove su carta, con i dati annunciati, gli Xeon vincono sia con il TDP che con le prestazioni.

Vedi la differenza tra me e chi invece si impunta sulle questioni usando numeri e valori che non hanno valore pratico?
Io mi limito a indicare quello che succede.
Io non ti sto dicendo che una CPU ARM consumando la metà non è sufficientemente parsimonioso per compensare il costo di tutto il resto. Non sono io che faccio i conti e le simulazioni. Ma poiché c'è chi investe e chi sta facendo esperimenti in questo senso significa che la cosa ha un suo perché. Non sta a me dire prima di tutto se un core ARM consuma "solo" la metà di uno Atom e dopo se il consumo rispetto a tutto l'ambaradan che gli sta dietro è insignificante.
Comunque risparmiare 1W a CPU (non core) e montare 10.000 CPU ha un suo risparmio comunque. Se ne monti 100.000 ancora di più. Ancora di più se dimezzi il sistema di raffreddamento e ancora di più se non ce lo metti proprio.
Sulle FPGA può essere un esercizio di stile per dimostrare che comunuqe si può fare meglio di quel che abbiamo oggi ma non avere reale valore pratico. Ma se domani si scopre che Oracle compra 1 milione di FPGA o allestisce un reparto solo per lo sviluppo con quell'architettura vuol dire che la cosa può avere un senso economico. Non lo fa solo per avere incentivi statali.

Per quanto riguarda la ricerca "che ha vantaggi fiscali" se proprio, io come azienda, devo "buttare" dei soldi lo faccio facendo ricerca in qualcosa che mi può essere d'aiuto in futuro. Se veramente la questione dei SoC ARM nei server non ha senso di esistere non ci investo e uso quei soldi per qualcosa d'altro (in AMD per esempio a tentare di fare una archiettura x86 che consumi la metà a parità di prestazioni di quella che ha ora in produzione). Sempre ricerca faccio, sempre "incentivi" fiscali prendo, ma almeno spero che il lavoro porti a qualcosa. Le aziende tecnologiche vivono perché fanno ricerca nei campi dove credono troveranno maggiori guadagni. Altrimenti, ripeto, sono soldi buttati che ti lasciano al palo rispetto agli altri che investono dove serve. Certo, qualche volta sbagliano e ne pagano le conseguenze, ma è ciò che dimostra che le ricerce sono fatte per raggiungere uno scopo e non tanto per fare, diversamete che qui in Ita(g)lia dove si pagano tutti i tipi di ricerca che non portano a nulla di concreto basta che sia ricerca su qualcosa che collezioni tanti link in altre ricerche che a loro volta non portano a nulla... e sempre che sia ricerca, perché spesso alla ricerca si sostituisce la parola "innovazione" che vuol dire sovvenzioni al rinnovo di parco macchine, PC, stampanti, e cose del genere).

In tutta questa discussione io ho solo fatto notare che la nuova proprosta Intel che arriverà tra un anno non si scontrerà con Kepler con la quale si fanno i confronti, ma con Maxwell che è ben altra cosa, sia in termini di architettura che in processo produttivo. Purtroppo non si sa nulla dell'archiettura futura di AMD, sennò si poteva un paragone anche con quella.
Ma qui le etichette alle persone si sprecano, tanto non costano nulla.

Una analoga discussione nacque quando feci notare la stessa cosa con tutte le vecchie versioni dell'Atom che non si è cag@to nessuno fino a quando Intel non ha cominciato a dare "incentivi" per adottarlo. Puoi venire qui a spaccare il capello su quanti microampre consuma in stato C0, C1, o cippalippa e quanti MIPS faccia a 1GHz, quanto meglio va nel test "nonservoanullamaqualcosamisuro", quanti FPS fai a 10000x10000 che nessun altro è in grado di supportare, ma se là fuori ci sono 20 produttori di HW e nessuno lo considera un motivo ci sarà no?
E normalmente per un produttore "neutrale" la non adozione è per via del costo (se non è proprio una schifezza il prodotto in sé, tanto belli questi Atom, ma come ho sempre sostenuto a parità di area costano di più di un ARM fatto con PP più vecchio). Tagliato il prezzo (o dati i soldi in altro modo per farlo adottare) ecco che magicamente l'Atom comincia a comparire in qualche dispositivo.
C'è merito tecnologico in questo? Non mi sembra.
Aiuta il progresso? Nemmeno
Favorisce lo sviluppo di HW migliore? Nemmeno

Però io sono pro-nvidia/ARM e anti-Intel/AMD e quindi quello che dico è fuffa.
Mi chiedo perché perdo tempo (mio e dell'azienda che mi paga) per cercare di venire qui a farvi guardare un po' più in là del vostro naso o a pensare oltre alle barrette colorate.

mica vero, Anandtech ha gia fatto test in passato che mostravano gli Atom reggere benissimo il confronto con gli Arm, e la contropova l'avremo a fine anno quando arriveranno gli Opteron 8 core Arm che si scontreranno con gli Atom 8 core Xeon, dove su carta, con i dati annunciati, gli Xeon vincono sia con il TDP che con le prestazioni.

Ok avrei dovuto mettere a PP uguale ed ho esagerato con le proporzioni.
Ma mettendo tutto in conto alla fine tra un atom ed un arm su stesso hardware avremo a stento una differenza del 2% max come consumi.
Io non ci vedo tutto questo risparmio di MW.

mica vero, Anandtech ha gia fatto test in passato che mostravano gli Atom reggere benissimo il confronto con gli Arm, e la contropova l'avremo a fine anno quando arriveranno gli Opteron 8 core Arm che si scontreranno con gli Atom 8 core Xeon, dove su carta, con i dati annunciati, gli Xeon vincono sia con il TDP che con le prestazioni.
Ricorda sempre con quale processo produttivo sono realizzati però.
Se non saranno a 20nm dubito che l'Opteron di AMD possa andare tanto lontano, quando ci sono già aziende che stanno facendo ARM a 64bit a 20nm.
Le potenzialità di ARM sono ovviamente sfruttabili quando non lo penalizzi troppo con il processo produttivo. Ed è prorpio il trend che si sta verificando. Ecco perché molti stanno sempre più guardando ad ARM invece che a x86.
Se non sarà con la prima infornata a 64bit@20nm, quando arriveranno i 16nm le cose potrebbero essere diverse. E i 16nm di TMSC ariveranno sicuramente prima dei 10nm di Intel (altrimenti ciao a tutti).

Quindi secondo la tua opinione Intel dovrebbe acquistare una licenza arm e sviluppare tale architettura in una famiglia di cpu dal design custom (ed a quanti soldi e capacità produttive ha potrebbe anche farlo).
Intel ha già una licenza ARM. Ma che senso ha per una azienda che ha il monopolio dell'archiettura desktop e ha una bella fetta di quella server investire in tecnologia di altri? Cosa ci guadagna? SI va a mettere sullo stesso livello di Apple, Qualcomm o Samsung avendo solo il processo produttivo come vantaggio. Che non è destinato a durare.
E per il desktop che fa? Si fa fare una versione Windows per ARM? Insieme a tutte le applicazioni professionali? O bella, sarebbe la mossa giusta per venire asfaltata dal resto della truppa nel momento in cui il SW diventa compatibile anche con qualcosa di cui lei non ha l'esclusivo possesso (tralascio AMD per ovvie performance di mercato sempre più insignificanti).
La strategia di Intel è quella di difendere quello che si è costruita in questi 25 anni insieme a Microsoft, che è poi quello che giustifica il suo HW, che è venduto a camionate che le permette di venderlo a costi più bassi per via dell'economia di scala e che le permette di rimanere davanti al resto nel processo produttivo.
E' un equilibrio delicato che sta per rompersi (se non si è già rotto) là dove la gente non vede più in Windows (e quindi x86) un motivo di dipendenza. E Intel questo lo sa bene, perché il prossimo processo produttivo lo deve pagare con gli introiti del solo mercato desktop/server in forte contrazione, pagare i sussidi per l'adozione degli Atom nel mobile, mentre la concorrenza sta facendo investimenti giganteschi nel mercato boom del mobile e le sta col fiato sul collo.

Intel ha già una licenza ARM. Ma che senso ha per una azienda che ha il monopolio dell'archiettura desktop e ha una bella fetta di quella server investire in tecnologia di altri? Cosa ci guadagna? SI va a mettere sullo stesso livello di Apple, Qualcomm o Samsung avendo solo il processo produttivo come vantaggio. Che non è destinato a durare.
E per il desktop che fa? Si fa fare una versione Windows per ARM? Insieme a tutte le applicazioni professionali? O bella, sarebbe la mossa giusta per venire asfaltata dal resto della truppa nel momento in cui il SW diventa compatibile anche con qualcosa di cui lei non ha l'esclusivo possesso (tralascio AMD per ovvie performance di mercato sempre più insignificanti).
La strategia di Intel è quella di difendere quello che si è costruita in questi 25 anni insieme a Microsoft, che è poi quello che giustifica il suo HW, che è venduto a camionate che le permette di venderlo a costi più bassi per via dell'economia di scala e che le permette di rimanere davanti al resto nel processo produttivo.
E' un equilibrio delicato che sta per rompersi (se non si è già rotto) là dove la gente non vede più in Windows (e quindi x86) un motivo di dipendenza. E Intel questo lo sa bene, perché il prossimo processo produttivo lo deve pagare con gli introiti del solo mercato desktop/server in forte contrazione, pagare i sussidi per l'adozione degli Atom nel mobile, mentre la concorrenza sta facendo investimenti giganteschi nel mercato boom del mobile e le sta col fiato sul collo.
OK ho capito infine che non conosci nemmeno la differenza tra licenza, soc standard e chip custum (come quelli Apple, Samsung, mediatek e decine di altri).
Quando si parla del prodotto dell'articolo non lo consideri perché uscirà tra sei mesi, invece quando parli di arm vs atom mi tiri fuori la questione dello stesso PP che forse fonderie terze riusciranno ad eguagliare intel tra 10 anni.
Viva l'obiettività.

fra l'altro Maxwell oltre che in ritardo è pure stato tarpato perchè doveva portare con se la Unified Memory che ora, dopo il cambio di roadmap, arrivera nel 2016 con Pascal.... sempre ammesso che non si arrivi al 2017 visto com'è l'andazzo di TSMC.

VECCHIA
[...]
NUOVA
[...]
Grazie per averlo ricordato. Avevo dimenticato questo, e il fatto che Volta fosse sparito.
Parlo da profano, ma mi chiedevo:
Intel con quest'architettura cerca di elevare la capacità computazionale sia lato fpu che unità vettoriali
Se per FPU intendiamo la classica unità di calcolo scalare che le CPU hanno avuto dalla notte dei tempi (prima come coprocessore esterno, poi integrato nel core), allora no: x87 (l'FPU degli x86) rimane inalterata da parecchio tempo ormai (se non ricordo male è stato soltanto una versione del Pentium 4, forse quello che portò le SSE3, ad aver effettuato qualche cambiamento, integrando una o due istruzioni per quest'unità di calcolo, una dozzina d'anni fa).

Per il resto è dai tempi delle SSE che ormai Intel, come pure le altre aziende, puntano tutto sulle unità vettoriali.

Quindi l'FPU x87 è presente in tutti i core x86 (inclusi quelli di Xeon Phi, ovviamente), ma risulta scarsamente utilizzata per questi motivi. Ma uno dei motivi per cui ancora oggi è utilizzata riguarda la maggior precisione di calcolo che è possibile ottenere con essa. Infatti mentre le unità SIMD, come pure le FPU di altri processori (tranne alcuni che hanno supporto a float a 128bit, ma parliamo di macchine per impieghi molto particolari, e parecchie lontane dal mercato mainstream), manipolano al più dati in virgola mobile a 64 bit (il famigerato formato a doppia precisione, aka FP64), x87 è in grado di eseguire calcoli a 80 bit (16 bit di esponente e ben 64 di mantissa), garantendo una precisione molto più accurata. Per cui in questo caso gli sviluppatori sacrificano le prestazioni in favore della precisione.
creando difatti una cpu strana che funziona ne più ne meno come uno xeon classico, ma super ottimizzata solo per alcuni tipi di calcolo.
Funziona come uno Xeon, ma è massicciamente orientato al calcolo vettoriale e parallelo, mentre lo Xeon è più "general purpose".
Gia mi vedo rack con 4 slot occupati da 2+2 o addirittura 1+3 (xeon-phi)
In teoria con KL potresti avere tranquillamente rack con soltanto processori Xeon Phi. Non servono degli Xeon "tradizionali", perché KL è in grado di svolgere anche il ruolo di CPU. Inoltre ha particolari connessioni veloci con altri processori.
Lo stesso tentativo lo trovo in amd ma fatto in modo diverso (cmd-apu).
A livello puramente concettuale sì. A livello pratico nVidia sta lavorando per realizzare grosso modo quello che AMD già offre con le APU, mentre KL si differenzia da entrambi avendo integrato direttamente nel core l'unità vettoriale (non è comandata da un core "tradizionale", ma esterno agli shader processor, per intenderci, come ho spiegato negli commenti).
Credo che l'approccio Amd sia più dispendioso in fase di realizzazione-studio, mentre quello intel più dispendioso in termini di costo hardaware.
Non ci sono numeri in merito, ma c'è da dire che AMD, al pari di nVidia, si porta dietro la sua "GPU-tax", integrando elementi propri delle GPU che non servono nei calcoli più general-purpose. In un precedente commento ho riportato un elenco di questi elementi, con annessi calcoli basati sull'enorme register file in dotazione a ogni "macro-unità" di elaborazione (SMM per nVidia).

Ma numeri in merito non ce ne sono per cercare di capire, per ogni soluzione (AMD, nVidia, Intel / Xeon Phi), quanto pesa la rispettiva "tassa". In realtà qualche numero lo conosco, ma si tratta di informazioni che non posso riportare; diciamo che non siamo messi male, ecco. ;)
Credi che AMD possa sostituire in toto le unità fpu dei suoi core (cmd) con la parte apu?
Oppure questa strada è senza uscita.
Non può farlo perché perderebbe la compatibilità col codice x86 già scritto. Sulle APU di AMD può girare anche roba arcaica: persino il DOS 1.0.

In teoria potrebbe realizzare delle APU ad hoc in cui, imitando Intel, e togliendo di mezzo il supporto alle SSE, le rimpiazzasse l'unità SIMD con una nuova a vocazione massicciamente parallela. Xeon Phi, infatti, si porta dietro soltanto x87, mentre si è sbarazzato completamente dell'unità SSE (e AVX), avendola sostituita in toto con la nuova unità vettoriale (chiamiamola EVEX, al momento, perché AVX-512 è l'estensione che arriverà con KL); d'altra parte SSE/AVX sarebbe stata una duplicazione.

Comunque si potrebbe anche togliere di mezzo x87, ma si tratta di una piccola unità che viene tutt'oggi utilizzata in tanto codice. Rimuoverla farebbe risparmiare un po' di transistor, ma a mio avviso non ne vale la pena e comunque verrebbe meno la possibilità di eseguire calcoli con 80 bit di precisione, che rimane il suo valore aggiunto.
Solo la tua opinione personale.
Spero che le mie risposte siano adeguate. Considera, comunque, che non ho informazioni dettagliate su come funzionano le GPU di nVidia e AMD. Per essere chiari, mi mancano gli "internal". Tempo fa lessi un corposo documento di nVidia riguardo a Fermi, e da lì ho dedotto qualcosa (come, ad esempio, che gli shader processor utilizzavano una forma di esecuzione condizionale delle istruzioni simile a quella dei processori ARM), ma per il resto ho a disposizione le informazioni "di massima" che conoscono (o dovrebbero conoscere) un po' tutti.
Di Xeon Phi, invece, sono a conoscenza di un sacco di cose, inclusa la struttura degli opcode, per cui posso anche "visualizzare", dato un problema, in che modo verrebbe eseguito (e magari le istruzioni generate).
Va be', per risponderti ruberò un po' di tempo al mio datore di lavoro, io che disprezzo i dipendenti ma dipendente sono.
Allora non si capisce perché mi hai attaccato proprio su questo punto, visto che sei nella mia stessa situazione.

Comunque preferisco mantenere la discussione in topic e a livello strettamente tecnico.
Ora devo veramente smettere o mi licenziano. Beato te che hai un'azienda multimega miliardaria alle spalle che ti permette di avere tutto questo tempo a disposizione.
Dalle mie parti c'è un detto che, tradotto, suona come "non ci scambiamo i vestiti". Io non scrivo mai durante l'orario di lavoro, come puoi notare dall'orario dei miei commenti. Perché a lavoro... lavoro. Ho tante cose da fare che, anche volendo, non avrei proprio il tempo per fare altro; anzi, generalmente faccio più del dovuto, ma lo faccio con piacere perché amo il mio lavoro e quello che faccio.

Per cui respingo al mittente le accuse, e mi chiedo se il tuo datore di lavoro sa che perdi così tanto tempo nei forum.

Adesso devo sistemarmi e correre a lavoro. In questi giorni non ho avuto tempo perché la mia famiglia mi ha raggiunto dall'Italia, e abbiamo avuto parecchio da fare. Ho approfittato di un attimo di respiro per fornire qualche risposta, approfittando del permesso che ho preso oggi.

Velocemente do qualche risposta anche a te.
- i 14nm dovevano arrivare proprio in questo periodo, come ha correttamente riportato AceGranger. Sono stati spostati di 6 mesi, e le informazioni a riguardo riportavano la fine del 2014 per i primi prodotto, con la produzione in volumi per l'inizio del 2015. Come confermato proprio in questi giorni.
- su Atom vs ARM le chiacchiere lasciano il tempo che trovano. Se riporti dei benchmark, con annessi consumi, in cui sono confrontate entrambe le architetture, ne possiamo riparlare.
- continui a non avere chiaro il concetto di unità di elaborazione, core, coprocessore, e CPU. Oltre ad altre cose come SoC et similia, come ha riportato Ares17, col quale concordo.
- il confronto fra Kepler e KL l'hai tirato fuori soltanto tu, come ho già ampiamente dimostrato in precedenza.
- sei pregato di non riportare falsità su vendite sottocosto et similia. Se hai le prove, portale prove. Bonus != da sottocosto != dumping (che, ti ricordo, è proibito; e Intel ha già pagato abbastanza e non ha alcuna voglia di essere presa di mira nuovamente).

Riguardo al tema del thread, appena avrò un altro po' di tempo ti risponderò puntualmente. Sulle altre cose che hai tirato fuori nel frattempo, sono d'accordo con quanto hanno scritto Ace e Ares.

E adesso... a lavoro. Scusate per eventuali errori, ma non posso nemmeno rileggere il commento adesso.

Grazie per averlo ricordato. Avevo dimenticato questo, e il fatto che Volta fosse sparito.

Se per FPU intendiamo la classica unità di calcolo scalare che le CPU hanno avuto dalla notte dei tempi (prima come coprocessore esterno, poi integrato nel core), allora no: x87 (l'FPU degli x86) rimane inalterata da parecchio tempo ormai (se non ricordo male è stato soltanto una versione del Pentium 4, forse quello che portò le SSE3, ad aver effettuato qualche cambiamento, integrando una o due istruzioni per quest'unità di calcolo, una dozzina d'anni fa).

Per il resto è dai tempi delle SSE che ormai Intel, come pure le altre aziende, puntano tutto sulle unità vettoriali.

Quindi l'FPU x87 è presente in tutti i core x86 (inclusi quelli di Xeon Phi, ovviamente), ma risulta scarsamente utilizzata per questi motivi.

In realtà l'FPU x87 non esiste più "fisicamente" dai tempi del Pentium 4
http://www.hardwaresecrets.com/fullimage.php?image=2294

Le cpu x86 attuali implementato le istruzioni x86 e quelle vettoriali (SSEx, AVX, ecc.) decodificandole in differenti microOP (o sequenze di microOP) che vengono poi eseguite su unita floating point "generiche".
Nel caso del Pentium4 c'era un unita "floating point MOV" dedicata alle mov tra registri interni x87 e SSE ed alle store verso la meoria ed un unita "floating point ALU" che implementava le altre operazioni.
Ma non c'era una vera "unita FPU x87" ed un "unita FPU SSE".

Questo invece è l'Haswell:
http://www.hardwaresecrets.com/fullimage.php?image=55132

Il motivo è che un sommatore ad N*2 bit può fare anche due somme di N bit bloccando la propagazione del carry tra il bit N ed il bit (N +1).
Quindi un sommatore a 256bit (con circuiteria che blocca il carry in base ad un selettore di modalità di uso) puo eseguire in un ciclo 1 somma a 256 bit oppure 2 somme a 128bit, oppure 4 somme a 64bit, 8 somme a 32 bit, ecc. ecc.
Idem per i moltiplicatori (la moltiplicazione ad N bit viene eseguita come somma degli esponenti dei due operanti e come shift della mantissa di un operando seguita dalla moltiplicazione del risultato con l'altra mantissa), pure con essi con oppurtune modifiche ce bloccano a comando la propagazione dei carry nelle somme e degli shift si può riutilizzare la stessa unita per operazioni su più operandi più piccoli.
(N.B. il discorso è più complicato di come ho scritto sopra, ma spero che renda l'idea di base senza doverci scrivere sopra un trattato)

In realtà l'FPU x87 non esiste più "fisicamente" dai tempi del Pentium 4
http://www.hardwaresecrets.com/fullimage.php?image=2294

Questo mi sembrava di ricordarlo, ma non ero sicuro di aver capito bene.


(N.B. il discorso è più complicato di come ho scritto sopra, ma spero che renda l'idea di base senza doverci scrivere sopra un trattato)

E meno male che l'hai semplificato.
Aspetta un attimo che prendo un moment e rileggo.
:D

In realtà l'FPU x87 non esiste più "fisicamente" dai tempi del Pentium 4
http://www.hardwaresecrets.com/fullimage.php?image=2294

Le cpu x86 attuali implementato le istruzioni x86 e quelle vettoriali (SSEx, AVX, ecc.) decodificandole in differenti microOP (o sequenze di microOP) che vengono poi eseguite su unita floating point "generiche".
Nel caso del Pentium4 c'era un unita "floating point MOV" dedicata alle mov tra registri interni x87 e SSE ed alle store verso la meoria ed un unita "floating point ALU" che implementava le altre operazioni.
Ma non c'era una vera "unita FPU x87" ed un "unita FPU SSE".

Questo invece è l'Haswell:
http://www.hardwaresecrets.com/fullimage.php?image=55132

Il motivo è che un sommatore ad N*2 bit può fare anche due somme di N bit bloccando la propagazione del carry tra il bit N ed il bit (N +1).
Quindi un sommatore a 256bit (con circuiteria che blocca il carry in base ad un selettore di modalità di uso) puo eseguire in un ciclo 1 somma a 256 bit oppure 2 somme a 128bit, oppure 4 somme a 64bit, 8 somme a 32 bit, ecc. ecc.
Idem per i moltiplicatori (la moltiplicazione ad N bit viene eseguita come somma degli esponenti dei due operanti e come shift della mantissa di un operando seguita dalla moltiplicazione del risultato con l'altra mantissa), pure con essi con oppurtune modifiche ce bloccano a comando la propagazione dei carry nelle somme e degli shift si può riutilizzare la stessa unita per operazioni su più operandi più piccoli.
(N.B. il discorso è più complicato di come ho scritto sopra, ma spero che renda l'idea di base senza doverci scrivere sopra un trattato)
Verissimo, ma qui sei sceso di un gradino nel livello di astrazione. Io m'ero fermato all'ISA, senza scendere nel dettaglio riguardo alla microarchitettura (la particolare implementazione di un'architettura, per chi non lo sapesse).

Ma qualunque sia la microarchitettura, in ogni caso l'ISA è sempre presente e ha il suo peso in termini di transistor e consumo.

Nel caso di x87, se decidi di supportare quest'unità di calcolo devi prevedere:
- decoding delle istruzioni x87;
- generazione di u-op e/o di microcodice (a seconda dell'istruzione implementata);
- register file per gli 8 registri FPU e tre di controllo;
- implementazione delle varie operazioni da eseguire.

Quest'ultima è la parte che hai riportato tu e che può essere riciclata per buona parte da un'unità d'esecuzione che esegue calcoli in virgola mobile (e anche interi). Ma serve in ogni caso:
- adattare i risultati per implementare correttamente le operazioni con 80 bit di precisione;
- supportare le operazioni BCD;
- supportare varie istruzioni che non possono essere implementate utilizzando l'unità d'esecuzione condivisa.

E' ovvio che la parte più grossa è quella relativa ai calcoli veri e propri, e che può essere omessa dal computo delle risorse impiegate per implementare l'FPU x87, per cui il risparmio c'è ed è MOLTO consistente.

Però rimane la parte non coperta da ciò, che è sicuramente una piccola parte della torta, ma... va considerata.

Sull'argomento avevo scritto tempo fa un articolo a riguardo (http://www.appuntidigitali.it/17518/il-legacy-di-x86-x64-parte-3-fpu-x87/), che peraltro riportava anche il possibile uso dell'unità di esecuzione SIMD. ;)

Questo a ulteriore dimostrazione di quanto l'aspetto legacy sia decisamente sopravvalutato e frutto di informazioni gonfiate, essendo la comprensione dell'argomento un po' indigesta e complicata.
E Intel questo lo sa bene, perché il prossimo processo produttivo lo deve pagare con gli introiti del solo mercato desktop/server in forte contrazione
Una cosa al volo su questa grandissima bufala, che non si può proprio leggere.

Il mercato desktop si è sostanzialmente stabilizzato, non avendo più le grandi perdite di tempo fa.

Quello server (che fa parte dell'area business) è DA SEMPRE in crescita, e nell'ultimo quarto ha pure registrato un boom che ha portato Intel ad alzare nettamente le sue previsioni.

Io mi chiedo dove le vai a pescare queste balle, ma più che altro per quale motivo le riporti, non avendo interessi nel settore (o li hai?). Non so, ti piace raccontare falsità sperando che nessuno poi se ne accorga? Bah...

Una cosa al volo su questa grandissima bufala, che non si può proprio leggere.

Il mercato desktop si è sostanzialmente stabilizzato, non avendo più le grandi perdite di tempo fa.

Quello server (che fa parte dell'area business) è DA SEMPRE in crescita, e nell'ultimo quarto ha pure registrato un boom che ha portato Intel ad alzare nettamente le sue previsioni.

Io mi chiedo dove le vai a pescare queste balle, ma più che altro per quale motivo le riporti, non avendo interessi nel settore (o li hai?). Non so, ti piace raccontare falsità sperando che nessuno poi se ne accorga? Bah...

Io spero vivamente che lavori per nVidia, nel settore marketing. Altrimenti c'è solo da provare compassione.
Comunque in merito alla questione PP intel nella posizione di monopolista che si ritrova li fa uscire quando se li è già ripagati, in questo caso lo ha spostato di 6 mesi, tanto non ha bisogno di forzare i tempi. Comunque il nuovo PP ha un senso solo per il mobile (una MBA che faccia 16 ore di lavoro continuato non sarebbe male) visto che per i desktop non cambierà molto e per il mercato pro comunque erano previsti per il 2015-2016.

Io spero vivamente che lavori per nVidia, nel settore marketing. Altrimenti c'è solo da provare compassione.
Infatti. E' del tutto irrazionale sparare balle e menzogne soltanto per difendere la marca del cuore. Se ci fossero degli interessi, per quanto ritengo meschino ricorrere a questi "mezzi" (perché, in linea teorica, ci si dovrebbe attenere soltanto ai fatti e al proprio know-how), avrebbe una giustificazione. Ma fare figuracce soltanto per una questione pseudo-religiosa è del tutto privo di senso.
Comunque in merito alla questione PP intel nella posizione di monopolista che si ritrova
Non è l'unica fonderia esistente, ma a mio avviso è l'azienda che ha un vantaggio in quest'ambito rispetto alla concorrenza, in termini di velocità di adozione di nuovi processi produttivi e sperimentazione di qualche nuova tecnologia.
li fa uscire quando se li è già ripagati, in questo caso lo ha spostato di 6 mesi, tanto non ha bisogno di forzare i tempi.
In realtà in una situazione normale si dovrebbe cercare di sfruttare il nuovo processo produttivo perché più economico e, dunque, vantaggioso. Ma a volte s'incontrano problemi di resa o non c'è sufficiente richiesta per tenere impegnate le fabbriche.

Personalmente non ho alcuna informazione riguardo al nuovo processo a 14nm, perché al mio livello e per quel che faccio informazioni più dettagliate non ne passano. E comunque, anche se ne fossi a conoscenza, non potrei riportarle, trattandosi al 99,9999% di informazioni confidenziali (come minimo).

Per cui riporto soltanto le mie impressioni da utente comune che ha a disposizione le informazioni pubbliche che circolano per tutti.
Comunque il nuovo PP ha un senso solo per il mobile (una MBA che faccia 16 ore di lavoro continuato non sarebbe male) visto che per i desktop non cambierà molto e per il mercato pro comunque erano previsti per il 2015-2016.
Concordo. A mio avviso le priorità da seguire sono proprio queste. Mi spiace che non sia stato fatto prima, con Atom che per lungo tempo è stato relegato a utilizzare processi vecchi; probabilmente la situazione a livello di mercato sarebbe stata diversa se avesse privilegiato il mobile (anche perché su desktop e server è da parecchio tempo che non ci sono rivali).

Al solito, sono mie personalissime opinioni, che nulla hanno a che vedere con l'azienda. Forse è meglio che lo metta in firma, così evito ogni volta di riportarlo. ;)

Una nota su quanto avevo scritto prima riguardo al rapporto registri su core. Avevo riportato che 410 registri / core per Maxwell, e 32 registri / core per Xeon Phi. In realtà ogni core Xeon Phi ha 4 thread hardware, ognuno col proprio register set, per cui è chiaro che quel numero vada quadruplicato, arrivando a 128 registri per core. In ogni caso è meno di un terzo rispetto a Maxwell, ma la correzione era doverosa.

Ragazzi io non ho capito una mazza di quello che state parlando, ma volevo chiedere se con questi benedetti xeon phi e knight Landing si possono o si potranno fare rendering 3d (in openCL si possono utilizzare giusto?) Aldilà delle specifiche la cosa interessante è che hanno un prezzo in linea con schede quadro, tesla o firepro di fascia alta.

Sì, è in grado eseguire rendering 3D (ne parlava anche AceGranger prima). Supporta OpenCL, come pure OpenMP, MPI, più altre tecnologie.
Non c'è molto da dire se nonché non riusciamo a sintonizzarci sulla stessa frequenza comunicativa. Ti sei appigliato come un polipo a una definizione infelice "sull'unita scalare" dell'archiettura CPU+GPU che per me è la CPU, quella che sta fuori dal die della GPU, quella che esegue le istruzioni in maniera sequenziale (appunto scalare), non le unità interne agli SMM.
Prendi tutto il mio commento precedente e sostituisci le parole "unità scalare" riferita all'architettura GPU+CPU con il "core delle CPU a cui la GPU è collegata tramite bus PCI-e" e vedi se ti torna tutto il ragionamento. Così come per me l'unità scalare (o CPU) all'interno di KC/KL è la parte che esegue codice x86 collegata alla unità vettoriale.
Se non riusciamo a "sintonizzarci", come dici tu, è perché io adotto la terminologia in uso nella letteratura informatica, chiamando le cose col loro nome, mentre tu... no. E, purtroppo, continui a farlo anche adesso.

E' chiaro che non ha idea di cosa stiamo parlando, e mi chiedo perché continui a insistere su questo fronte anziché documentarti e studiare come stiano realmente le cose prima di cimentarti sull'argomento.

Per questo motivo è inaccettabile che tu scriva "per me": su questioni tecniche si adotta il linguaggio del caso; non un linguaggio a caso. Altrimenti non ci si capisce, mentre scopo della lingua è poter instaurare una comunicazione in cui si possa veicolare informazione (e non rumore).

Esempio pratico: no, la CPU NON è l'unità scalare all'interno di Xeon Phi.

Come puoi discutere su queste se ti mancano proprio le basi? Bah...
Infine per la questione del confronto con i prodotti vecchi della concorrenza, lo hai fatto perché considerando Maxwell hai bellamente "dimenticato" che Maxwell verrà con core ARM all'interno dello stesso die
Mi sa che hai confuso le informazioni a riguardo. E' Denver, basato su ARMv8, che integrerà un core Maxwell nello stesso die, e non il viceversa. Sarà, insomma, simile a Tegra e alle APU di AMD, con CPU e GPU sullo stesso die, ma i due elementi rimarranno distinti; "semplicemente" sarà una CPU nuova di pacca, sviluppata interamente da nVidia anziché ricorrere al design standard di ARM.
del cluster di unità di calcolo vettoriale e ne potrà condividere le risorse senza passare dal suddetto bus stretto,
Da quel che si sa finora, potrà condividere l'accesso al memory controller. Che è già una buona cosa, sia chiaro, ma non è certo una rivoluzione, visto che è roba che altri fanno già da anni (anche Intel con le GPU integrate nel die delle sue CPU, da tempo immemore).
quando prima (cioè con Kepler) ogni gestione di un flusso di istruzioni sequanziali è un problema da esegire su GPU ed eseguire un branch del codice comporta una penalità non indifferente. Con un core in grado di eseguire codice sequenziale a fianco del cluster vettoriale usato come "semplice coprocessore" i giochi potrebbero cambiare.
Se mi spieghi tutto quello che hai scritto qui mi fai un favore, perché non è affatto chiaro. Quindi:
- cos'è la gestione del flusso di istruzioni "sequenziali";
- cosa sarebbe la penalità causata dal branch e perché avverrebbe;
- cos'è il core che esegue "codice sequenziale";
- cosa intendi per "cluster vettoriale";
- in che modo questi due elementi sarebbero collegati e interagirebbero.

A naso direi che quando parli di "istruzioni sequenziali" e di "codice sequenziale" ti stai riferendo all'unità scalare, ma messa così è un pastrocchio che non si può proprio vedere, visto che un core può eseguire codice non sequenziale. Anzi, diciamo che un core general-purpose è uno specialista in questo campo, visto che mediamente il 10% delle istruzioni che esegue sono... salti (che, dunque, interrompono l'esecuzione sequenziale delle istruzioni).

Questo a ulteriore dimostrazione che continui a rantolare frasi senza avere la minima idea di quello di cui stai parlando.
Anche nvidia può costruire una unità di calcolo indipendente come lo sarà KL perché al suo interno ci sono delle CPU in grado di far girare il normale flusso di codice "seriale" e delegare i calcoli vettoriali agli SMM il tutto condividendo la memoria.
Può? Certamente, ne ha le capacità, ma... non l'ha ancora fatto. Questo è quello che magari vorresti tu, dopo la discussione che abbiamo avuto, ma rimane soltanto un sogno, perché non c'è nessun prodotto concreto, ma nemmeno in roadmap, a riguardo.

Poi adesso hai tirato fuori un altro dei tuoi neologismi tecnici che derivano dal pasticciare parole e concetti che sconosci. Il "codice seriale" di cui parli può essere quello che identifica un serial killer, o la licenza di Windows, oppure la spedizione di un pacco, ecc. ma non ha nulla a che vedere con l'esecuzione di istruzioni...
Tu invece continui a sostenere che questa è una prerogativa di KL che si permette di poter condividere le risorse tra il core "scalare" (il pezzo che decodifica ed esegue istruzioni x86 per internderci, che altrimenti parti ancora per la tangente) e l'unità AVX.
Non è che lo sostengo io: sono i FATTI a dimostrarlo, a prescindere dalle tue fantasie. Ma, al solito, puoi sempre dimostrarmi il contrario.

Per il resto continuano le tue tecnoballe:
- Xeon Phi non ha l'unità AVX
- la decodifica delle istruzioni non viene effettuata dal core scalare
- il core scalare esiste nelle GPU, ma non nei sistemi x86 (Xeon Phi incluso)

Visto che sarei partito per la tangente, cortesemente riportami sulla strada. Mi faresti vedere cosa integra Xeon Phi, cos'è & come funziona un core scalare, chi si occupa & come avviene la decodifica delle istruzioni in un sistema x86?

Sì, lo so, è un'altra domanda. Una delle tante che, "stranamente", non troverà risposta da parte tua. Cercherò di farmene una ragione...
Come è fatta una GPU lo so bene.
Uhhhh. Come no. Ne capisci di GPU quanto io di bricolage. E io NON sono un esperto di GPU, per cui figuriamoci cosa ne può pensare di te uno che lavora nel campo...

Anche in questo commento non hai risparmiato frottole, infatti.
Se ti fossi fermato a cercare di capire i termini che ho usato (magari non propriamente, per la cui cosa mi scuso) non saresti partito per una filippica intorno alla definizione ma ti saresti concentrato di più a discutere sul merito delle cose.
Ma se sbagli i termini E (congiunzione) nemmeno la descrizione che fornisci corrisponde a qualcosa di concreto, come pensi che possa continuare questa discussione, se non finendo in farsa (complice, in ogni caso, i tuoi toni non proprio concilianti)?

Visto che a parole sei un disastro, la prossima volta usa i disegnini, modello scuola elementare: "Ecco, vedi, questo è un core scalare, che fa questo e quest'altro, è collegato a quest'altro pezzo in questo modo, e funziona così (magari con una bella animazione)".

Così vediamo se finalmente si capisce qualcosa, oppure anche con quelli trasparirà il tuo digiuno in materia.
Comprenderai che le due architetture hanno approcci tremendamente differenti
Lapalissiano.
e che le GPU scalano meglio in termini di quantità di unità di calcolo integrabili.
E questo dove l'avresti letto? Dimostralo pure. Mi sono permesso di sottolineare la parte più importante.
Il 3x, 4x del GK107 è estratto dalle prove eseguite da Anantech della 750Ti. Vedi come si comporta rispetto al GK104.
Eccola qui (http://www.anandtech.com/show/7764/the-nvidia-geforce-gtx-750-ti-and-gtx-750-review-maxwell/3). Dove li vedi 3x & 4x?

Ma veniamo, in particolare, al campo in cui stiamo discutendo in questo thread. Ecco qui (http://www.anandtech.com/show/7764/the-nvidia-geforce-gtx-750-ti-and-gtx-750-review-maxwell/21). C'è UN solo test in cui la 750 Ti mostra poco più di 3 volte le prestazioni della 650 Ti. Considerando le versioni "plain" (non Ti), il vantaggio è mediatamente maggiore, ma c'è sempre UN solo test in cui la 750 è 4 volte (quasi 5) le prestazioni della 650.

E in tutto ciò c'è da tenere in conto che Maxwell ha un die del 25% più grande rispetto a Kepler. Quindi l'aumento di prestazioni è legato anche a questo.

Ovviamente l'incremento di prestazioni c'è, ma non puoi prendere i picchi delle rispettive schede per poter affermare di essere davanti a prestazioni di 3 o 4 volte il predecessore, perché stai falsificando la realtà.
Per la questione KL andrà meglio perché usa core Saltwell invece che i vecchi Pentium è tutta da dimostrare. Come detto la potenza di calcolo la fa l'unità vettoriale, non quella scalare.
T'avevo già scritto che KL avrà TRE VOLTE (adesso l'ho pure evidenziato, eh!) la capacità di calcolo in virgola mobile rispetto a KC. Considerato che le uniche due unità di calcolo che lavorano in floating point sono la vecchia FPU x87 e l'unità SIMD, indovina da dove arriva tutta questa potenza calcolo. Dall'unità scalare? Acqua. Da tutte le parti...
E no, non ho adorazione per nvidia o ARM. La prima è l'unica per ora sta cercando di innovare il mercato usando tecnologia fino a ieri "aliena" all'uso che oggi si sta tentando di fare.
Hai dimenticato AMD, che è messa anche meglio da questo punto di vista. Ma sappiamo che AMD non rientra fra le tue grazie...

A parte questo, nVidia è stata costretta a riciclarsi in questo mercato perché quello delle GPU è in calo, e non può competere nel mercato x86, visto che non ha nessuna licenza per produrre chip basati su quest'architettura. Anzi, tempo fa perse anche la licenza per produrre chipset per Intel, per cui è stata sostanzialmente tagliata fuori (il mercato di AMD era/è troppo piccolo e troppo competitivo).
Ma se ci fosse anche AMD con le sue GPU sarebbe la stessa cosa, dato che architetturalmente sono molto simili.
A parte che c'è, e in ambito GPGPU è sicuramente superiore a nVidia, ma la sua architettura è abbastanza diversa da quella di nVidia. A meno che non parli del fatto che sono entrambe GPU, con annesse unità di calcolo dedicate allo scopo (la "GPU-tax" che continui a ignorare sistematicamente; ma magari un giorno mi farei vedere quant'è utile il Polymorph engine per calcolare matrici da 10000x10000).
AMD è già più avanti di nvidia con le sue APU, soluzione simile che nvidia realizzerà con project Denver (cioè avere finalmente una CPU che collabora con il cluster vettoriale localmente e non diviso da un bus strettissimo,
Questo da cosa l'avresti dedotto? Al momento tutte le informazioni a riguardo parlando della GPU che risulta integrata nello stesso die del processore, ma non c'è nulla riguardo a una fusione dei due diversi elementi (core di CPU che può comunicare direttamente con un cluster della GPU). Se hai informazioni a riguardo, portale pure, perché sarebbe una novità.
che è il cancello che Intel si è costruita per le sue CPU se non era chiaro prima).
Ma di che cancello parli? Questa è una soluzione utilizzata anche da altri in passato. Non era e non è, dunque, un'esclusiva di Intel.
Il problema di AMD è che nel campo professionale e come supporto allo sviluppo SW vale zero, tant'è che è un peccato che le sue GPU come Tahiti o Hawaii stiano solo nelle schede consumer (il numero delle FirePro che vende sono risibili e non stanno all'interno di nessun super computer).
Ovviamente non poteva mancare la stoccata ad AMD per sminuirne il valore...

Comunque se i driver grafici di AMD non sono lo stato dell'arte, almeno in ambito GPGPU-computing se la cava molto bene (e mi pare sia molto apprezzata). O vuoi ignorare / ribaltare anche questo?
ARM semplicemente ha dimostrato in diversi anni di non aver sbagliato un colpo e si ritrova con una archiettura molto più efficiente di quel mattone di x86 che ha fermato il progresso tecnologico per anni.
Efficiente per cosa? Per i consumi? Intel ha già colmato il divario, e persino le architetture "desktop" hanno ormai consumi talmente bassi da essere integrati in tablet et similia.

E a livello prestazionale non c'è storia.

Poi dovresti spiegarmi perché x86 sarebbe un mattone, perché avrebbe fermato il progresso. Sono le tue solite fantasie, o ti basi su FATTI concreti? Riporta pure.
Sarei contento (anzi stra contento) che assieme a ARM ci fosse anche MIPS o qualsiasi altra cosa che dimostra (se ce ne fosse ancora bisogno) che l'approccio monolitico di Intel del mega super huber core general purpose che vuole fare tutto da solo non è stata la soluzione migliore e che molto si sarebbe già potuto fare se il monopolio non avesse fatto la sua parte.
Continui a parlare di cose a te del tutto aliene. In primis non è mai esistito un monopolio, definizione alla mano.

Secondo, e più importante, il "megacore general purpose che vuole fare tutto da solo" è proprio quello che hanno fatto tutti i produttori di processori, ARM e MIPS inclusi. In particolare ARM è ben nota per aver aggiunto numerose estensioni (bada bene: ESTENSIONI, e non COPROCESSORI) alla sua architettura per migliorare le prestazioni in determinati ambiti (DSP, Java, virtual machine in generale).

Comunque scendi pure nel dettaglio. Esplicita pure cosa intendi con quella roba che hai scritto, e prendi pure qualunque architettura ti aggradi, ARM, MIPS, PowerPC, ecc. ecc.. Così almeno cerchiamo di capire di cosa stai parlando, SE stai parlando di qualcosa di concreto, visto che a me suonano come le classiche leggende metropolitane di mio cuggggggino che stai riportando senza avere la minima cognizione sull'argomento.

Io sono più di 32 anni che mi occupo di architetture degli elaboratori, ho scritto anche tanti articoli in merito, e sarò ben felice di vivisezionare quello che scriverai, mettendo alla luce le solite balle che ami raccontare.
Apprezzo ARM (come sarebbe potuto essere il PowerPC, MIPS, Spark, cippalippa) perché oggi finalmente si vede la luce al fondo del tunnel Wintel che ci siamo dovuto sorbire per quasi 30 anni.
Nessuno ti ha obbligato.

A parte questo, se Intel ha fatto fuori tante architetture "rinomate" è proprio perché è riuscita a colmare il gap coi RISC in termini prestazionali, che alla fine si sono rivelati una bolla.
Se vuoi ti chiarisco meglio la cosa, così mi sarai più amico di prima: Intel con il suo approccio general purpose spreca transistor/energia ma con PP più avanzato ha rotto le palle. Il progresso si fa in altro modo. E oggi si vede la possibilità di realizzarlo da parte di altri che le stanno erodendo piano piano il mercato.
Adesso dal "megacore" passi al processo produttivo, e vomiti veleno su Intel perché è in vantaggio in questo campo. Beh, questo vantaggio l'ha realizzato a colpi di investimenti e ricerca, non per opera dello spirito santo.

Adesso visto che questa dovrebbe essere una discussione tecnica, DIMOSTRAMI cosa c'è che non ti piace dell'approccio general purpose di Intel alla computazione. Scendi pure nei dettagli quanto vuoi, io non ho problemi a seguirti.

E poi DIMOSTRAMI cosa e come si possa fare di meglio. Ovviamente sempre tecnicamente, e non con vuote parole e slogan da fan.
Riguardo al RoadRunner non hai capito una cosa: tutto il mostro consumava 1/3 di un equivalente PC basato esclusivamente su x86. La parte x86 nel RoadRunner, oltre che essere molto più inefficiente di quella di Intel (gli Opteron di AMD non sono certo famosi per la loro efficienza energetica rispetto agli Xeon Intel) è usata solo per la gestione e la connessione con il resto del sistema e non partecipa alla generazione della potenza di calcolo. Fai tu una estrapolazione per vedere quanto era efficiente la soluzione IBM rispetto a quella Intel al netto dell'energia parassita degli Opteron.
Ancora con quest'energia "parassita"? Ti ho chiesto già due volte cosa fosse, ma "stranamente" eviti accuratamente di rispondere ogni volta.

RoadRunner aveva bisogno degli Opteron perché da solo non sarebbe stato in grado di erogare tutta quella potenza di calcolo, senza qualcuno che gli fornisse i dati da processare. E non si tratta di una questione di poco conto, visto che OGNI core PowerCell era collegato a UN core x86.

Nel mondo reale per fare C = A + B non basta avere le unità di esecuzione che effettuino fisicamente il calcolo, ma serve un apparato, un'infrastruttura, affinché tutto ciò avvenga.

E questo è l'errore che commetti: guardare soltanto ai numeri senza soffermarti all'insieme che rende possibile tutto ciò. Non meno importante è il COME l'insieme debba venir utilizzato per sfruttarne adeguatamente le capacità in ottica degli obiettivi da raggiungere.

Per fare un esempio concreto, il PowerCell usato in RoadRunner integra al suo interno gli 8 SPU che eseguono i massicci calcoli vettoriali. Ma integra anche un core PPE (basato su architettura PowerPC) "general-purpose", che sulla carta dovrebbe essere perfettamente in grado di eseguire i compiti di coordinamento di tutta la baracca. Tra l'altro PowerPC è una delle architetture che hai snocciolato prima e messo in contrapposizione a x86; dunque sarebbe dovuto essere una soluzione "migliore", no? L'hai detto pure tu... e dovremmo crederti sulla parola, visto che sei un esperto in materia.
Invece chi ha progettato RoadRunner (che è IBM. Non un'azienda qualsiasi, e tra l'altro proprio il padre di POWER & PowerPC) ha deciso che fosse meglio affiancargli un core x86. Forse perché quegli ingegneri sono pragmatici e non sognatori...
Per quanto riguarda il fatto che il 14nm siano in tabella di marcia... suvvia, chi stai prendendo in giro? I 14nm dovevano essere pronti l'anno scorso e costare 6 miliardi in meno.
Oltrettutto avrebbero dovuto coprire una produzione maggiore vista la nuova fabbrica ora designata come in disuso ancora prima di essere partita. Nel secondo semestre del 2015 i 16nm Finfet dovrebbero essere pronti (si spera).
Se non vuoi credere che nvidia farà un chip Maxwell da 12/14 miliardi di transistor a 28nm, non c'è altro che pensare che la mattonella Maxwell la vedremo a 16nm.
Ma la questione è un'altra e lo stai chiaramente sottolineando: Intel campa ancora perché ha un processo produttivo migliore della concorrenza, non perché sforni dei prodotti che siano migliori nella parte funzionale. E la sua fortuna continuerà fintanto che questo processo produttivo rimarrà avanti agli altri. Cosa che, vista le vicessitudini dei 14nm e i proventi che la concorrenza sta avendo dalla produzione di miliardi di SoC mobile, non è destinata a durare a lungo.
Su questo ho già risposto e concordo quanto scritto da Ace e Ares. Aggiungo soltanto che se hai un posto in cui ti rifornisci di sfere di cristallo fammelo sapere, che ne compro qualcuna pure io...

Per il resto continui a far fede al nick che ti sei scelto su questo forum. Non soltanto dimostri di non conoscere gli argomenti di cui parli, ma affronti la discussione con l'arroganza tipica di un talebano che deve difendere la fede costituita, addirittura immolandosi per la nobile causa. Perché soltanto un folle sparerebbe balle e falsità senza aver nulla di concreto in cambio, se non accumulare figuracce (ma ti va bene perché sei coperto dall'anonimato del nick).

Hai deciso nuovamente di partire con le tue frecciatine e i toni ruvidi che ti contraddistinguono, per cui, nuovamente, ricevi delle risposte adeguate al tuo incivile e ben poco conciliante modus operandi.
D'altra parte se provi gusto a farti umiliare pubblicamente, chi sono io per impedirtelo?

E se avessi la malsana idea di continuare in questa discussione, sappi che la prossima replica sarà "soltanto" una racconta di TUTTE le cose a cui hai sistematicamente evitato di rispondere. "Ccà nisciuno è fesso". Non credere che non mi accorga di tutte le parti che tagli perché non sei in grado di argomentare o che ti sono scomode. Se non hai nemmeno le basi per discutere, evita di intervenire e vedi di spendere il tuo tempo studiando e facendoti un'adeguata cultura in materia, che è meglio.

A parte questo, se Intel ha fatto fuori tante architetture "rinomate" è proprio perché è riuscita a colmare il gap coi RISC in termini prestazionali, che alla fine si sono rivelati una bolla.

Non esattamente, ha colmato il gap prestazionale DOPO averli di fatto estromessi dai settori in cui gli x86 erano presenti in forze.

Il vero vantaggio degli x86 era la retrocompatibilità a livello di codice binario con tutto il software scritto in precedenza per i modelli precedenti
(basta pensare a come i 286 ed i 386 abbiano passato la maggior parte della loro vita ad eseguire codice 8086), per una nuova cpu x86 per avere successo era sufficiente che avesse maggiori prestazioni di quella precedente quando eseguiva codice "vecchio", non importava se le cpu RISC avevano una potenza di calcolo da 2 a 4 volte superiore.

Inoltre gli x86 avevano il vantaggio di avere tutto un ecosistema hardware (produttori di periferiche, chip, e chipset) costruite progressivamente attorno ad essi che semplificava enormemente la produzione di computer "pc compatibili" basati su di essi.

Tutto questo nel lungo periodo in cui i pc basati su x86 guadagnavano sempre maggiori quote di mercato perche su essi girava tutto il software per pc "da ufficio" che ormai era diventato lo standard di fatto (prima prodotti come Wordperfect e LOTUS 123, poi la suite Microsoft office) e questo contribuiva anche a renderli più economici di altre alternative.

POI gli x86 hanno cominciato ad espandersi seriamente pure in settori tipo i server di fascia alta ecc. perche Intel aveva disponibilità di cassa ed economie di scala che i concorrenti potevano solo sognarsi (e senpre con il vantaggio della retrocompatibilità a livello di codice binario con un sacco di software già sviluppato).

Infatti Intel ha avuto (ed ha) problemi ad espandersi in settori in cui la retrocompatibilità x86 non è sufficientemente rilevante ed in cui sono importanti aspetti architetturali e/o commerciali che non sono il forte degli x86.

Ad esempio nel settore degli smartphone e dei tablet è molto più importante avere il SoC "giusto" in termini di costi/prestazioni/consumi, non il SoC più sbrilluccicante del momento.

Per buona parte sono d'accordo, ma riguardo a server, workstation, e supercomputer la compatibilità x86 non era affatto un valore aggiunto. Inoltre aziende del calibro di IBM, HP, Sun, e DEC non avevano proprio nulla da invidiare a Intel.
Eppure Intel, come pure AMD (ricordiamo che con gli Opteron ha avuto un enorme successo), è riuscita a imporsi anche in questi mercati. Ed erano anche mercati in cui la compatibilità binaria con le rispettive architetture era molto importanti (vedi IBM, HP, Sun, DEC, e mettiamoci pure la gloriosa SGI, che era basata su MIPS, e con software come Maya che girava su queste macchine).
I numeri hanno dimostrato che verso la fine degli anni '90 gli x86 avevano ormai raggiunto i RISC più rinomati in termini puramente prestazionali, rendendoli non soltanto appetibili, ma addirittura preferibili.
I RISC hanno dovuto, quindi, ripiegare in ambito embedded per continuare a sopravvivere, perché lì erano irraggiungibili da x86 in termini di spazio su die e consumi. All'epoca. Adesso anche quel mercato è attaccabile.

Per buona parte sono d'accordo, ma riguardo a server, workstation, e supercomputer la compatibilità x86 non era affatto un valore aggiunto. Inoltre aziende del calibro di IBM, HP, Sun, e DEC non avevano proprio nulla da invidiare a Intel.

Lo era perche fu attuato un attacco "dal basso", in cui roba che prima girava su pc poi veniva fatta girare su workstation e su server di fascia medio-bassa basati su x86 o su cluster Beowulf.
Le ultime workstation Alpha di DEC (cpu a 64bit) non a caso venivano proposte con Windows NT (per Alpha, in modalita a 32bit) e con emulazione x86 integrata.


I numeri hanno dimostrato che verso la fine degli anni '90 gli x86 avevano ormai raggiunto i RISC più rinomati in termini puramente prestazionali, rendendoli non soltanto appetibili, ma addirittura preferibili.
I RISC hanno dovuto, quindi, ripiegare in ambito embedded per continuare a sopravvivere, perché lì erano irraggiungibili da x86 in termini di spazio su die e consumi. All'epoca. Adesso anche quel mercato è attaccabile.

Verso la fine degli anni '90 c'era Intel che dal 1995 aveva stretto un alleanza con HP riguardo Itanium (facendo fuori l'architettura RISC di HP) e che poi si è tirata dentro pure SGI (buttando definitivamente fuori dal settore server le cpu MIPS).
Nonostante questo nei primi anni 2000, Alpha ormai di fatto "morta", con un semplice shrink e con un PP inferiore a quello già in uso sugli x86, aveva ancora maggior potenza di calcolo degli Itanium appena usciti e degli x86.
Mentre IBM aveva ormai da tempo puntato sul settore embedded per quel che riguardava i PowerPC e si era barricata nella fascia alta sei server con i POWER.

Ad esempio nel settore degli smartphone e dei tablet è molto più importante avere il SoC "giusto" in termini di costi/prestazioni/consumi, non il SoC più sbrilluccicante del momento.

Si bè, ma li non è che non c'è perchè l'architettura X86 non va bene, ma per il semplice fatto che sono stati miopi e i tablet gli sono esplosi sotto i loro occhi senza avere nulla in mano.

I vecchi Atom non erano pensati per quegli ambiti, sono corsi ai ripari con delle versioni modificate , ma va bè erano quello che erano, gli attuali Atom invece sono arrivati proprio per cercare di sfondare nel mercato degli ultra-trasportabili e smartphone e per ora sembrerebbero essere degli ottimi prodotti;

La roadmap Atom è stata accellerata per rimediare all'errore, ora vedremo le prossime versioni come saranno.