Suport technique et veille technologique

LinuxFr.org : les journaux  -  Le début de la fin pour Intel ?

 -  Septembre 2020 - 

Sommaire

• • 1. Apple lâche Intel, mais on le savait
  • 2. François PiedNoël : How to fix Intel ?
  • 2.1. Un petit point sur AVX512
  • 3. Lakefield : porte de sortie ?
  • 4. La fin de la nécessité du Out of Order ?
  • Conclusion

Apple a récemment officiellement annoncé ce qui se tramait depuis longtemps : les Macbook vont passer sur architecture ARM. Vous allez me dire que vous vous en fichez, puisqu'Apple cédéméchan çapucépalibre.
Mais des signaux plus ou moins faibles indiquent ça et là qu'Intel est mal barré.
Exposé des faits

1. Apple lâche Intel, mais on le savait

Les rumeurs sur le lâchage d'Intel par Apple bruissait depuis longtemps. Qui plus est, l'utilisation de plus en plus fréquente de leur propres puces ARM sur les segments les plus bénéficiaires de marché pour la pomme indiquait le chemin.
Depuis l'officialisation, on a appris que le mouvement est venu d'en bas. En effet, dû à des gros bugs chez Intel SkyLake, les ingénieurs d'Apple ont eu envie de switcher : ils trouvaient autant de bugs que les ingénieurs d'Intel. C'est balo… Et ça la fout mal quand même. Ça me rappelle une appli développée par une SSII.
Ce sont eux qui ont frais pression sur la direction, en mode "c'est plus possible". Ils ont finalement eu gain de cause.
Ce switch ne va pas changer grand chose pour Intel en terme de carnet de commande : les CPU du Mac équivalent à à peine 12% du marché PC voire moins. Le gros des marges d'Intel, ce sont les datacenters avec un marché qui s’agrandit chaque année (+40% en un an).

D'après Jean-Louis Gassée, ancien de la firme à Wozniak, c'est mal barré pour Intel, car si les précédentes tentatives de Switch par Microsoft ce sont soldées par un échec, celle-ci est de loin bien mieux préparée. Car c'est essentiellement l'émulation x86 sur ARM qui pose problème : Microsoft comme Apple use de cet artifice pour faire marcher les applis x86 sur des machines ARM. Mais dans le cas de la surface X, que Microsoft a mis sur le marché, j'ai un peu de mal à comprendre pourquoi ils n'ont pas tout simplement recompilé la suite Office, qui était affreusement lente à cause de l'émulation. Car c'était en effet une émulation du type JIT, et c'est de là que leurs problèmes sont venus.
De son côté le switch pommesque, préparé de longue date, et l'"émulation" d'applis x86_64 sur ARM, Rosetta 2, a l'air d'avoir d'excellentes performances.. Pour une raison simple : c'est un compilateur, pas un JIT.
Quelques benchmarks agitent le landerneau et laissent à penser que même via Rosetta 2, les performances ne seront pas horribles : on se retrouve au coude à coude avec un Macbook Air.
Qui plus est, les Mac pourront exécuter toutes les applis de l'écosystème Apple, iPhone compris.

Apple a pris le temps de maitriser son architecture ARM tranquillement et d'avoir des apps qui fonctionne sur son système, comme les apps sont dans l'écrasante majorité développées avec Xcode, une simple recompilation suffira.
Je pense que c'est cela qui assurera leur succès.

2. François PiedNoël : How to fix Intel ?

Ancien "Performance Guru OF Chipzilla" aka ingénieur principal d'Intel, un français qui a participé et conçues toutes les archis Intel x86 de 1997 à 2017 pense qu'Intel va dans le mur résumé ici vidéo là
Plusieurs éléments ressortent de sa passionnante présentation d'une heure avec son accent français à couper au couteau :

• L'AVX512 est une mauvaise idée, il prend 10% du die pour rien, car très peu utilisé. Cette approche ultra-vectorielle a perdu contre celles des GPU. En même temps quand on voit la gueule des instructions, on comprend, je préfère me prendre la tête à coder du GPU. J'ajouterai qu'avec des langages comme Futhark, la palanquée de libs existante pour les GPU, le match est perdu d'avance. Autant réserver 10% du die à mettre un petit GPU pour exécuter de l'OpenCL…. Qui plus est l'AVX512 est décliné partout, des processeurs pour portables à ceux des datacenters. Il y a fortement à parier qu'il n'est jamais utilisé.
• Utiliser AVX512 dans des puces grand publics, portable en particulier là où il n'est que rarement utilisé est stupide en terme de rendement énergétique
• Linus a déclaré, avec son franc-parler habituel : « J'espère que l'AVX512 mourra d'une mort douloureuse, et qu'Intel commencera à régler les vrais problèmes au lieu d'essayer de créer des instructions magiques pour ensuite créer des standards sur lesquels ils pourront se reposer »
• Intel réduit ses fréquences d'horloge à cause d'AVX512 (voir plus loin)
• Les dirigeants d'Intel ne sont plus des ingénieurs mais des MBAs, d'après Piednoël, ils ne comprennent plus rien au marché. Les employés sont démotivés.
• Pendant qu'Intel a été occupé à acheter des startups, AMD a eu le temps de progresser, et les derniers Ryzen sont excellent.
• Intel ne se fait pas défoncer par AMD à cause des capacités limitées d'AMD en production, dépendant qu'ils sont de TSMC
• Skylake a été conçu pour le monothread puis ensuite amélioré pour le multicoeur au fur et à mesure.

J'ajoute que AMD, ayant les archis Radeon à disposition peuvent vraiment faire du mix CPU/GPU, même s'ils sont à la traine derrière NVidia.

2.1. Un petit point sur AVX512

Quand on creuse un peu, on se rend compte que l'AVX512 n'est pas anodin pour le processeur, l'utiliser l'oblige à changer de fréquence et de voltage
C'est bien expliqué ici (traduction libre) :

On paie un coût pour [l'AVX512] dans le sens où la fréquence baisse si on exécute beaucoup de code AVX[…] Le problème avec les horloges AVX2 / AVX512 avec Intel n'est pas le fait qu'elles doivent cadencer plus bas pour les utiliser (pour du code AVX pur, traiter plus de données mais à une vitesse d'horloge inférieure en vaut toujours la peine !), C'est que le processeur doivent cadencer plus bas préventivement pour de telles instructions, et doit rester à cette fréquence inférieure pendant un certain temps. Cela signifie que le code qui s'exécute de temps en temps avec quelques instructions AVX mélangées avec beaucoup de code entier doit exécuter l'ensemble du programme à des fréquences inférieures.
En revanche, AMD gère l'alimentation de sa puce à partir d'un énorme MIMCAP (Metal Insulator Metal capacitor NDR) intégré à la puce, ce qui signifie qu'ils ont une marge pour pouvoir commencer à exécuter des instructions extrêmement gourmandes en énergie, et ne synchroniser de manière réactive que si cela est réellement nécessaire. Et gère le changement de fréquence à la baisse et la hausse avec une granularité beaucoup plus fine, et de manière beaucoup plus réactive.

Ceci est constaté avec des Benchs montrant qu'AVX2 a tendance à faire baisser les perfs générales du processeur quand on l'utilise conjointement avec autre chose.

3. Lakefield : porte de sortie ?

Intel essaie tout de même de trouver sa voie : les MBAs dirigeant la boite ont décidés de se concentrer sur l'architecture Lakefield qui est une application big.LITTLE d'ARM : des cœurs orienté perfs à côté de cœurs orienté économie d'énergie (issu des architectures Atom). Avec cette nouvelle architecture, Intel inaugure avec ce processeur le passage à la 3D sur la gravure : 12x12x1mm (!) d'épaisseur.
Il possède pas mal de features qu'on trouve sur des processeurs ARM pour mobile : Wifi/4G intégrée, GPU avec gestion d'écrans (4) 4K, gestion de caméras, fréquence variant de 0,8Ghz à 2,8Ghz, et il comportera aussi… sa propre RAM.
L'histoire ne nous dis pas s'il y a AVX512 ;-)
Tout cela va être empilé sur un die, permettant d'éviter une carte mère complète.

4. La fin de la nécessité du Out of Order ?

C'est une conviction que j'ai depuis longtemps : les incantations vaudou sur le code alors les compilateurs sont capable parfaitement capables d'optimiser eux-même le code (ceux qui me connaissent de longue date ici connaissent mon passé à ce propos) vont forcément disparaitre un jour, et plus que les avancées de GCC, du Intel C Compiler, c'est surtout Clang à mon sens, qui est en train de tuer la nécessité de tuer le Out Of Order : les compilateurs deviennent assez malin, on a assez de puissance de calcul pour optimiser au mieux le code et précalculer les dépendances read-after-write.
C'est aussi l'avis de F. Piednoel, qui partage cette opinion lorsque je la lui ai exposé.
À moins que tous les sites codées en NodeJS sauvent Intel ? X-D
Mais peut-être certains d'entre vous auront des avis divergents sur ce point, ça m'intéresse ;-)

Bref, m'est impression que les x86 d'Intel, descendant directs des archis Pentium, consomment énormément de transistors à descendre les IPC à moins de 1, avec le out of order, les multiples unités d'exécutions, les multiples niveaux de pipelines qui ont conduit à l'échec du Pentium 4 (20 étages !). Or tout cela, avec la progression des compilateurs va devenir de plus en plus inutile. Intel y a cru pourtant, avec Itanium, mais c'était trop tôt, et l'archi état trop complexe (VLIW)

Conclusion

A l'heure où les IPC sont autour et en dessous de 1 depuis longtemps, quel point de salut en dehors du massivement multi-coeur ?
Est-ce qu'ARM va tous nous bouffer ? Enfin celui à qui il va appartenir (NVidia ?)
Comment Intel va t-il se sortir de ce guêpier ? Sachant que pour le marché des datacenters, avec la fin de la nécessité du out of order, qu'auront-ils à offrir face à AMD ?

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Ontologia