L’an dernier, Intel et AMD s’associaient pour officialiser le x86 Ecosystem Advisory Group, une initiative dans le but d’élaborer conjointement des standards à destination des futurs CPU x86 — probablement du fait d’un Arm biglouchant un peu trop sur les marchés laptop et serveur au goût des — habituellement concurrents — géants bleus et rouge. Un projet sacrément pertinent aux yeux des programmeurs, tant les interfaces ont pu différer dans le passé (citons par exemple les appels systèmes 32-bit, utilisant pour chaque vendeur des instructions différentes aux syntaxes qui leur sont propres — on adore).
À l’occasion de son anniversaire, le groupement dresse son bilan : 3 extensions préexistantes ont été passées en revue, à savoir FRED, un mécanisme plus léger pour la gestion des interruptions ; l’AVX-10, une version modernisée et unifiée des extensions vectorielles AVX2 et AVX512 ; et AMX, qui rajoute des capacités matricielles aux CPU — vous sentez venir la douce odeur de Machine Learning !
Ce n’est pas tout, puisqu’une nouvelle spécification est également rendue publique : ChkTag (prononcez, "Check Tag"), vendue comme "une extension unifiée de tag mémoire". L’idée derrière tout cela est de combattre les bugs liés à la gestion de la mémoire (dépassement de buffer ou utilisation après libération), des erreurs courantes en programmation, qu’il s’agisse de simples applications utilisateur comme des systèmes d’exploitation, des micrologiciels UEFI ou des hyperviseurs. Dans le monde des serveurs ou la sécurité et la stabilité sont recherchés à tout prix, l’argument a de quoi faire mouche. Reste encore à savoir ce que ChkTag peut bien apporter côté hardware, et le groupe ne fait pas dans le détail le plus poussé. En effet, ce dernier communique uniquement sur une accélération matérielle de la détection de ces erreurs (peut-être une faute de page plus légère, ou plus facilement configurable, ou encore de nouvelles instructions d’accès mémoire travaillant à un grain plus fin que la page), et ce à la granularité de l’instruction. Dans un flou toujours aussi artistique, cette extension sera accessible via le biais d’intrinsèques et d’optimisations des compilateurs, voire de nouvelles fonctionnalité au niveau des langages — ce qui est au passage le cas de bon nombre d’extension, puisque le compilateur est justement le maillon entre code et langage assembleur, compris par le processeur.
Bref, tout cela est certes encore imprécis, mais fortement encourageant : voir les deux acteurs du x86 annoncer une collaboration commune était prometteur ; avec les débuts d’une spécification commune, l’alliance semble porter ces fruits. Reste que ChkTag n’existe à l’heure actuelle qu’au format texte, le temps sera encore long — quelques années à minima — avant une prise en charge logicielle… et encore quelques années de plus pour une arrivée sur le matériel, si la réception de ladite extension s’avère favorable. Ce que nous souhaitons, tant la question de la sûreté mémoire demeure d’actualité !
Savez vous quand l'avx 10 sera pris en charge dans les cpu grand public d'amd et d'intel ?
intel parle de l'avx 10 depuis quelques années mais j'ai pas l'impression que c'est pris en charge.
Ça serait ™️ pour Nova Lake
chez amd zen 6 ou 7?
Pas d'infos :/
autre question:
Est-ce qu'avx 10 aura un intérêt pour les joueurs ou l'utilisateur lambda versus l'avx12 et l'avx 512 ?
Merci d'avance.
Pour l'émulation c'est très cool il parait (je n'ai pas encore compris pourquoi, pour être honnête), pour le reste non. De toute manière il faut attendre longtemps ou avoir recours à des bibliothèques spécialisé pour utiliser l'AVX-512 pour des raisons de compatibilité ; il y a donc peu de chances que ce soit utilisé en jeu (et encore moins pour que ça ait un réel intérêt dans la majorité des cas si tu veux mon avis).
Les émulateurs ps3 sont plus rapide grâce a l avx 512
Ils proposent donc un projet d'extension qui n'est même pas encore en place sur leur puces, et s'attendent à une prise en charge par les compilo, avant même que ça n'existe sur leur proc? 🤨
Toujours. Si le proco sort avec une extension qui n'est pas prise en charge par les compilos ni aucune bibliothèque, je ne lui donne pas une grande durée de vie car personne ne l'utilisera.
Le cycle standard c'est draft -> spécification / compilos (parfois simu) -> implémentation dans les CPU. Il faut que le support soit près avant la sortie des puces ; et il faut avoir eu des retours des programmeurs avant la spec finale. Par exemple, le support d'AVX10 a commencé dans GCC en... août 2023 avec un premier technical paper, suite à une annonce fin juillet (et probablement un sacré travail préliminaire en sous-marin) ; et une première spec en juillet 2024. On attend toujours les premiers CPU compatibles :)
Un compilo, ça se met à jour plus facilement qu'un proc. Le support de nouvelles fonctions non bloquantes pourraient très bien sortir plus tard, au fur et à mesure. Mais bon, si ils ont choisi de fonctionner comme ça...
En même temps, c'est souvent les ingé Intel/AMD qui s'occupent de patcher les outils open sources (voir closed sources), non?
Les 3 jeux d'extensions passé en revue viennent tous de chez Intel. AMD n'a encore rien apporté?
Oui, mais une extension doit être prise en charge par le compilo pour être utile en pratique, et on ne se rend compte de certains problèmes qu'à l'implémentation. En plus, le support compilo / bibliothèques au lancement permet de montrer l'intérêt de l'extension et en faire une argument de vente. Le RISC-V fait pareil, avec des tas de spécifications dans tous les sens et très très peu de design (voir aucun pour certains draft).
Effectivement, ce sont les ingés des boites du hards qui font la majeure partie du support soft open source. AMD doit en avoir moins, je n'ai pas d'info quand à sa participation.