Intel Xeon Phi ufficialmente al debutto: schede x86 per GPU Computing

[jappilas]

Originariamente inviato da lucusta

..no, aspetta, almeno X87 lo sono, se no sarebbero derivati dal 486!

ricontrollato... ricordavo male, my fault
in effetti ha due pipeline, una con ALU normale e una con ALU intera/ SIMD /FP X87 appunto..

in questo documento sembra che sia appunto un x86 e non un x86-64:

su quello sono perplesso anch' io, avendo la/e scheda/e da 8 GB di memoria GDDR5 a salire, come sarebbe indirizzata?

[AleLinuxBSD]

An Overview of Programming for Intel® Xeon® processors and Intel® Xeon Phi™ coprocessors
Per approfondire un po' l'argomento.

[cdimauro]

Si tratta di core a 64 bit.
D'altra parte le nuove estensioni SIMD fanno utilizzo di un opcode (quello dell'istruzione BOUND) rimosso da AMD da x64, adesso utilizzato come prefisso per quasi tutte le nuove istruzioni.
Viene utilizzato anche il prefisso introdotto dalle estensioni AVX per la manipolazione degli 8 nuovi registri di maschera (k0..7).

Si tratta di core simili a quelli di Atom, anch'essi derivati (per lo meno concettualmente) dal Pentium, quindi in-order, ma con la caratteristica di poter eseguire un'istruzione "scalare" (general-purpose) e una vettoriale (LNI) per ciclo di clock (le vector store, però, vengono eseguite dalla pipeline "scalare").

Non si tratta di un progetto simile alle GPU. Hanno provato, con Larrabee, a competere in questo campo, e hanno fallito.
Successivamente, e questo è finalmente il prodotto commercializzato, hanno deciso di modificarlo per puntare al GPGPU Computing, verso il quale direi che ci siano ottime prospettive.

[gnappoman]

.....veramente.... Intel ha da almeno 10 anni la tecnologia per fare cose come questa, solo che puoi permetterti di aspettare se sei l' incontrastato leader di mercato e fai pagare una cpu X volte tanto la sua versione più economica, identica all'altra ma con qualche feature deliberatamente bloccata....
Stesso discorso vale per Nvidia e AMD.
CI vediamo tra 2 anni....
Il futuro è ARM.

[cdimauro]

Fammi un fischio quando ARM presenterà una soluzione comparabile/competitiva con questa di Intel...

[PaulGuru]

Originariamente inviato da cdimauro

Fammi un fischio quando ARM presenterà una soluzione comparabile/competitiva con questa di Intel...

Parlano tutti di ARM ma non ha le risorse di Intel.

[cdimauro]

Nemmeno AMD le aveva, eppure ha tirato fuori tanti bei processori: K5, K6, Athlon, per non parlare poi della nuova architettura a 64 bit x64 (ex AMD64) e della linea di processori server Opteron.

ARM ha notevoli risorse (credo più di AMD negli ultimi anni), anche perché si è dedicata interamente alla progettazione delle CPU, lasciando ai partner/client l'implementazione ed eventuale personalizzazione dei core.

Ma il punto è che ARM ha sposato da sempre la filosofia RISC, tranne per soluzioni come Thumb e, soprattutto, Thumb-2, che sono a tutti gli effetti dei progetti CISC (hanno opcode a lunghezza variabile, caratteristica che li ha sempre distinti dai RISC).

Mentre Intel (e AMD) lavorano da tantissimo tempo con x86, che è un'architettura CISC. Per quanto possa essere "brutta" e con tutte le problematiche "legacy" che si porta dietro (ho scritto parecchi articoli solo per questo, di recente), ha il vantaggio di possedere una codifica degli opcode a lunghezza variabile (oltre a operazioni che possono indirizzare direttamente la memoria, con modalità d'indirizzamento complesse) che le ha consentito di sopravvivere e, alla fine, dominare sui RISC, grazie alle notevoli prestazioni.

E' questa flessibilità che le ha consentito di mettere in piedi progetti come questo (Knights Corner) sulla base della precedente Larrabee, e che altre architetture RISC non si possono permettere (a meno di abbandonare la macrofamiglia RISC e abbracciare quella CISC).

Infatti se andate a controllare nel manuale dell'architettura, potete vedere che le nuove istruzioni fanno uso di un "mega prefisso" di 4 byte (l'ex opcode BOUND, a cui seguono 3 byte che si portano dietro un bel po' di informazioni ed "estensioni" dell'opcode a cui sono applicate), poi c'è il byte dell'opcode vero e proprio, il byte utilizzato per indirizzare la memoria (ci sono due operandi per la precisione: un registro e una locazione di memoria oppure un altro registro), un eventuale altro byte per specificare una modalità d'indirizzamento più complessa (registro base + registro indice * dimensione + offset), gli eventuali i byte dell'offset per indirizzare la memoria, e infine un altro byte con un valore immediato a 8 bit che è presente soltanto per alcune istruzioni che ne fanno uso.

Questo si traduce in istruzioni lunghe minimo 6 byte, ma che hanno il vantaggio di poter specificare una qualunque locazione di memoria per uno degli operandi sorgente, il che consente di risparmiare un'istruzione di load e relativa dipendenza, oltre che un registro in meno da "sporcare" per memorizzare il risultato della load, rispetto a un'equivalente RISC (che, conti alla mano, finirebbe per richiedere più istruzioni e occupare più spazio per fare la stessa cosa).

Senza contare poi le "goodies" che Intel ha aggiunto proprio nell'indirizzamento della memoria: broadcast del valore letto, oppure conversione di tipo (es: conversione da intero a 8 bit con segno intero a 32 bit con segno) al volo, senza bisogno di ulteriori istruzioni, e questo specificabile direttamente in OGNI istruzione della nuova unità SIMD. Le istruzione vere e proprio di load/store consentono, invece, parecchie altre operazioni di conversione (quelle del normale indirizzamento sono 4: le più diffuse per interi o valori in virgola mobile); senza contare poi le operazioni di gather e scatter.

Un RISC che ha un opcode fisso di 32 bit, in cui deve farci stare tutto: istruzioni general purpose e quelle dell'unità SIMD, per cui i progettisti sono costretti a fare un po' di economia sugli opcode e, quindi, sulle istruzioni eseguibili, che hanno per forza di cose dei limiti.
Basti vedere come ARM abbia dovuto riprogettare completamente l'ISA per aggiungere i 64 bit, togliendo di mezzo alcuni cavalli di battaglia dei processori ARM (tutte le istruzioni erano condizionali; istruzioni di load/store multiple di registri, e altro che al momento non mi viene in mente) per far spazio ai 32 registri (quasi) general purpose che ha introdotto; e idem (prima erano soltanto 16) per l'unità SIMD potenziata.
Non poteva fare altrimenti: i bit contano, e quindi certe scelte vanno sempre a scapito di qualcos'altro. Il che, tradotto, vuol dire istruzioni più semplici, in termini di lavoro "utile" eseguibile per la nuova ISA.

Quel che voglio dire, alla fine, è che un CISC consente di eseguire molto più lavoro "utile" per ogni singola istruzione eseguita, e ciò può portare (e con x86 abbiamo visto che... succede!) a prestazioni complessivamente più elevate rispetto a un RISC.
Questo, però, a scapito dei decoder, che sono di gran lunga più complicati rispetto ai RISC, e che richiedono oltre a milioni di transistor in più, consumi molto più elevati.

D'altra parte, tutto è frutto di compromessi. Non esiste l'uovo di Colombo. O forse deve ancora arrivare...

[coschizza]

Originariamente inviato da cdimauro

Quel che voglio dire, alla fine, è che un CISC consente di eseguire molto più lavoro "utile" per ogni singola istruzione eseguita, e ciò può portare (e con x86 abbiamo visto che... succede!) a prestazioni complessivamente più elevate rispetto a un RISC.
Questo, però, a scapito dei decoder, che sono di gran lunga più complicati rispetto ai RISC, e che richiedono oltre a milioni di transistor in più, consumi molto più elevati.

D'altra parte, tutto è frutto di compromessi. Non esiste l'uovo di Colombo. O forse deve ancora arrivare...

sono anni che leggo critiche incondizionate sulla tecologia cisc basate principalmente sull'ignoranza o sul fatto che risc è "ovviamente" superiore , il tuo post l'ho condivido pienamente bravo.

[cdimauro]

Non mi sento nemmeno di biasimare chi fa queste affermazioni. Erano idee che condividevo anch'io, fino a quando non ho cominciato ad avere a che fare seriamente con queste problematiche.

Non si può pretendere che tutti studino le architetture dei processori o che ne progettino qualcuna. Credo che ognuno abbia delle proprie inclinazioni / hobby che segue, e per i quali spende il proprio tempo.

Ciò non toglie che, di fronte ad alcune informazioni, chi ha avuto la possibilità di dedicarsi alle architetture, faccia sentire la propria opinione se rileva delle cose non esatte. Nella speranza che, alla fine, emergano e si facciano strada i concetti e le idee corrette.

[PaulGuru]

vedremo i prossimi Atom 22nm di Intel

[gnappoman]

Originariamente inviato da PaulGuru

Parlano tutti di ARM ma non ha le risorse di Intel.

dal Company Profile di ARM:
"Over 20 billion ARM based chips shipped to date"

per avere i numeri di Intel, dividi per 10......

[cdimauro]

Cosa non ti è chiaro del concetto di "risorsa" (finanziaria, s'intende) e di quello di "pezzi venduti" (consegnati, in realtà)?

Se si parla di risorse, perché tiri fuori il numero di pezzi di processori ARM venduti (sotto licenza della casa madre)?

Sono due cose completamente diverse, che non c'entrano proprio nulla.

[gnappoman]

Originariamente inviato da cdimauro

Fammi un fischio quando ARM presenterà una soluzione comparabile/competitiva con questa di Intel...

Simon Segers, presidente di arm, marzo 2012:

“Supercomputers, for ARM, is not a high volume market, it’s not something we spend a lot of time talking about. Ours is a business that is royalty and unit driven, so we’re interested in high-volume markers.”

E' per questo che aspettano a spazzare via intel

@mazinga
per risorse si intende risorse tecnologiche. I dindi non si fanno con la ricerca, ma con la commercializzazione, vedi tordi che comprano a 729 euro un cinafonino che a prodursi ne costa 100.....

[cdimauro]

Ho una discreta conoscenza della lingua inglese, ma mi sembra che quello che hai riportato non c'entri proprio nulla con la frase che avevo scritto prima.

Libero di smentirmi, ovviamente.

EDIT. Ho visto che hai editato il tuo messaggio, aggiungendo altro.

Le risorse tecnologiche sai da dove arrivano? Da quelle finanziarie. Se non hai soldi, non puoi investire in ricerca. Mi sembra lapalissiano.

Comunque le tue battutine sul mio avatar dimostrano che sei a corto di argomenti. Com'era facile intuire, vista la "consistenza" delle tue affermazioni...

[gnappoman]

diciamo che se mi trovi un utilizzo della suddetta scheda che non sia in ambito "supercomputer" te ne fo trovare una sotto l'albero di natale

Originariamente inviato da Bazzinga

EDIT. Ho visto che hai editato il tuo messaggio, aggiungendo altro.

-Le risorse tecnologiche sai da dove arrivano? Da quelle finanziarie. Se non hai soldi, non puoi investire in ricerca. Mi sembra lapalissiano.

a mazzi', nun vorrai mica incominciare un flame?

E ARM, che non fa altro che ricerca, non avrebbe il danaro da investire? Mi sembri allampanato.

[cdimauro]

Stai nuovamente cambiando argomento. Inoltre le faccine che usi sono un chiaro segnale del tuo disagio nel proseguire in una discussione spinosa in cui ti sei andato a cacciare.

Ciò detto, queste schede non servono esclusivamente per supercomputer, ma in generale in ambiti in cui servono potenze di calcolo superiori a quelle offerte da un normale server.

Infatti vanno a coprire e competere con le soluzioni già esistenti di AMD e, soprattutto, nVidia. Che non sono certo state realizzate esclusivamente per i supercomputer.

Difatti il titolo della news parla chiaro: GPGPU Computing.

Il fatto che l'evento in cui sono state presentate queste nuove soluzioni sia dedicato ai supercomputer NON implica che sia esclusivamente questo il loro ambito di utilizzo.

Logica (banale) alla mano.

[PaulGuru]

Spazzare via intel fa veramente ridere i polli.

Cortex non è in grado di produrre un chip ARM con IPC lontanamente paragonabile ad un i5, figurati contro un fiammante i7 o gli Entusiasth, ma non spariamo cavolate.

ARM vende ? Si i numeri li fanno ma con mobile dove Intel non c'è ancora ( grazie al piffero ), intel è il big del transistors sotto solo a IBM e volendo potrebbe pagare tutti gli OEM per penalizzare gli ARM e mettere a tacere tutti quanti come ha fatto con AMD.

Inoltre credi veramente che Intel non possa andare molto più di come sta andando ora ? Su desktop non ha concorrenza, se ci fosse sarebbe già ora in grado di accelerare la roadmap di 2 annetti, altro che Haswell ..............

[gnappoman]

@maz
mah, se vuoi ti dò anche ragione, davvero non riesco a pensare a un utilizzo di queste unità SIMD in un server normale di classe enterprise

@paul
boh, Intel non è altro che un successo di mercato che applica logiche di mercato, se il consumatore si accontentasse venderebbero ancora a caro prezzo i 486.
ARM vende una tecnologia che viene implementata e sfruttata al massimo dalle aziende che ne acquistano la licenza, il suo lavoro è pura ricerca.

Quale delle due logiche è vincente?

[cdimauro]

Originariamente inviato da PaulGuru

Spazzare via intel fa veramente ridere i polli.

Cortex non è in grado di produrre un chip ARM con IPC lontanamente paragonabile ad un i5, figurati contro un fiammante i7 o gli Entusiasth, ma non spariamo cavolate.

ARM vende ? Si i numeri li fanno ma con mobile dove Intel non c'è ancora ( grazie al piffero ), intel è il big del transistors sotto solo a IBM e volendo potrebbe pagare tutti gli OEM per penalizzare gli ARM e mettere a tacere tutti quanti come ha fatto con AMD.

Inoltre credi veramente che Intel non possa andare molto più di come sta andando ora ? Su desktop non ha concorrenza, se ci fosse sarebbe già ora in grado di accelerare la roadmap di 2 annetti, altro che Haswell ..............

A parte ciò, ARM non ha nessuna soluzione che possa competere nel campo del GPGPU Computing.

Questo è un dato di fatto incontrovertibile, che non si può smontare semplicemente perché davanti si ha una tastiera e si può scrivere quel che si vuole...

[cdimauro]

Originariamente inviato da gnappoman

mah, se vuoi ti dò anche ragione, davvero non riesco a pensare a un utilizzo di queste unità SIMD in un server normale di classe enterprise

E' un tuo limite. Altri non la pensano così. E non sono gli unici...