Intel met fin à son aventure Larrabee, Réactions à la publication du 09/05/2019

[Lionel]

En 2010, Intel a décidé de se lancer dans l'aventure des CPU avec une idée censée être alors innovante, remplacer les coeurs graphiques dédiés par un grand nombre de coeurs dérivés du design des puces 486.
La société n'a jamais convaincu avec ce projet et décidé de le recycler en un autre, où ces coeurs améliorés devenaient des coprocesseurs pour faire l'équivalent du GP-GPU. Le nom a alors changé pour devenir Xeon Phi dont on a eu plusieurs versions.

Là encore, ce produit n'a pas convaincu par ses performances face au vrai GP-GPU et à la complexité de paralléliser de plus en plus des calculs.

La société a annoncé la fin de cette aventure. Les actuels Xeon Phi 7295, 7285 et 7235 seront les derniers et il est possible de les commander jusqu'au 9 août prochain avant leur disparition.

De l'autre côté, Intel a décidé de se lancer sur le marché des vraies puces graphiques dédiées, basées sur des procédés plus classique. On verra si la société arrive à s'y faire un trou, tout en sachant que grâce aux parties graphiques intégrées à ses puces la société reste, en nombre, le premier vendeur de solutions graphiques.

Lien vers le billet original

[iAPX]

Il faut rappeler que ces bousins étaient d'abord de très mauvaises CPU, non à cause de leurs basses performances (normal) mais à cause de leur incompatibilité binaire et même en terme de sources assembleur avec les x86 modernes (AMD64; AVX; AVX2; etc.) et réciproquement.
Ça portait le nom "x86" mais avec une compatibilité folklorique, probablement à même de faire tourner Windows NT4 ou Windows 2000, et encore!

Coté number-crunching ça dépotait bien plus qu'un x86 normal, mais bien moins qu'une bonne GPU, là aussi inférieur pour des prix explosifs!

Je pense quand-même que nous leur devons les unités AVX 512bits dans les CPU récentes mais aussi l'architecture actuelle des iGPU Intel très efficaces pour faire tourner du code OpenCL complexe, avec un bien meilleur ratio perf réelle/perf théorique dans ce cas que tout ce que nVidia ou AMD a pu sortir à ce jour!

Je parierais que les futures dGPU Intel seront excellentes voir insurpassables en GPGPU, mais médiocre voir franchement inférieures comme GPU pour le jeu.

[XL]

C'est pas non plus la mort de recompiler le code spécifiquement pour une architecture. On écrit bien du code spécifique pour certaines architectures.
Je pense que le Xeon Phi sont loin des perfs attendues, même sur des cibles "faciles" (eg. LINPACK).

[iAPX]

C'est pas non plus la mort de recompiler le code spécifiquement pour une architecture. On écrit bien du code spécifique pour certaines architectures.
Je pense que le Xeon Phi sont loin des perfs attendues, même sur des cibles "faciles" (eg. LINPACK).

Je suis d'accord, mais dans ce cas pourquoi se compliquer la vie avec du x86, et vendre ça comme "compatible" (argument imbattable bien que totalement faux) ?!?

Pour les perfs ça a été la grosse déception, l'efficacité avec le ratio perf réelles/perf théoriques, sans compter le TDP qui venait avec, et alors qu'Intel voulait s'emparer du marché du HPC avec ça en tuant nVidia c'est l'inverse qui est arrivé.

[XL]

L'argument du "compatible et facile" je pense que c'était un argument pour les managers... On le sait, rien n'est gratuit.

Ce message a été modifié par XL - 9 May 2019, 14:47.

[Ambroise]

Il faut rappeler que ces bousins étaient d'abord de très mauvaises CPU, non à cause de leurs basses performances (normal) mais à cause de leur incompatibilité binaire et même en terme de sources assembleur avec les x86 modernes (AMD64; AVX; AVX2; etc.) et réciproquement.
Ça portait le nom "x86" mais avec une compatibilité folklorique, probablement à même de faire tourner Windows NT4 ou Windows 2000, et encore!

C'est du x86 et la compatibilité est aussi bonne qu'entre d'autres références d'Intel.
Tout l'intérêt des Xeon Phi c'est justement de permettre de faire tourner des codes de calculs adaptés (pour tirer parti des 144 threads mais surtout être capables de tirer partie de la mémoire hétérogène) mais en continuant de les linker à des librairies binaires existantes.
La plupart des applications de calcul sont liées à des librairies de calcul traditionnelles elles-mêmes liées à d'autres briques binaires classiques de calcul - et les Xeon Phi permettent sans souci de se lier à ces librairies sans avoir à les recompiler.

[Ambroise]

Ça portait le nom "x86" mais avec une compatibilité folklorique, probablement à même de faire tourner Windows NT4 ou Windows 2000, et encore!

Aucun problème avec Windows 7 ou Windows 10.


Pour moi la raison principale de l'échec du Xeon Phi c'est le foirage industriel du 10nm chez Intel qui en a tué l'évolution.
C'est une machine qui fonctionne aux limites des capacités du procédé de fabrication. Le Knight Hill aurait du sortir il y a 2 ans avec 2,7 fois le nombre de transistors des Knight Landing actuels. Il en aurait multiplié par 4 la puissance crête de calcul. Ces perfs garantissait à Intel la clientèle des supercalculateurs et ils avaient même une commande de 200 millions de dollars avant qu'ils ne l'annulent faute d'usines fonctionnelles.

[iAPX]

Allez pour en remettre une couche pour ceux qui ne le savent pas, avec la source ici par le Summer Supercomputing Institute (PDF) "What is a native application?" page 21.

"MIC [Xeon Phi] is not binary compatible with the [x86/AMD64] host processor:
– Instruction set is similar to Pentium, but not all 64 bit scalar
extensions are included.
– MIC [Xeon Phi] has 512 bit vector extensions, but does NOT have
MMX, SSE, or AVX extensions."

"Native [Xeon Phi] applications can’t be used on the host [x86/AMD64] CPU, and viceversa."

Il n'y a pas de compatibilité binaire, sauf très restreinte entre le Xeon Phi et les CPU x86, puisque ni MMX ni SSE ni AVX ou AVX2 ne sont supportées en sus d'autres instructions scalaires 64bits et le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!).
Exactement ce que j'écrivais au-dessus ni plus ni moins "AMD64; AVX; AVX2; etc." (j'avais gentiment écarté le SSE mais il est maintenant la base pour le fp scalaire pour des raisons d'exécution OoO face au modèle Stack de la FPU des origines!)

Et pour finir pour les perfs CPU, hors SIMD (AVX-512), c'est l'équivalent du MBP que j'utilise pour taper ce texte en multithread et facilement 12X plus lent en monothread (donc en latences).
Quand aux perfs pour le calcul vectoriel c'est risible face à une GPU de milieu-de-gamme actuelle (ou celle de mon MBP), en fait les CPU+iGPU Intel en 10nm lui donneront la fessée sur presque tous les plans (hors accès mémoire) dans un TDP de 25W...

Ce message a été modifié par iAPX - 9 May 2019, 19:20.

[tim_gnu]

Le Xeon phi n'ont jamais eu vocation à devenir un processeur pour le grand public. C'est un processeur qui a été développé pour le HPC, et comme souvent il a été mis en place pour les grandes commandes HPC des nationals lab. Ce processeur était surtout pour la mémoire qui lui est associé 16 GB de MCDRAM pour une bande passante de 400 GB/s. Il faut aussi savoir que le processeur a été développé par Alan Gara architecte des Blue Gene d'IBM. Sa philosophie est beaucoup de petit processeur pour beaucoup de scaling, c'est un point de vue qui se défend. Le modèle de programmation était simplement l'utilisation d'OpenMP. Une simple recompilation du code et ça marche. Bref ce processeur n'a pas vraiment marché dans le milieu du HPC. Alors pourquoi ?

Mon point de vue et qu'il est facile d'acheter un cluster, mais moins d'avoir un support software (sdk/environnement/etc... - Prise de tete pour la recompilation des libraires MPI). Pour le cas du Xeon Phi le support était à minima, oui il était possible de recopier la totalité des librairies du monde HPC mais avec des performance en deçà. D'un certains coté le plus (parallelization des codes faciles grace à openmp) c'est transformé en moins lors d'execution de code séquentiel tiers (HDF5, etc ...). Par ailleurs, obtenir des performances, demande bien de retravailler son code. A contrario Nvidia à un support software énorme. Il y a des réels efforts pour supporter et implémenter des librairies, et workshop etc .... Après il y a le cout. Développer un processeur lorsque l'on sait où on va c'est 2 milliards de $. Il n'y a aucune rentabilité dans le milieu HPC. Nvidia marche bien car il y a le marché grand publique et le jeux vidéo. Ils peuvent se permettre de faire des V100 car le développement est payé plus ou moins par des nintendo switch.

Pour terminer, pour le futur national lab d'Oak Ridge, la solution sera du pure AMD, Epyc + Radeeon, je suis un peu effrayé par la solution GPU. Car présentement dans le milieu du HPC les solutions OpenCL sont faméliques. L'unique alternative est OpenACC mais PGI appartient maintenant à Nvidia. De plus, Nvidia a fait des efforts monstres depuis 10 ans pour simplifier/améliorer son SDK et la programmation GPU. Mais bon on vera bien.

Après je vois beaucoup de gens qui hurlent sur Intel, je pense avoir tester tous les processeurs depuis 10 ans (x86/Power/ARM/trux exotique), et jusqu'à présent j'ai obtenu les meilleurs perf sous X86 (voir la remarque de Linus sur ARM/X86)

Ce message a été modifié par tim_gnu - 9 May 2019, 19:30.

[Ambroise]

Message posté par erreur en cours d'édition. Désolé. Prière de regarder deux messages plus loin.

Il n'y a pas de compatibilité binaire, sauf très restreinte entre le Xeon Phi et les CPU x86, puisque ni MMX ni SSE ni AVX ou AVX2 ne sont supportées en sus d'autres instructions scalaires 64bits et le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!).
Exactement ce que j'écrivais au-dessus ni plus ni moins "AMD64; AVX; AVX2; etc." (j'avais gentiment écarté le SSE mais il est maintenant la base pour le fp scalaire pour des raisons d'exécution OoO face au modèle Stack de la FPU des origines!)

Il est bien compatible au niveau binaire : il ne supporte pas les mêmes extensions optionnelles que d'autres CPU Intel. ça n'empêche pas la compatibilité : l'intérêt des extensions c'est qu'elles sont optionnelles et qu'on ne les utilise que si elles sont présentes.

t le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!)

En fait la première génération de Xeon implémentait l'extension IMCI qui proposait du calcul vectoriel sur des registres 512 bits. Elle n'

Ce message a été modifié par Ambroise - 9 May 2019, 21:55.

[iAPX]

Il n'y a pas de compatibilité binaire, sauf très restreinte entre le Xeon Phi et les CPU x86, puisque ni MMX ni SSE ni AVX ou AVX2 ne sont supportées en sus d'autres instructions scalaires 64bits et le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!).
Exactement ce que j'écrivais au-dessus ni plus ni moins "AMD64; AVX; AVX2; etc." (j'avais gentiment écarté le SSE mais il est maintenant la base pour le fp scalaire pour des raisons d'exécution OoO face au modèle Stack de la FPU des origines!)

Il est bien compatible au niveau binaire : il ne supporte pas les mêmes extensions optionnelles que d'autres CPU Intel. ça n'empêche pas la compatibilité : l'intérêt des extensions c'est qu'elles sont optionnelles et qu'on ne les utilise que si elles sont présentes.

t le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!)

En fait la première génération de Xeon implémentait l'extension IMCI qui proposait du calcul vectoriel sur des registres 512 bits. Elle n'

Tu es tout mêlé: si pour toi toute instruction scalaire non-présente dans le Pentium 1 est "optionnelle" alors on est d'accord, mais moi je me tord de rire par terre
Oser dire que du code de 20ans sur Pentium III ne s'exécutera pas sur Xeon Phi 61 cœurs c'est normal car ce sont des instructions "optionnelles", fallait oser!

Bien sûr que le noyau Linux n'utilise plus que SSE (non-supporté sous la daube Xeon Phi) comme base pour le calcul flottant scalaire sur AMD64/x86 n'est évidemment pas un problème de compatibilité, pas du touuuuuuttttt....

Mais j'oubliais que la base c'est la compatibilité Windows: tout le monde sait qu'en HPC on utilise Windows à fond, c'est bien connu, du moment que Windows XP tourne

Ce message a été modifié par iAPX - 9 May 2019, 21:52.

[Ambroise]

Il n'y a pas de compatibilité binaire, sauf très restreinte entre le Xeon Phi et les CPU x86, puisque ni MMX ni SSE ni AVX ou AVX2 ne sont supportées en sus d'autres instructions scalaires 64bits et le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!).
Exactement ce que j'écrivais au-dessus ni plus ni moins "AMD64; AVX; AVX2; etc." (j'avais gentiment écarté le SSE mais il est maintenant la base pour le fp scalaire pour des raisons d'exécution OoO face au modèle Stack de la FPU des origines!)

Il est bien compatible au niveau binaire : il ne supporte pas les mêmes extensions optionnelles que d'autres CPU Intel. ça n'empêche pas la compatibilité : l'intérêt des extensions c'est qu'elles sont optionnelles et qu'on ne les utilise que si elles sont présentes.
Toutes les générations de CPU x86 supportent des ensembles différents d'extensions.

Sur les stations Xeon Phi x200 socket, on peut installer normalement Windows Server 2012 ou Windows 10. La compatibilité est binaire. Windows 10 tourne sur le xeon Phi et détecte 256 ou 288 processeurs selon le modèle.
On avait vu dès la sortie du x200 fleurir ces vidéos de benchs sous Windows (ici avec Cinebench en 2016) : https://www.youtube.com/watch?v=43DcdZLZd94

t le code binaire du Xeon Phi utilisant son encodage pour l'AVX-512 ne peut tourner sur aucune CPU Intel actuelle supportant AVX-512 (sans compter les sous-ensembles non-supportés de part et d'autre!)

En fait la première génération de Xeon Phi implémentait l'extension IMCI qui proposait du calcul vectoriel sur des registres 512 bits. Elle n'a existé que sur ces processeurs. Ce sont des vecteurs 512 bits mais ça n'est pas de l'AVX-512. Il n'y a effectivement aucune compatiblité avec d'autres CPU.

A partir des Knights Landing, le jeu d'instruction AVX-512 a été proposé sous forme de différentes extentions : AVX-512F (F pour foundation) existe à l'identique pour tous les CPUs supportant AVX-512.

Ce message a été modifié par Ambroise - 9 May 2019, 21:54.

[iAPX]

...
A partir des Knights Landing, le jeu d'instruction AVX-512 a été proposé sous forme de différentes extentions : AVX-512F (F pour foundation) existe à l'identique pour tous les CPUs supportant AVX-512.

Enfonçons le clou c'est incompatible binairement, et justement ça comporte des sous-ensemble d'instruction différentes de celles proposées par les CPU AMD64/x86 actuelles.

Quand au reste, continuer à prétendre que ne pas pouvoir exécuter du code d'il y a 20ans comme étant "normal" sous couverts d'extensions du jeu d'instruction

TL;DR le Xeon Phi est approximativement compatible Pentium II, ça ne qualifie pas vraiment une compatibilité x86 dans les années 2010!

Ce message a été modifié par iAPX - 9 May 2019, 21:56.

[Ambroise]

...
A partir des Knights Landing, le jeu d'instruction AVX-512 a été proposé sous forme de différentes extentions : AVX-512F (F pour foundation) existe à l'identique pour tous les CPUs supportant AVX-512.

Enfonçons le clou c'est incompatible binairement, et justement ça comporte des sous-ensemble d'instruction différentes de celles proposées par les CPU AMD64/x86 actuelles.

C'est ainsi que fonctionnent les extensions d'une manière générale depuis 30 ans.
Par exemple les instructions 3DNow ont été supportées par AMD pendant plus d'une douzaine d'années depuis le K6-2.
Un logiciel compilé avec 3DNow en 1998 fonctionnera aussi bien sur un K6-2 de l'époque que sur un Xeon Phi x200 ou un Core 2 Duo. La différence c'est que sur le K6-2 c'est le chemin 3DNow! qui sera pris dans le code, alors que sur les deux autres ça sera un chemin avec des instructions non optionnelles.

[iAPX]

...
A partir des Knights Landing, le jeu d'instruction AVX-512 a été proposé sous forme de différentes extentions : AVX-512F (F pour foundation) existe à l'identique pour tous les CPUs supportant AVX-512.

Enfonçons le clou c'est incompatible binairement, et justement ça comporte des sous-ensemble d'instruction différentes de celles proposées par les CPU AMD64/x86 actuelles.

C'est ainsi que fonctionnent les extensions d'une manière générale depuis 30 ans.
Par exemple les instructions 3DNow ont été supportées par AMD pendant plus d'une douzaine d'années depuis le K6-2.
Un logiciel compilé avec 3DNow en 1998 fonctionnera aussi bien sur un K6-2 de l'époque que sur un Xeon Phi x200 ou un Core 2 Duo. La différence c'est que sur le K6-2 c'est le chemin 3DNow! qui sera pris dans le code, alors que sur les deux autres ça sera un chemin avec des instructions non optionnelles.

Mais oui le SSE est optionnel avec un chemin séparé et des tests, le Pentium III d'il y a 20ans c'est vraiment trop moderne

Le SSE est le seul chemin supporté sur les noyaux Linux AMD64/x86 depuis des années pour remplacer la FPU x87 (une affaire de OoO vs. stack-based qui créé des dépendances), tu sais Linux et le HPC, bien que tu sembles croire que la compatibilité Windows est ce qui est intéressant dans ce cas...

Ton argumentaire ne se tient pas, ce qui était dit en 2014 est encore valable: incompatibilité binaire dans les deux sens (cf. page 21 et l'ensemble du document) et nécessité de recompiler spécialement pour les Xeon Phi depuis un langage de haut-niveau (et uniquement dispo via les outils Intel) puisque aussi incompatible que l'est une CPU ARM et son unité Neon dans les faits.

Ce message a été modifié par iAPX - 9 May 2019, 22:22.

[Ambroise]

Ton argumentaire ne se tient pas, ce qui était dit en 2014 est encore valable: incompatibilité binaire dans les deux sens (cf. page 21 et l'ensemble du document) et

Absolument pas. Ce document fait référence à la première génération des Xeon Phi : des cartes additionnelles de calcul. Il s'agissait de cartes PCIe que l'on ajoutait dans une machine (au même titre que des GPU). Ce sont ces cartes externes dont je parle quand je fais référence à l"extension IMCI incompatible avec AVX. Ces cartes embarquaient leur propre OS (un linux).

Mais la totalité des xeon phi en socket, ceux sur l'arrêt desquels non réagissons, sont des CPU x86 standards. Prétendre qu'un CPU qui permet d'utiliser Windows Server et ses 4000 librairies binaires, n'est pas compatible binairement, est du déni de réalité. Il n'y a pas besoin de recompiler Windows, ou de recompiler Cinebench, ou n'importe quelle application pour que ça fonctionne.

Les Xeon Phi x200 sont des processeurs x86 avec les jeux d'instructions Intel 64, SSE, AVX, AVX2 et AVX-512. Ce sont des archis SilverMont auxquelles ont été ajouté AVX-512.

nécessité de recompiler spécialement pour les Xeon Phi depuis un langage de haut-niveau (et uniquement dispo via les outils Intel) puisque aussi incompatible que l'est une CPU ARM et son unité Neon dans les faits.

N'importe quel compilateur convient.

Je n'ai jamais utilisé Visual Studio pour Xeon Phi mais de nombreuses références montrent qu'il est utilisé (ce qui est normal vu que c'est un CPU x86 100% standard).

Avec gcc ou clang on peut optimiser le code pour le Xeon Phi en précisant l'option "-march=knl" (ou -march=native). Dans ce cas, gcc générera du code utilisant les instructions suivantes :

" MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, AVX512F, AVX512PF, AVX512ER and AVX512CD instruction set support." (cf https://gcc.gnu.org/onlinedocs/gcc/x86-Opti...ml#x86-Options)

[DonaldKwak]

Enfonçons le clou c'est incompatible binairement

Les premiers Xeon Phi étaient bien incompatibles binairement avec les x86-64. Par contre, les Xeons Phi Knights Landing (KNL) l'étaient.