Knights Landing è la futura GPU Intel per il calcolo parallelo

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

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.

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.

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

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

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

Funziona come uno Xeon, ma è massicciamente orientato al calcolo vettoriale e parallelo, mentre lo Xeon è più "general purpose".

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.

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

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.

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.

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

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.

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.

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)