Donc, d'un côté, on a un mini-consortium composé d'au moins 4 acteurs majeurs qui décident d'un truc en commun. De l'autre, on a un gars tout seul qui rejette sous prétexte qu'il trouve ça stupide.

Qu'il ne souhaite pas l'intégrer dans Linux, c'est son problème. Si d'autres décident de l'adopter (en premier, les compilateurs), il ne pourra rien y faire.

Surtout que le CPUID, c'est du runtime. Le niveau, cela à l'air plus d'être quelque chose de statique défini à la compilation...

Je pense que techniquement, il a raison puisqu'on a au moins un exemple qui prouve qu'un classement par chronologie de marche pas : les instructions AVX-512 citées dans la brève.

Le côté chronologique, c'est Linus qui semble l'introduire.

De base, cette classification ne semble pas être axée dessus. Bien sûr, v1 vient avant v2, qui vient avant v3 qui vient lui-même avant v4. La dessus, je pense qu'on peut être d'accord.

Maintenant, je pense qu'il faut voir ce que ces niveaux représentes pour ce qu'ils sont. Le v1 par exemple, ne représente pas des jeux d'instructions vieux, mais des jeux d'instructions considérés comme la base (aujourd'hui, on n'imagine pas un processeur sans FPU par exemple).

Les niveaux suivants viennent ensuite enrichir chaque niveau précédent de nouvelles instructions. Bien évidement qu'il va y avoir un ordre peu ou prou chronologique, car les jeux d'instructions sortent au fur à et mesure.

Regrouper des jeux d'instructions "d'une même période" au sein d'un même niveau, est-ce si déconnant que ça ?

Qui plus est, cela permet de gérer plus facilement la compatibilité du matériel. Tout processeur compatible d'un niveau N peut être remplacé par un processeur d'un niveau équivalent ou supérieur.

Enfin, je rajouterai que regrouper les jeux d'instructions selon différents ensemble, cela permet également de s'assurer de pouvoir utiliser ensemble des jeux d'instructions. Si ça se fait plutôt bien à la compilation via les options, c'est un peu plus difficile de gérer ça au runtime en se basant sur le CPUID, car cela peut entrainer une complexité calculatoire si tu veux faire tous les cas.

Qui plus est, je vois un avantage pourtant certains pour le noyau linux : les modules. Avoir un module compatible avec tel ou tel niveau permettrait de s'assurer que le module fonctionne pour tous les processeurs compatibles avec un niveau spécifique ou supérieur, sans avoir besoin de le recompiler pour chaque architecture spécifiquement (ce qui est le cas aujourd'hui).

Car oui, la notion de niveau est aussi un moyen d'assurer une compatibilité avec les processeurs à venir, en "forçant" l'inclusion de jeux d'instruction de niveaux inférieurs, sous peine d'avoir un processeur qui soit limité en terme de niveau.

Après, il fait du Linus sans une once de diplomatie comme trop souvent.

C'est un peu ce que je lui reproche. Je ne nie pas qu'il a fait beaucoup pour l'informatique (rien que Git et Linux, c'est déjà énorme). Mais il n'est pas non plus obligé de se montrer aussi dénigrant. Il me semblait pourtant qu'il avait dit qu'il ferait attention dans le passé, étant conscient de son comportement parfois borderline...

Ça n'empêcherait pas d'être obligé de quand même tester au runtime les CPUID qui varient dans une même version (comme AVX512F).

On peut toujours, mais c'est en théorie inutile si le jeu d'instruction que l'on veut utiliser est inclus dans le niveau du processeur.

Ce n'est justement pas le cas. La news de Next est inexact. C'est bien tout le problème.

Peux-tu expliciter stp ? Le seul truc que j'ai vu qui pourrait aller dans ce sens, c'est la désactivation via microcode de fonctionnalités pour cause de failles/sécurité. Si cela devait affecter un jeu d'instruction d'un niveau précis, alors le processeur perdrait sa compatibilité.

C'est précisément ce qui est en train d'être abandonné.

Oui et non. Ce qui est abandonné, ce ne sont pas les jeux d'instructions, mais les architectures complètements obsolètes. Un ordinateur 64 bits aujourd'hui, démarre en 16bits, avant de passer en mode protégé 32 bits pour enfin activer le mode 64 bits. Car la méthode de démarrage n'a pas changé depuis au moins la fin des années 80. La seule chose qui ait changé, c'est que maintenant, c'est l'UEFI qui fait une partie du boulot au lieu que cela soit l'OS qui fasse tout.

Le 16 bits est complètement désué et ne sert plus à rien (il n'y a plus de programmes en mode 16bits qui tourne directement sur une architecture 32/64bits comme ce que nous avons eu à une époque sous Windows par exemple, où il était possible de lancer un programme DOS directement sous Windows).

Ou alors j'ai mal compris les intentions d'AMD et d'Intel.

Pourquoi drame ?. Si le CPU ne supporte pas un jeu d'instruction nécessaire pour être en v4, il ne sera pas en v4, tout simplement...

Vérifier la présence d'un jeu d'instruction, oui, bien sûr, cela sera toujours nécessaire. Que ce soit à la compilation ou à l'exécution, l'important, c'est que cela soit fait.

Ensuite, Intel a sorti une gamme de processeurs annoncé compatible v4 et ne contenant justement pas l’instruction en question (parce que ça ne rentrait pas dans leurs cœurs « efficiency » donc tout le processeur en est privé).

Justement, c'est ce que j'entends de la part des détracteurs. Mais pour l'instant, aucun exemple n'a été donné d'un processeur annoncé comme v4 et sans ce jeu d'instructions. Oui, le jeu a été retiré de la 12e génération. Tant qu'un processeur de 12e génération n'est pas estampillé v4, ça ne pose absolument aucun problème.

Si ça existe, il doit pourtant être facile de trouver, sur le site d'Intel par exemple, un processeur estampillé v4 sans ce jeu d'instruction. Les 5min de recherches que j'ai fait n'ont pas été concluant.

C'est pas parce que la décision est collégiale qu'elle n'est pas mauvaise.

Ce n'est pas parce qu'une décision est prise par une seule personne qu'elle n'est pas mauvaise ;)

Soit dit en passant, les "décisions absurdes" (3 volumes au total, avec des années écoulés entre chaque volume) est une lecture très intéressante pour, justement, comprendre comment, par en groupe, on peut arriver à prendre une décision... absurde !