Knights Landing è la futura GPU Intel per il calcolo parallelo

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



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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

Lapalissiano.

E questo dove l'avresti letto? Dimostralo pure. Mi sono permesso di sottolineare la parte più importante.

Eccola qui. Dove li vedi 3x & 4x?

Ma veniamo, in particolare, al campo in cui stiamo discutendo in questo thread. Ecco qui. 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à.

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

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

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

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

Ma di che cancello parli? Questa è una soluzione utilizzata anche da altri in passato. Non era e non è, dunque, un'esclusiva di Intel.

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?

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.

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.

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.

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.

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

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.

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.

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.



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.

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.