[cdimauro]

Originariamente inviato da CrapaDiLegno

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/blo...2-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)...