Linux : une future séparation des builds selon les modèles de CPU ? |
————— 19 Août 2021 à 08h38 —— 13291 vues
Linux : une future séparation des builds selon les modèles de CPU ? |
————— 19 Août 2021 à 08h38 —— 13291 vues
Si vous installez Linux sur une nouvelle machine — par exemple via un certain tutoriel de comptoir —, alors le noyau que vous utilisez est très probablement directement issu d’une compilation unique effectuée par les mainteneurs de ladite distribution. En un mot, quel que soit votre CPU, vous faites tourner in fine la même chose. Cela pourrait sembler logique, mais ce serait oublier que, au fil des années, les processeurs ont progressé, et sont notamment capables de comprendre de nouvelles extensions du jeu d’instruction x86 initial.
Or, si vous utilisez le même binaire pour tout le monde, alors il faut sacrifier ces améliorations au profit de la rétrocompatibilité, quitte à y perdre, au passage, des performances. Cela devrait être amené à évoluer, car un ensemble de patchs vise à autoriser l’utilisation de davantage d’extensions x86 selon le feature level de votre CPU, déchiffré dans le tableau suivant :
Feature set | Extensions | Quels CPU? |
---|---|---|
x86-64 | SSE2 | Tous ! |
x86-64-v2 | SSE3/SSE4.1/SSE4.2/ SSSE3 | Après Nehalem |
x86-64-v3 | AVX/AVX2/BMI2/FMA | Après Haswell |
x86-64-v4 | AVX-512 | Après Skyake-SP/Icelake |
Pour autant, cela ne signifie pas que les processeurs récents verront une aération gigantesque, car les améliorations ne sont, finalement, que celles automatiquement appliquées par le compilateur, alors que le noyau est principalement composé de code non régulier, empêchant diverses optimisations telle la vectorisation automatique efficace. Certes, Linux contient déjà des directives spécifiques à certains processeurs, mais ce dernier est limité, a été écrit à la main et ne concerne que des routines d’initialisation spécifiques ou des correctifs logiciels de bugs matériels. Par design, ce code n’est par ailleurs jamais ou rarement expulsé du tronc commun, et est donc présent sur tous les binaires distribués (bien que désactivé), sans compter les éventuels appels de bibliothèques dynamiques, pouvant, eux, fortement être modifiés en fonction de l’architecture hôte... ou pas ! À voir dans un futur test ce qu’il en retourne au niveau des performances ? (Source : Phoronix)
![]() | Un poil avant ?La bêta de Diablo 2 Resurrected testée, ça farte ? | Un peu plus tard ...NVIDIA signe un 2nd trimestre monstrueux (et record, of course) ! | ![]() |
|
La première fois que j'avais compilé le noyau Linux, c'était novembre 1993. Juste pour que mon PC puisse prendre en compte ma carte I/O qui ajoutait 2 autre ports série RS232, et ainsi profiter de 4 ports série pour connecter 4 terminaux et tester une configuration sur mesure pour un client.
Grace à la compilation du noyau, le client a acheté une machine à ~10.000F au lieu d'une machine à plus de 50.000F proposé par IBM ou Olivetti.
Mais j'avais lu un article chez Phoronix, que la compilation du noyau n'augmentait que 2 ou 3% les performances en utilisation de tous les jours.
Par contre de mon expérience compiler le noyau pour utiliser de manière native certain gestionnaire de système de fichiers, augmente significativement les performances pour les bases de données.
@++