ARM met plus de vectoriel dans ses futures puces, Réactions à la publication du 24/08/2016

[Lionel]

Les plus anciens ici se souviennent certainement du processeur G4. Il se démarquait du G3 grâce à ses instructions vectorielles Altivec, qui accéléraient énormément le traitement de certaines données, ce qui lui a permis de passer devant le G3.
Intel en a aussi dans ses processeurs sous la dénomination AVX. Chez Intel ces jeux d'instructions sont plus complexes que ne l'était l'Altivec.

L'intérêt de ces instructions vectorielles est de pouvoir réaliser simultanément certains calculs. Ainsi (en résumé) il est possible de traiter 4 données 32 bits en même temps avec une instruction vectorielle 128 bits. La plupart des processeurs Intel utilisent de l'AVX 256 bits. Le fondeur commence à proposer sur certains de ses processeurs de l'AVX 512 bits.

Pour en revenir au sujet de la brève, ARM exploite aussi des instructions vectorielles appelées NEON. Elles n'ont toutefois pratiquement pas évolué en profondeur depuis fort longtemps, avant le premier iPhone.

Les choses vont changer. ARM a annoncé son nouveau jeu d'instructions vectorielles appelé SVE, pour Scalable Vector Extension.

Sur le papier, cela devrait apporter un gain très significatif dans certains types de traitement. C'est d'autant plus vrai qu'ARM va fournir un canevas SVE très lâche. Il sera en effet possible de créer des instructions (ou plutôt des designs de transistors) allant de 128 à 2048 bits, de quoi alors traiter dans ce dernier cas 64 instructions 32 bits en même temps.

Assez clairement, cette initiative va permettre à ARM de tenter de séduire le monde des supercalculateurs, qui commence déjà à travailler avec ses puces.

Avec un peu de chance, la montée en puissance des puces ARM devrait aussi convaincre Intel de se relancer dans une course à la puissance dont la société n'a plus besoin, ayant une marge d'avance plus que confortable sur AMD.

Lien vers le billet original

[raoulito]

conclusion: ben quand la course à la puissance s'essouffle, on en revient aux bon vieux copro ou a leur version moderne : les instructions vectorielles..
je dis une bêtise?

[iAPX]

Intel est a sa troisieme generation d'instruction vectorielles (si on oublie le vectoriel implicite d'un AND ou OR entre des vecteurs de booleens, deja supporte des le i4004!): MMX, SSE, AVX & AVX2. SSE4 ayant beneficie du travail d'Apple et de son experience avec les instructions Altivec des PowerPC G4 et suivants!)
Intel est un peu coince sur les super-calculateurs et n'arrive pas a convaincre avec les Xeon Phi: leur rapport performance/watt est inferieur aux cartes Pro de nVidia, cuda semble etre prefere aux outils d'Intel, aucune compatibilite n'existe nativement entre un Xeon Phi et aucune CPU Intel existante (surtout en vectoriel indispensable dans ce cas), donc aucune possibilite de s'acheter une config a 1000$ ou meme 2000$ pour developper et tester, et pire, une efficacite (puissance pratique/theorique) plus faible que nVidia.

Mais les nouvelles generations vont peut-etre changer cela, Intel travaille tres fort ses iGPU pour OpenCL, avec une efficacite totalement inegalee, et des performances dans certains epoustouflantesp our ne pas dire totalement hors-norme face a des cartes qui en 3D sont au moins 3X a 4X plus performantes! Wait and see.

Le vectoriel SVE est interessant a cause de la longueur variable des vecteurs, tres similaire a ce qui a ete implemente par Seymour Cray sur les fameux Cray, avec des unites de taille variable, permettant de garder la compatibilite sur une puce equipee d'une unitee 128bits (l'equivalent du vieux SSE) jusqu'a la possibilite -un jour lointain- d'avoir plusieurs unites 2048 bits. Donc acces a des unites compatibles tres peu cheres a implementer, code compatible avec les puces specialisees et tres cheres (la ca va douiller, 2048bits en vectoriel ca sera pas tout de suite dans un iPod!), des problemes resolus des le design, demontrant encore une fois comme ARM est incroyablement fort dans ce domaine.

Leur proposition evoque pour moi le Xeon Phi: une base de CPU simple affublee d'unites vectorielle tres tres puissantes (512bits pour le Xeon Phi, variable donc chez ARM), on peut dont prevoir qu'ils vont sortir quelque-chose capable d'aller concurrencer celui-ci a moyen-terme.
Mais je ne donnerais pas ARM gagnant, l'aspect logiciel est extremement important (les outils, librairies, etc), ce qui donne a cuda un gros avantage par rapport a Intel actuellement, et outre ca, ils ne sont pas dans le domaine des HPC encore, il y a du chemin a parcourir la-dessus. Un dernier point sont les interfaces memoires relativement lente des CPU ARM, historiquement, car pour une puce tres efficace il faut un gros cache (donc une puce grosse et chere) et une interface memoire tres performante, avec au moins 4-canaux DDR3 (ou mieux DDR4), par puce.

PS: +1 Raoulito, et des unites dediees sur la puce comme pour AES par exemple, ou l'encodage/decodage video hard ou hard+soft, et meme des unites qui sont eteintes quand on ne les utilise pas (comme AVX2), qu'on appelle du "Dark Silicium" car en general aucun courant n'y passe

Ce message a été modifié par iAPX - 24 Aug 2016, 17:49.

[Sethy]

Lionel, petit lapsus : 64 données de 32 bits simultanément. En effet, pour autant que je ne me trompe pas le principe est d'appliquer la même instruction à plusieurs données en même temps.

[malhomme]

ahhhhh Altivec.
Ca permettait de trainer dans la poussière n'importe quel PC, et d'avoir de très bonnes performance en audio.
J'ai adoré mon g4 :-)

[velvia]

@iAPX: Tu travailles sur quoi pour connaitre si bien le HPC?

Concernant le match Tesla/Xeon Phi, il est vrai que NVidia a une base materielle/logicielle plus avancée. Il ne faut pas oublier que le premier "vrai" Xeon Phi (Knights Landing) a été lancé en juin 2016 et encore très peu de personnes y ont accès. La première version (Knights Corner) n'a rien à voir et était simplement là pour faire patienter.

Ce match se fera surement sur le type d'algorithme. Sur des accès mémoire réguliers, la carte Tesla va gagner. C'est le cas sur les algos de Deep Learning où le bottleneck est le calcul de produits de convolution. Sur des algos où l'accès mémoire est moins régulier, je pense que le Xeon Phi aura un avantage. J'aimerai bien voir un benchmark sur la résolution directe d'un système creux par exemple.

Attention, chez NVidia, il n'existe pas toujours des configurations de base pas cher pour développer. Si on veut faire du calcul sur des flottants 64 bits (double) même une Titan X Pascal est à la rue.

ARM sur serveur pourrait être un allié de choix pour NVidia sur le long terme car je vois mal Intel aider NVidia sur certains points, par exemple contourner le bus PCI pour accéder à la mémoire. Le NVLink permet actuellement de connecter des GPUs ensembles mais pas de connecter le GPU au CPU sur une plateforme Intel.

[iAPX]

@iAPX: Tu travailles sur quoi pour connaitre si bien le HPC?
...

Je suis juste un observateur du match actuel IBM+nVidia vs Intel (on s'entend qu'AMD est largué et pour longtemps dans le HPC aussi!)

Je fais du GPGPU depuis près de 10ans (un hasard, une GeForce 8800 GTS l'originale en 384Mo dans un PC acheté d'occase), en cuda puis maintenant surtout OpenCL, et j'ai des amis qui sont franchement dans le monde du HPC, notamment en R&D chez AMD.

Ce message a été modifié par iAPX - 25 Aug 2016, 13:06.

[Hebus]

@iAPX: Tu travailles sur quoi pour connaitre si bien le HPC?
...

Je suis juste un observateur du match actuel IBM+nVidia vs Intel (on s'entend qu'AMD est largué et pour longtemps dans le HPC aussi!)

Je fais du GPGPU depuis près de 10ans (un hasard, une GeForce 8800 GTS l'originale en 384Mo dans un PC acheté d'occase), en cuda puis maintenant surtout OpenCL, et j'ai des amis qui sont franchement dans le monde du HPC, notamment en R&D chez AMD.

Tu fais du OpenCL sur ton MBr, ? Je n'ai pas encore essayé de voir, restant pout l'instant à étudier Metal. J'ai un peu peur que le support OpenCL par Apple soit mort et Intel ne donne pas de toolkit pour macOS, je n'ai vu que Linux et Windows...

[iAPX]

@iAPX: Tu travailles sur quoi pour connaitre si bien le HPC?
...

Je suis juste un observateur du match actuel IBM+nVidia vs Intel (on s'entend qu'AMD est largué et pour longtemps dans le HPC aussi!)

Je fais du GPGPU depuis près de 10ans (un hasard, une GeForce 8800 GTS l'originale en 384Mo dans un PC acheté d'occase), en cuda puis maintenant surtout OpenCL, et j'ai des amis qui sont franchement dans le monde du HPC, notamment en R&D chez AMD.

Tu fais du OpenCL sur ton MBr, ? Je n'ai pas encore essayé de voir, restant pout l'instant à étudier Metal. J'ai un peu peur que le support OpenCL par Apple soit mort et Intel ne donne pas de toolkit pour macOS, je n'ai vu que Linux et Windows...

Oui justement, j'avais vu les benchs tres etrange entre les 2015 et 2016 (SkyLake), en OpenCL, avec une augmentation de bande-passante memoire de 60 a 70%, le meme code pouvait prendre plus de 100%, ce qui m'en a fait prendre un 2016, et je confirme qu'on voit pas la difference cote 2D (ou plutot 2.5D pour l'interface d'OS X), meme avec un ecran 4K, mais qu'en OpenCL c'est incroyablement different.

Je ne suis pas alle analyser en detail, mais je suppute un gros changement d'architecture, un peu l'ordonnanceur, pas mal les unites de calcul (le calcul entier a fait un bond en avant incroyable, tient ca fait penser a une difference entre AVX et AVX2 justement), et surtout la quantite de registres diponibles a du probablement doubler.
L'effet du nombre de registre physique augmente (ou eventuellement augmentation du cache mais j'y crois pas), ca ne se voit pas sur les algos les plus simples, mais des que tu as du code long, complique avec une grosse conso de registres, ca enleve un gros goulot d'etranglement, forcement ca diminue la pression sur le cache et tout le sous-systeme memoire en general.

Une caracteristique que j'ai vu depuis le vieux G92, c'est que generation apres generation le code possible est devenu plus complexe, avec plus de registres utilisables, des meilleurs perfs en Integer, etc.
Ce qui se traduit, que ca soit chez nVidai, AMD ou Intel, par une efficacite qui n'augmente pas enormement sur les traitements simples (allez une FFT de base), mais en revanche une efficacite de plus en plus importante poru les traitements complexes comme mes moteurs d'echecs (voir la simple possibilite de les faire tourner sans crasher!), a l'exception de Kepler bien sur (regs et caches reduit par thread!).
Et je pense qu'Intel avec ses iGPU SkyLake est tres tres largement devant AMD et meme nVidia en terme d'efficacite sur du code complexe (qui n'aurait simplement pas pu tourner il y a 10ans sur GPU), alors que la 3D progresse bien moins, et que ca demontre une orientation vers le GPGPU (et peut-etre pas uniquement OpenCL!) de la part d'Intel.

Ils n'ont d'ailleursp as communique du tout sur des changements d'architecture GPU en Compute sur SkyLake, alors que les resultats sont la et n'importe quelle compagnie aurait fanfaronne partout. Ca me parait tellement etrange!

Ce message a été modifié par iAPX - 25 Aug 2016, 17:23.

[Ambroise]

SSE4 ayant beneficie du travail d'Apple et de son experience avec les instructions Altivec des PowerPC G4 et suivants!)

??? SSE4 ce sont des instructions basées sur du shuffle et un troisième opérande implicite : quel rapport avec Altivec ?

aucune compatibilite n'existe nativement entre un Xeon Phi et aucune CPU Intel existante (surtout en vectoriel indispensable dans ce cas)

Non. Il y a une totale compatibilité binaire avec les Xeon Phi KNL. Ce sont des x86 standards. Non seulement ils executent nativement les anciens codes AVX sur 288 threads, mais ça fait longtemps que l'on trouve des libs en AVX-512 développées avec Intel SDE.

[iAPX]

SSE4 ayant beneficie du travail d'Apple et de son experience avec les instructions Altivec des PowerPC G4 et suivants!)

??? SSE4 ce sont des instructions basées sur du shuffle et un troisième opérande implicite : quel rapport avec Altivec ?

aucune compatibilite n'existe nativement entre un Xeon Phi et aucune CPU Intel existante (surtout en vectoriel indispensable dans ce cas)

Non. Il y a une totale compatibilité binaire avec les Xeon Phi KNL. Ce sont des x86 standards. Non seulement ils executent nativement les anciens codes AVX sur 288 threads, mais ça fait longtemps que l'on trouve des libs en AVX-512 développées avec Intel SDE.

Pour SSSE4 je ne vais pas argumenter, regarde AltiVec

Pour un Xeon Phi, ça veut dire que je prends une distribution Linux x86-64 (AMD64 en fait, avec du SSE en 2016 au lieu du fpu x87) standard et elle s'installe dessus?
Windows 10 (et je ne parle pas d'accéder à une carte Xeon Phi via ssh, mais bien d'installer Windows 10 dessus, merci!)?
Où es TA compatibilité?
Sûr, Windows 2000 et des vieux logiciels doivent pouvoir tourner (aux limitations Microsoft près sur le nombre de coeurs, etc).
Que certaines instructions soient encodées pareil, on peut s'entendre. Que toutes les instructions soient présentes, d'un coté et de l'autre, encodées de la même façon, et bien non. Il y a un sous-ensemble commun, mais qui oublie AVX & AVX2 pour commencer d'un coté, et bien sûr AVX-512 de l'autre.
Mais comment programmer une machine vectorielle quand elle ne partage pas son jeu d'instruction avec les autres avec lesquelles elle est "compatible"?
Ou alors ton argument s'arrête à pouvoir afficher un écran de bienvenu et faire tourner des vieux logiciels au 1/10eme de la vitesse qu'offre les différentes architectures quand programmées nativement?
Ou avoir un version spécifique de Windows Server 2016 qui est compatible (et différente des autres)?
Si c'est ça ta compatibilité, alors comme Windows NT4 existait pour MIPS et Alpha, alors ce sont des puces compatibles x86?

Ou dit autrement, pour être sérieux:
On ne peut pas programmer un SkyLake AVX2 en assembleur (ou code in-line) aujourd'hui et faire tourner le code binaire sur un Xeon Phi encore.
On ne peut pas faire tourner le code binaire d'un Xeon Phi en AVX-512 sur autre chose qu'un Xeon Phi (hors de prix pour les étudiants et beaucoup de chercheurs!).
Mais tu as raison, on peut faire tourner du code x86 sans AVX2 et AVX-512 sur les deux plateformes, mais où serait l'intérêt?!?

Ce message a été modifié par iAPX - 27 Aug 2016, 16:59.

[Ambroise]

Pour un Xeon Phi, ça veut dire que je prends une distribution Linux x86-64 (AMD64 en fait, avec du SSE en 2016 au lieu du fpu x87) standard et elle s'installe dessus?
Windows 10 (et je ne parle pas d'accéder à une carte Xeon Phi via ssh, mais bien d'installer Windows 10 dessus, merci!)?
Où es TA compatibilité?

Je ne parle pas des cartes coprocesseurs Xeon Phi : il est effectivement difficile de faire tourner un OS sur une carte PCIe ou sur une carte graphique...
Je parle des Xeon Phi en socket : le Xeon Phi x200 par exemple. C'est un CPU x86 complet et standard.

Je n'ai pas eu l'occasion d'essayer de station de travail Xeon Phi pour le vérifier mais il n'y a pas de raison que Windows 10 ne boote pas.
Par contre sur des machines de calcul à base de multiple Xeon Phi KNL, la compatiblité binaire avec des executables pour Xeon (des haswell dans mon cas) est totale.

Sûr, Windows 2000 et des vieux logiciels doivent pouvoir tourner (aux limitations Microsoft près sur le nombre de coeurs, etc).
Que certaines instructions soient encodées pareil, on peut s'entendre. Que toutes les instructions soient présentes, d'un coté et de l'autre, encodées de la même façon, et bien non. Il y a un sous-ensemble commun, mais qui oublie AVX & AVX2 pour commencer d'un coté, et bien sûr AVX-512 de l'autre.
Mais comment programmer une machine vectorielle quand elle ne partage pas son jeu d'instruction avec les autres avec lesquelles elle est "compatible"?
Ou alors ton argument s'arrête à pouvoir afficher un écran de bienvenu et faire tourner des vieux logiciels au 1/10eme de la vitesse qu'offre les différentes architectures quand programmées nativement?

Ils executent du MMX, du SSE, de l'AVX et l'AVX2 en plus de l'AVX-512. Ce sont des processeurs x86 tout ce qu'il y a de plus classique (si on fait abstraction des 260W de TDP).
Chez Supermicro les cartes mères utilisent le classique chipset Intel C612 (classique dans les stations de travail bi-Xeon E5-2x00) et un bios AMI. https://www.supermicro.nl/products/system/t...SYS-5038K-I.cfm

Il ne faut pas confondre avec les unités vectorielles 512 bits des KNC. Les KNC sont des coprocesseurs de calculs qui fonctionnent comme des cartes graphiques (initialement ils avaient même une sortie graphique vestige du temps ou les Xeon Phi s'appelaient Larrabee et devaient être des cartes graphiques d'Intel adaptées au GPGPU) et qui ont leur jeu d'instruction vectoriel expérimental dédié.

On ne peut pas faire tourner le code binaire d'un Xeon Phi en AVX-512 sur autre chose qu'un Xeon Phi (hors de prix pour les étudiants et beaucoup de chercheurs!).

C'est vrai pour n'importe quel nouveau jeu d'instruction. Le Xeon Phi KNL est le premier processeur à supporter l'AVX-512 et il n'est sorti qu'en juin. Il est donc effectivement le seul pour l'instant. Mais dans quelques mois les Xeon Skylake feront également de l'AVX-512.

Et bien sûr que c'est hors de prix pour les étudiants. L'objet de ce Xeon c'est de faire du MIMD sur des centaines de Go de RAM. En un seul cycle d'horloge il peut lancer 144 instructions différentes sur 2304 nombres flottants. Et contrairement à un GPU ces calculs s'effectuent sur de gros volumes de RAM (384Go). ça ne sera pas accessible aux étudiants avant plusieurs années.

[velvia]

Pour un Xeon Phi, ça veut dire que je prends une distribution Linux x86-64 (AMD64 en fait, avec du SSE en 2016 au lieu du fpu x87) standard et elle s'installe dessus?

Oui, le "Xeon Phi Knights Landing" est bien compatible binaire avec le x86-64 (ce qui n'était pas le cas du Knights Corner). Je crois qu'il faut une extension au noyau Linux pour gérer correctement la MCDRAM, mais sinon c'est bien la même distribution qui tourne. J'ai entendu dire que certains avait réussit à faire tourner Windows 10 dessus en bidouillant un peu.

Pour l'AVX-512, ce sera quasiment le même que celui présent sur les Xeon Skylake qui devraient sortir en 2017. Il y a juste quelques différences, mais l'essentiel sera partagé par les deux processeurs. On ne perdra donc quasiment rien à compiler pour la partie de l'AVX-512 commune aux deux plateformes.