Knights Landing è la futura GPU Intel per il calcolo parallelo

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.

"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).

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.

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).

Questo, come dicevo prima, non serve a KL, che ha già "tutto incluso".

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).

Anche le GPU integrano sempre più core.

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).

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.

Non mi è chiara questa parte. Potresti specificare meglio, cortesemente?

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...

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.

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/bl...12-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)...

Pronti via siamo già partiti con il piede sbagliato. Migliore è scritto lì. Flops/W.


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




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.


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.


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.


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


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.


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.


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.


Con l'architettura KL ogni impatto ce l'hai nella coppia CPU+SIMD. Non è che questi parlino "gratis per volere del Signore".


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à.

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

Quando l'inutilità comincia a fare la sua presenza...

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?

Vedi sopra.

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.

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.

Al contrario: è la chiave di volta per ottenere le migliori prestazioni. Vedi sopra.

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.

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.

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, 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 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.

Cioé? Potresti chiarire questa parte, cortesemente?

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.

Potresti chiarire anche questa parte?

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...

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.

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.

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 (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.

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.

Infatti era così potente che Sony ha deciso di rimpiazzarlo con una CPU x86 nella PS4.

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à.

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.

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à.

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...

Ma non lo dico mica io. Puoi chiedere anche a Tim Sweeney cosa ne pensa. Sempre se conosci il personaggio in questione.

Forse perché hanno architetture RISC?

AVX-512 sì. Ma potrebbero realizzare altre unità SIMD con concetti simili. SE fossero integrabili con la loro architettura RISC.

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.

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.

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.

Infatti sono talmente separati che l'unità scalare di Maxwell (e predecessori), l'SFU, si trova appiccicata a 4 CUDA core...

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.

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...

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.

Ciò non ti ha impedito di scrivere nuovamente un bel papiro: evidentemente anche questa discussione è importante per te.

Omettendo di analizzare TUTTI i fatti. Questa parte mancava.

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.

E adesso comincia il valzer delle falsità, mistificazioni, e fallacie logiche con annesso attacco personale.

Cominciamo a smontare le menzogne.
Da qui: "Il risultato di Xeon Phi è decisamente scadente."
Da qui: "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: "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: "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. Tipico di chi non è in grado di sostenere una discussione rimanendo sul piano dei fatti e delle argomentazioni.

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...

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?

Puoi sempre dimostrarlo: i miei commenti sono lì, e aspettano te per essere smontati...

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.

Allora non partecipare: non te lo prescrive il medico di stare qui quando hai pure cose più importanti da fare.

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...

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...

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.

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...

Altro attacco ad hominem circostanziale...

E un'altra falsità. Si vede che sei particolarmente in vena, non avendo altro a tua disposizione.

Ma ne parlo meglio dopo.

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.

Altra menzogna, come dicevo sopra. KL l'ho messo a confronto con Maxwell, e Kepler non l'ho mai confrontato con KL.

Ecco qui 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.

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...

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.

Diciamo che finora, sarà magari complice proprio la veneranda età, più che fare 2 + 2 ti sei dato molto da fare con la fantasia...

Allora non avrai difficoltà a riportarli nel thread di cui sopra, in modo da confrontarli coi numeri che ho già riportato.

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.

Questi problemi sono comuni a KC, Kepler, e in generale a qualunque scheda che si trova collegata alla CPU tramite PCI-Express.

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.

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.

Quali sarebbero questi cancelli? Non è chiaro il riferimento.

Veramente è proprio quello che ha fatto con 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'è...

Non può dialogare "liberamente" come KL. Ma, come già detto, non te lo rispiego di nuovo: ho finito le cartucce.

Ma infatti, e come già detto anche in precedenza, non ho nulla da dire su questo: è certamente un miglioramento per nVidia.

Ecco, se non sai perché scrivi?

Su questo ho già dimostrato prima che hai raccontato un'altra falsità.

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?

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...

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...

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...

Ecco, se magari riportassi quand'è che avrei espresso qualcosa del genere, mi faresti un favore: almeno ci sarà qualcosa di concreto di cui parlare.

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.

Fammi vedere in che modo lo "annullerebbe". Riporta pure, non ti fare problemi: io sono qui che aspetto di leggere queste meraviglie tecnologiche.

Lapalissiano.

Questo 3 / 4x dov'è che l'hai letto? Riporta pure.

Da 28 a 16nm ci dovrebbe essere ben più di un raddoppio.

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é...

Lo credo bene, visto che hai ampiamente dimostrato di non averne conoscenza.

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.

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...

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?

Peccato che proprio RoadRunner è basato anche su x86 (Opteron di AMD). Vedi sopra il link...

Visto il contenuto, è stato tempo perso: avresti fatto meglio a impiegarlo per cose "più interessanti".

Grazie per avermi dato il permesso...

Detto da uno che non sa distinguere un coprocessore esterno da un'unità di calcolo integrata, lo prendo come un complimento.

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: "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.

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...

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.

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:
[CODE]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 !!![/CODE]
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...

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
Link ad immagine (click per visualizzarla)

NUOVA
Link ad immagine (click per visualizzarla)