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

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

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.

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

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.

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

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.

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.

vedremo i prossimi Atom 22nm 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......