Intel annulla il lancio dei coprocessori Xeon Phi 7200 'Knights Landing'

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/cpu/int...ing_70698.html

Senza particolari clamori o annunci, Intel ha deciso di annullare il lancio dei coprocessori Xeon Phi 7200 "Knights Landing" inseriti su schede PCI-E. Continuerà, invece, il lancio dei processori su socket

Click sul link per visualizzare la notizia.

[GiGBiG]

Questa storia mi fa venire in mente i chip MMX che avrebbero dovuto affiancare i primi Pentium, ma che poi non sono più stati commercializzati... 1997 forse, mezza vita fa

[ginogino65]

Originariamente inviato da GiGBiG

Questa storia mi fa venire in mente i chip MMX che avrebbero dovuto affiancare i primi Pentium, ma che poi non sono più stati commercializzati... 1997 forse, mezza vita fa

Tutti processori intel, successivi ai MMX, integrano le funzioni introdotte con i pentium mmx, quindi a tutti gli effetti, i processori MMX sono ancora in vendita.

[Rubberick]

Si ma che senso ha? Su pci-e uno può montarne molti e facilmente.. Su socket?

[GiGBiG]

Originariamente inviato da ginogino65

Tutti processori intel, successivi ai MMX, integrano le funzioni introdotte con i pentium mmx, quindi a tutti gli effetti, i processori MMX sono ancora in vendita.

Ma Intel aveva detto che chi aveva comprato i primi Pentium senza MMX avrebbe potuto "aggiungere un chip", non specificando come. Hanno dato molte speranze a chi come me aveva un Pentium "liscio", ma poi non se n'è più fatto nulla, e mi sono comprato una 3Dfx

I processori odierni non contengono le istruzioni MMX, anche perché sono state rimpiazzate poco tempo dopo dalle SSE, che oltretutto si integravano molto meglio con l'architettura della CPU facendo di fatto dimenticare le MMX come un esperimento poco riuscito.

[cdimauro]

Originariamente inviato da Rubberick

Si ma che senso ha? Su pci-e uno può montarne molti e facilmente.. Su socket?

Dipende da quanti socket metti a disposizione, ovviamente. Mi pare che siano supportati fino a 8 socket.

Comunque è l'approccio/utilizzo che è radicalmente diverso: con le versioni su socket hai delle CPU x86/x64 a cui puoi dare in pasto qualunque applicazione esistente, mentre quelle PCI-Express sono dei coprocessori che richiedono uno stack software dedicato per poter essere usati nonché una compilazione apposita.

Ovviamente se vuoi ottenere il massimo devi compilare appositamente per anche per Knights Landing su socket, ma rispetto alla versione PCI-Express hai anche l'enorme vantaggio che non è necessario nessuno scambio di dati (la memoria è lì, ed è già condivisa da tutti i socket), mentre in quest'ultimo caso fra host e scheda/e deve sempre avvenire un (lento, visto che si passa da PCI-Express) passaggio di dati.

Originariamente inviato da GiGBiG

Ma Intel aveva detto che chi aveva comprato i primi Pentium senza MMX avrebbe potuto "aggiungere un chip", non specificando come. Hanno dato molte speranze a chi come me aveva un Pentium "liscio", ma poi non se n'è più fatto nulla, e mi sono comprato una 3Dfx

E' la prima volta che lo sento.

I processori odierni non contengono le istruzioni MMX, anche perché sono state rimpiazzate poco tempo dopo dalle SSE,

No, le MMX sono sempre lì, come ti è già stato detto, fin da quando sono state introdotte. Dagli ultimi processori Intel:

che oltretutto si integravano molto meglio con l'architettura della CPU

Non mi risulta nemmeno questo. MMX ed SSE sono MOLTO simili, e difatti condividono parte degli opcode (per quasi tutte le istruzioni MMX c'è la controparte SSE, e l'unica differenza è che quest'ultima utilizza un apposito prefisso per "trasformare" l'istruzione/opcode MMX in SSE).

facendo di fatto dimenticare le MMX come un esperimento poco riuscito.

Da quando sono state introdotte le SSE effettivamente non ha molto senso utilizzare le MMX, ma vedi sopra: l'esperimento "poco riuscito" di cui parli è e rimane ancora alla base delle SSE.

Basti dare un'occhiata al manuale dell'architettura dei processori Intel (o AMD: è uguale) per verificarlo.

[LMCH]

Originariamente inviato da GiGBiG

I processori odierni non contengono le istruzioni MMX, anche perché sono state rimpiazzate poco tempo dopo dalle SSE, che oltretutto si integravano molto meglio con l'architettura della CPU facendo di fatto dimenticare le MMX come un esperimento poco riuscito.

No, in modalità 32bit il supporto per MMX c'è ancora.

[LMCH]

In pratica Intel ha capito che con K.L. non può competere con sistemi GPGPU oppure basati su FPGA su PCI-E e come è successo in passato si sta defilando progressivamente.

Probabilmente continuerà a proporre versioni su socket e spingerà soluzioni x86+FPGA che possono essere anche implementate su daughterboard su PCI-E.

[aled1974]

ricordo ancora i proclami in pompa magna di Intel sul progretto Larrabee secondo i quali avremmo avuto schede gpgpu e raytracing da fantascienza, anzi, ad un certo punto si sbilanciarono perfino a dire che sarebbe uscita una versione con supporto videogames

con questa di oggi sembra invece che abbiano dato il colpo di grazia al progetto, o per meglio dire anche all'ultima sua possibile implementazione


evidentemente progettare schede video competitive, che siano gaming o professionali non dev'essere poi così semplice se anche un gigante quale Intel gliela da su

ciao ciao

[GiGBiG]

Originariamente inviato da cdimauro

E' la prima volta che lo sento.

---

No, le MMX sono sempre lì, come ti è già stato detto, fin da quando sono state introdotte.

Infatti la faccenda era durata poco, magari era una voce fraintesa circolata un po' troppo.

Le MMX probabilmente sono ancora lì per questione di compatibilità, occupano talmente poco spazio che forse non serve toglierle, benchè non servano a niente. Le SSE di fatto sono l'evoluzione delle MMX, è naturale che siano speculari alle MMX, però sono la controparte "progettata bene", è questa la grossa differenza, e infatti le istruzioni aggiunte in seguito sono SS2, SS3 etc: un motivo c'è

[cdimauro]

Originariamente inviato da LMCH

No, in modalità 32bit il supporto per MMX c'è ancora.

Non ho controllato, ma dovrebbero essere disponibili anche in modalità a 64 bit, sebbene siano deprecate (assieme all'FPU x87) in favore delle SSE2 (che sono il minimo set d'istruzioni supportate in Long Mode / 64 bit).

Originariamente inviato da LMCH

In pratica Intel ha capito che con K.L. non può competere con sistemi GPGPU oppure basati su FPGA su PCI-E e come è successo in passato si sta defilando progressivamente.

Probabilmente continuerà a proporre versioni su socket e spingerà soluzioni x86+FPGA che possono essere anche implementate su daughterboard su PCI-E.

Non credo proprio che sia questa la ragione. Alla Intel ho lavorato proprio con le schede Xeon Phi (Knights Corner) e, poco prima di lasciare, anche con queste nuove versioni su socket (Knights Landing, per l'appunto), per cui so bene come funzionano tutte e due (ho scritto anche diversi test per le estensioni / debugger relative a questi chip, per la suite Parallel Studio AKA Composer).

Come dicevo prima, la versione su socket è di gran lunga preferibile a quella su scheda PCI-Express perché offre notevoli vantaggi prestazionali, e a costi (sia hardware sia, soprattutto, software) molto più ridotti.

Di fatti, e se rileggi la notizia, Intel ha avuto un notevole successo con le versioni su socket, e immagino che, specularmente, non abbia avuto un granché di ordini per le schede PCI-Express (sebbene ci siano GROSSI centri di calcolo che ne fanno già uso, e immagino che avessero anche pianificato di impiegarle per altri progetti. Com'è ovvio che sia se hai già investito in queste soluzioni, e vuoi "semplicemente" aggiornare il tuo parco hardware con le nuove, più potenti, versioni di Xeon Phi. Probabilmente per questi casi Intel continuerà a produrre le versioni su scheda, o magari darà una mano per portare velocemente il software sulle versioni su socket), per cui avrà abbandonato queste ultime e si sarà concentrata sulle prime.

Se Knights Landing non fosse competitivo a causa di (GP)GPU e/o FPGA, non lo sarebbe a prescindere: sia socket sia su PCI-Express. In fondo il chip che trovi sulle schede è esattamente lo stesso che trovi piazzato su scheda. Da questo punto di vista non c'è differenza.

La differenza, però, sta nella notevole complessità della scheda, nell'ancor più notevole complessità dello stack software (considera che le schede integrano pure una distro Linux basata su YOCTO), e negli svantaggi prestazionali di cui parlavo prima (la comunicazione host <-> PCI-Express).

Sono ragionevolmente sicuro, per quanto detto, che queste siano le motivazioni che hanno spinto Intel a questa decisione.

Originariamente inviato da aled1974

ricordo ancora i proclami in pompa magna di Intel sul progretto Larrabee secondo i quali avremmo avuto schede gpgpu

GPU: non GPGPU. Larrabee era una GPU.

e raytracing da fantascienza, anzi, ad un certo punto si sbilanciarono perfino a dire che sarebbe uscita una versione con supporto videogames

Veramente era proprio quello l'obiettivo: entrare nel mercato delle GPU. E, dunque, anche dei videogiochi, ovviamente.

Fallito, perché le GPU sono decisamente più economiche e competitive a causa dell'hardware ad hoc, realizzato appositamente allo scopo. Larrabee si portava dietro troppo legacy x86 (x64 in realtà), e non poteva competere.

con questa di oggi sembra invece che abbiano dato il colpo di grazia al progetto, o per meglio dire anche all'ultima sua possibile implementazione

Non è affatto così. Leggi meglio la notizia, e quello che ho scritto qui sopra.

evidentemente progettare schede video competitive, che siano gaming o professionali non dev'essere poi così semplice se anche un gigante quale Intel gliela da su

ciao ciao

Intel progetta già da parecchi anni GPU, che trovi integrate in buona parte delle sue CPU.

Con Larrabee voleva attaccare anche il segmento delle discrete.

Xeon Phi, invece, è la declinazione "GPGPU", che ha avuto un discreto successo (ci sono diversi supercomputer che le usano: dai un'occhiata alla TOP 500. Ma le usano anche anche altri progetti che necessitano di processare grosse mole di dati).

Sono 3 cose diverse, e soltanto la seconda è stata un fallimento.

Originariamente inviato da GiGBiG

Infatti la faccenda era durata poco, magari era una voce fraintesa circolata un po' troppo.

Le MMX probabilmente sono ancora lì per questione di compatibilità, occupano talmente poco spazio che forse non serve toglierle, benchè non servano a niente.

Penso che ci sia ancora parecchio software che ne faccia uso, ed è il motivo per cui sono ancora supportate.

Ma circolano voci che in futuro Intel potrebbe rimuoverle dalla sua ISA.

Non so quale sia il costo implementativo (a livello micro-architetturale, per intenderci), ma non credo sia così poco. Evidentemente rimuovere le MMX porterà alcuni vantaggi concreti a Intel (SE le toglierà, alla fine, visto che al momento sono solo voci).

Le SSE di fatto sono l'evoluzione delle MMX, è naturale che siano speculari alle MMX, però sono la controparte "progettata bene", è questa la grossa differenza, e infatti le istruzioni aggiunte in seguito sono SS2, SS3 etc: un motivo c'è

Il motivo è che le MMX facevano uso dei registri dell'FPU (x87), che all'occorrenza venivano "rimappati" nelle versioni "vettoriali" usati dalle istruzioni MMX. Mentre le SSE hanno aggiunto un nuovo set di registri, la cui dimensione peraltro varia (da 128 bit di SSE siamo passati ai 256 di AVX/-2, e arrivati di recente ai 512 di AVX-512).

In linea teorica per le SSE/AVX/AVX-512 Intel avrebbe potuto tranquillamente continuare a utilizzare i registri dell'FPU, estendendoli in numero nonché dimensione, e continuando a utilizzare la stessa struttura degli opcode MMX.

Non so perché, alla fine, abbiano deciso per una soluzione radicale. Immagino che abbiano avuto i loro buoni motivi, ma personalmente propenderei per l'ipotesi di togliere del tutto di mezzo l'FPU x87, che è un grosso pezzo di legacy.

[LMCH]

Originariamente inviato da cdimauro

Come dicevo prima, la versione su socket è di gran lunga preferibile a quella su scheda PCI-Express perché offre notevoli vantaggi prestazionali, e a costi (sia hardware sia, soprattutto, software) molto più ridotti.

E' essenzialmente quello che avevo scritto (seppur in modo molto più sintetico).

Le soluzioni su PCI-E hanno più senso per sistemi basati su GPU e FPGA nei casi in cui maggiori latenze e meno banda di I/O non sono un limite eccessivo, con costi inferiori e prestazioni adeguate se la tipologia di elaborazioni prevalenti sono elaborazioni "lunghe" su set di dati che possono essere partizionati o bufferizzati bene.

[cdimauro]

Sì, ma il punto è che questi limiti si applica(va)no anche alle soluzioni Xeon Phi su PCI-Express per l'appunto, ma Intel ormai ha una soluzione universale, su socket, che funziona bene sia nei casi hai citato, sia negli altri altri.

Per essere chiari, non ha più senso per lei mantenere le soluzioni su scheda, quando quelle su socket sono sotto tutti gli aspetti più convenienti. Quindi ha dismesso le versioni PCI-Express non perché non competitive rispetto ad FPGA e GPU, ma perché ha di meglio.

[zhelgadis]

Originariamente inviato da cdmauro

Non so perché, alla fine, abbiano deciso per una soluzione radicale. Immagino che abbiano avuto i loro buoni motivi, ma personalmente propenderei per l'ipotesi di togliere del tutto di mezzo l'FPU x87, che è un grosso pezzo di legacy.

Perché tutte le volte che si passava da MMX a x87 era necessario fare una copia dei registri e poi ripristinarli (il software vedeva registri diversi, ma in HW erano i medesimi), cosa che portava ad un impatto prestazionale non indifferente. E visto che le MMX funzionavano solo su interi, non si poteva semplicemente buttare via la vecchia FPU, eri costretto a fare load/store dei registri tutte le volte.

Con SSE si è preso il toro per le corna e si sono divisi i due percorsi, in modo che l'FPU x87 usasse i suoi registri e le nuove istruzioni un set di registri dedicato. Questo ha permesso di superare i limiti del vecchio set di istruzioni, tant'è che SSE e sue evoluzioni sono ancora vive e vegete.

[zhelgadis]

Peraltro abbandonare l'FPU x87 non è stato così indolore. Al di là degli ovvi motivi di retrocompatibilità con il vecchio codice, x87 permetteva di eseguire internamente i calcoli con una precisione estesa ad 80 bit, mentre SSE è sempre stata limitata a 64 bit (a partire da SSE2).

Le soluzioni si sono trovate col tempo, ma quando uscirono le SSE2 con il Pentium 4 molti utenti Matlab ebbero da ridire ...

[cdimauro]

Anche con le SSE le istruzioni intere e in virgola mobile usano lo stesso set di registri.

Il problema di x87 ed MMX è che per eseguire istruzioni di ognuna delle due non era necessario copiare i registri, ma eseguire un'apposita istruzione per "sistemare" lo stato dei registri a seconda di quali istruzioni eseguire successivamente.

Ora, x86 è roba legacy (ma continua ad avere i suoi vantaggi, come giustamente hai riportato: 80 bit, con ben 64 per la mantissa / precisione), per cui era ed è un vicolo cieco per quanto riguarda le prestazioni, ma i suoi registri avrebbero potuto benissimo essere utilizzati anche per le SSE (e successori).

Mi spiego meglio. E' vero che con MMX puoi eseguire soltanto operazioni intere, ma nessuno avrebbe impedito a Intel di implementare anche quelle in virgola mobile, esattamente come fece AMD con 3DNow!. In questo modo non ci sarebbe stato alcun problema di "context switch" fra x87 e MMX, perché usando queste ultime anche per i float non sarebbe stato necessario.

Alla fine, e come dicevo prima, se guardi gli opcode di MMX ed SSE, sono praticamente gli stessi: quelli MMX si ritrovano pari pari su quelli SSE, ma con l'unica differenza di un prefisso diverso (che consente di "mappare" l'opcode come SSE anziché MMX). In linea teorica tutte le istruzioni SSE che sono mancanti su MMX avrebbero potuto benissimo funzionare anche su MMX, se Intel avesse deciso in tal senso (quindi sarebbe stato sufficiente eliminare il prefisso SSE, e consentire di eseguire la stessa istruzione, ma su MMX).

Se guardi la situazione attuale, con x64 non usi l'FPU x87, perché è deprecata, e viene consigliato l'uso delle SSE2, perché coprono sia gli interi sia i float (anche a doppia precisione). In pratica che tu utilizzi SIMD a interi o float è indifferente: usi sempre le istruzioni SSE.

Ma sarebbe potuto succedere esattamente la stessa cosa con le MMX, e sfruttando i registri di x87 (eventualmente estesi a 128 o più bit).

Spero di essere stato chiaro, anche se riconosco che il pensiero è un po' contorto.

[LMCH]

Originariamente inviato da cdimauro

Sì, ma il punto è che questi limiti si applica(va)no anche alle soluzioni Xeon Phi su PCI-Express per l'appunto, ma Intel ormai ha una soluzione universale, su socket, che funziona bene sia nei casi hai citato, sia negli altri altri.

Per essere chiari, non ha più senso per lei mantenere le soluzioni su scheda, quando quelle su socket sono sotto tutti gli aspetti più convenienti. Quindi ha dismesso le versioni PCI-Express non perché non competitive rispetto ad FPGA e GPU, ma perché ha di meglio.

Per Intel e per la tipologia di clienti a cui è interessata non ha più senso, ma per altri che hanno esigenze differenti le soluzioni su slot continuano ad aver senso.
Attualmente i produttori di mainboard propongono pure schede madri con 13 slot PCIe ( ASRock H110 Pro BTC+ ) per chi ad esempio fa mining di criptovalute.

[cdimauro]

Assolutamente d'accordo. D'altra parte le schede PCI-Express sono figlie del progetto Larrabee, ma con Knights Landing Intel se n'è finalmente riuscita a liberare.

[TheDarkAngel]

11 mesi dopo:
https://www.techpowerup.com/246237/intel-is-giving-up-on-xeon-phi-eight-more-models-declared-end-of-life

[cdimauro]

Intel ha già annunciato di voler entrare nel mercato delle GPU desktop, affermando anche di bloccare la famiglia di Xeon Phi per lavorare a nuova microarchitettura. Quindi è ovvio che le attuali siano destinate a morire.

Complice anche i problemi dei 10nm (3 anni di ritardo SE arriveranno il prossimo anno), che sono fondamentali per impacchettare più core e/o ridurre i consumi, e sono arrivate al capolinea prima del previsto.