A priori je dirais que Linus n'a pas tord. C'est peut-être utile au niveau commercial, mais au niveau de l'OS, l'OS doit savoir précisément ce qui est activé. Si une fonctionnalité d'une version est désactivé, que ce soit par sécurité ou par économie ou pour toute autre raison, on va devoir désactiver toute la série avec les versions alors que sinon, on peut juste désactiver une seule et unique instruction.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
D'après la page wikipedia liée dans l'article: These levels define specific features that can be targeted by programmers to provide compile-time optimizations."
L'idée est donc de fournir une version du cpu sur lequel on va exécuter le code au compilateur. Ce dernier ne peut pas utiliser les bits cpuid parce qu'il n'a aucune idée si le code généré va tourner sur la même machine que le compilateur lui même.
L'option pour faire ça existe depuis très longtemps dans gcc (-march) et configure un ensemble d'instructions utilisables. On peut ensuite affiner avec des options supplémentaires (-msse2 par exemple pour activer l'utilisation sse2). On peut aussi utiliser -march=native pour dire au compilateur de détecter le cpu de la machine de compilation et d'optimiser pour ce dernier (si on est utilisateur de Gento par exemple).
Donc quel est le problème? Le problème est que les valeurs données à l'option -march sont assez arbitraires, souvent des noms de processeurs "représentatifs" (pentium, pentium3, k6, …). C'est difficile de s'y retrouver. Pouvoir dire "x86_64 v3" est plus précis et un fabricant de processeur peut clairement identifier si un processeur est compatible avec une telle spécification. Ce qui bien sûr n'empêche pas de proposer des options qui ne seront "de base" que dans les générations suivantes (ou peut-ètre jamais), et de fournir les bits cpuid pour tout ce qui peut être décidé à l'exécution (pas à la compilation).
# Et pour la discussion sur phoronix
Posté par cosmocat . Évalué à 5 (+3/-0).
https://www.phoronix.com/news/Torvalds-Mind-Fart-x86_64-Level
# +
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
A priori je dirais que Linus n'a pas tord. C'est peut-être utile au niveau commercial, mais au niveau de l'OS, l'OS doit savoir précisément ce qui est activé. Si une fonctionnalité d'une version est désactivé, que ce soit par sécurité ou par économie ou pour toute autre raison, on va devoir désactiver toute la série avec les versions alors que sinon, on peut juste désactiver une seule et unique instruction.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Ou est le problème?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
D'après la page wikipedia liée dans l'article: These levels define specific features that can be targeted by programmers to provide compile-time optimizations."
L'idée est donc de fournir une version du cpu sur lequel on va exécuter le code au compilateur. Ce dernier ne peut pas utiliser les bits cpuid parce qu'il n'a aucune idée si le code généré va tourner sur la même machine que le compilateur lui même.
L'option pour faire ça existe depuis très longtemps dans gcc (-march) et configure un ensemble d'instructions utilisables. On peut ensuite affiner avec des options supplémentaires (-msse2 par exemple pour activer l'utilisation sse2). On peut aussi utiliser -march=native pour dire au compilateur de détecter le cpu de la machine de compilation et d'optimiser pour ce dernier (si on est utilisateur de Gento par exemple).
Donc quel est le problème? Le problème est que les valeurs données à l'option -march sont assez arbitraires, souvent des noms de processeurs "représentatifs" (pentium, pentium3, k6, …). C'est difficile de s'y retrouver. Pouvoir dire "x86_64 v3" est plus précis et un fabricant de processeur peut clairement identifier si un processeur est compatible avec une telle spécification. Ce qui bien sûr n'empêche pas de proposer des options qui ne seront "de base" que dans les générations suivantes (ou peut-ètre jamais), et de fournir les bits cpuid pour tout ce qui peut être décidé à l'exécution (pas à la compilation).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.