Journal Une base de données libre pour les CPU x86 grand public

Posté par  . Licence CC By‑SA.
Étiquettes :
23
2
jan.
2022

Pour un projet personnel, je cherchais à obtenir une base de donnée qui liste les jeux d'instruction des CPU x86 grand public et la présence éventuelle d'un GPU intégré. Malheureusement, je n'en ai trouvée aucune qui soit complète et réutilisable librement :
- CPUWorld est une mine d'informations non téléchargeables et non libres,
- Techpowerup est synthétique mais non libre,
- CPU-DB est un projet de l'université de Standford à l'arrêt depuis 2016, manquant d'informations sur les instructions prises en charge et sans licence.

Profitant du temps disponible durant le confinement de mars 2020, j'ai décidé de créer ma propre base de données qui agrège des sources libres, principalement Wikipédia anglais. Dans cette version de Wikipédia, chaque dénomination commerciale de CPU possède une page listant chaque modèle dans des tableaux (exemple).

La méthode

Face au traitement d'un grand nombre de taches répétitives, il y a deux profils : ceux qui font l'effort de développer des outils afin que les taches soient traitées facilement, et ceux qui ne font pas d'outils et répètent les taches le plus efficacement possible. J'ai appris que je fais partie de la deuxième catégorie.

En mettant Wikipédia sur un écran et LibreOffice Calc sur l'autre, j'ai récupéré l'ensemble des tableaux par copier-coller. Les données ont ensuite été déplacées dans la bonne colonne. Enfin, elles ont été transformées et vérifiées à l'aide de filtres et de formules. Les données n'étant pas explicitement présentes dans les tableaux de Wikipédia ont été ajoutées à la main. Par exemple, tous les AMD Phenom gèrent les instructions AMD64; je filtre la famille sur "Phenom" et ajoute "VRAI" à la colonne x86-64.

Le résultat

J'obtiens un tableau de 67 colonnes et 3190 entrées.

Certains processeurs ont été retirés car hors du cadre du projet :
- Les prototypes.
- Les CPU pour applications hors PC.

Toutes les colonnes ne sont pas exploitables. Par exemple :
- Les dates de commercialisation récoltées ne sont pas dans un format uniforme. Je n'avais besoin que de l'année, récupérée grâce à une formule.
- Le type de RAM ou le "Feature Level" DirectX supprimés lors des premiers copier-coller, puis je me suis rendu compte que ça pouvait servir à d'autres.
La version publiée ne comprend plus que 40 colonnes sur 67.

La publication

Cela fait depuis un an et demi que le tableau traîne sur mon disque dur. Je manque de temps pour apprendre Ruby on Rails nécessaire à la construction du projet. J'ai donc décidé de la partager afin que le travail puisse servir à d'autres développeurs. Elle est disponible sur un repo Github accompagnée des instructions d'utilisation et de la roadmap, sous licence CC BY-SA 3.0. Github semble un choix pertinent car il permet de tracer les évolutions de versions et de gérer les demandes de correction.

Exemples d'utilisation

  • Mettre à niveau son CPU : sélectionner le CPU actuel dans la liste, obtenir son nom code, puis filtrer par nom code pour obtenir la liste des CPU équivalents.
  • Trouver un processeur 64 bits pour une vieille machine : je dispose d'un PC équipé d'un Pentium 4 "Prescott" 32 bits. Malheureusement, de moins en moins de programmes tournent sur des PC 32 bits. Je peux trouver un Pentium 4 "Prescott" x86-64 en appliquant les filtres appropriés.
  • Trouver un CPU pour un pare-feu : consommation faible (filtre sur "TDPMin"), instructions AES-NI pour un VPN performant (filtre sur "AES") et générateur de nombres aléatoires (filtre sur "RDRAND").

Et les GPU ?

Une base de donnée des GPU dédiés est prête. J'aimerais prendre en compte vos retours sur la base de données CPU avant de la publier.

  • # petits manques

    Posté par  . Évalué à 3.

    Merci pour le boulot, c'est intéressant, mais pourquoi tu n'indiques pas 32/64 bits ni l'année de sortie ?

    • [^] # Re: petits manques

      Posté par  . Évalué à 3.

      Merci pour ton retour.
      - L'année de sortie correspond à la colonne "Year".
      - La prise en charge du 64bit est indiquée dans la colonne "x86-64".

      • [^] # Re: petits manques

        Posté par  . Évalué à 3. Dernière modification le 02/01/22 à 14:34.

        Ah oui d'accord, je viens de trouver ces colonnes supplémentaires, mille pardons.
        L'affichage du CSV agrandit tellement la colonne "Socket" que je pensais qu'il n'y avait rien après.

        En CSV il faut faire attention au formattage des nombres. Certains sont à passer comme du texte pour avoir un alignement similaire au texte ou pour préserver les zéros de gauche. On les précède alors d'une apostrophe qui ne sera pas affichée par le tableur : '325. C'est nécessaire dans la colonne Socket ou les noms en texte sont à gauche et les noms en chiffres à droite.

        NB : ce n'est pas une norme, juste une convention pratique avec les tableurs courant.

  • # suggestion de format

    Posté par  . Évalué à 3.

    Quitte à utiliser un format textuel, universel et pratique, je te propose de jeter un oeil à GNU Recutils qui permet beaucoup plus de manipulations.

    • [^] # Re: suggestion de format

      Posté par  (site Web personnel, Mastodon) . Évalué à 3.

      Héhé, j'allais proposer d'utiliser du TSV plutôt que du CSV (bien que très répandu est très peu interopérable), vu qu'il n'y a pas de tabulation dans les cellules ; et sinon justement du recfile (ça ressemble un peu à du YAML mais une ligne vide pour séparer les enregistrements —au lieu du triple-tiret ou de l'inclusion dans une liste, et on a une suite de commandes pour les traiter)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: suggestion de format

        Posté par  . Évalué à 2.

        Merci Orfenor et Gil Cot pour les suggestions. Il est vrai que le CSV ne semble pas trop utilisé dans le monde du développement, mais reste répandu dans l'Open Data pour les exports. On pourrait imaginer avoir la base de données en plusieurs formats.
        J'ai hésité aussi à utiliser du TSV car simple à générer depuis LibreOffice.

        • [^] # Re: suggestion de format

          Posté par  (site Web personnel) . Évalué à 8. Dernière modification le 02/01/22 à 17:06.

          A quand un journal/dépêche sur les formats d'export ? pour vulgariser.

        • [^] # Re: suggestion de format

          Posté par  (site Web personnel, Mastodon) . Évalué à 2.

          Je pense que les professionnels un peu consciencieux sont conscients qu'il ne faut pas utiliser CSV ou alors se sont assuré à minima de la validité du fichier (peu respectent la norme à la lettre) et de l'absence garantie d'effets de bord… On en a souvent parler ici. Commentaires sur https://linuxfr.org/users/desktop-ready-0/journaux/en-finir-avec-csv-ou-excel-pour-echanger-des-donnees par exemple.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: suggestion de format

          Posté par  . Évalué à 2.

          L'intéret de Recutils c'est d'utiliser un format texte simple, bien plus simple que CSV, moins sujet aux erreurs (dans un tableur on se trompe facilement de case). On peut le remplir à la main ou avec les outils dédiés. Et Recutils dispose aussi d'outils pour le manipuler. C'est un format de stockage de base de donnée.
          D'autre part il se convertit en CSV (ou depuis le CSV).

          Je te suggère seulement de regarder pour voir si c'est mieux pour toi.

          • [^] # Re: suggestion de format

            Posté par  . Évalué à 2.

            J'oubliais un point important : le format texte de Recutils est lisible et versionnable. Même les diffs sont faciles à lire.

            • [^] # Re: suggestion de format

              Posté par  . Évalué à 6.

              Ou enrichir wikidata

              • l'organisation communautaire est déjà faite
              • tu as de l'outillage pour faire des requêtes (et c'est hébergé)
              • tout le monde peut contribuer à enrichir avec par exemple les nouveaux CPUs
              • tu étends amplement les usages possibles en permettant de croiser les données avec d'autres données

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: suggestion de format

                Posté par  . Évalué à 2.

                Merci pour la suggestion. Je viens de déposer un message sur le bistrot de Wikidata. Wait and see…

  • # Méthodes

    Posté par  . Évalué à 3.

    Face au traitement d'un grand nombre de taches répétitives, il y a deux profils : ceux qui font l'effort de développer des outils afin que les taches soient traitées facilement, et ceux qui ne font pas d'outils et répètent les taches le plus efficacement possible. J'ai appris que je fais partie de la deuxième catégorie.

    Il y a une troisième catégorie qui créé des outils pour que pleins de gens le fasse. C'est d'ailleurs ce que fait wikipédia.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Méthodes

      Posté par  (site Web personnel) . Évalué à 3.

      Sans compter la catégorie de celles et ceux qui créent des outils pour que pleins de gens créent des outils. :)

      Adhérer à l'April, ça vous tente ?

  • # Infos pour procs Intel

    Posté par  . Évalué à 2. Dernière modification le 02/01/22 à 15:07.

    Quand j'ai besoin d'infos pour les procs Intel (et au regard de la nomenclature super claire sur les différentes gammes…) pour connaître l'archi, les jeux d'instructions AVX supportés, les caches, etc, je me tourne vers le site Intel Ark. Par contre, je ne sais pas si on peut extraire les données proprement.

    Petite parenthèse : pour les derniers Alder Lake, les coeurs "Performance" ont de l'AVX-512 dedans, mais pas les petits coeurs "Eco" donc c'est désactivé, par contre pour les versions d'entrée de gamme avec uniquement des coeurs "Performance", on aurait pu espérer pouvoir activer l'AVX-512 mais Intel semble forcer les fabricants de cartes mères à désactiver cette possibilité

    • [^] # Re: Infos pour procs Intel

      Posté par  (site Web personnel) . Évalué à 4. Dernière modification le 02/01/22 à 15:22.

      Pareil, pour tout savoir de son proco Intel quand on a un doute : Intel Ark

      Sinon j'ai beaucoup bossé à une époque sur la page fr Intel HD Graphics : content de voir que ça sert :)

      Bravo Thecross pour ta démarche et l'organisation pour un faire un projet collaboratif

  • # Usage

    Posté par  . Évalué à 4.

    Certains processeurs ont été retirés car hors du cadre du projet :
    - Les prototypes.
    - Les CPU pour applications hors PC.

    Pourquoi ne pas les avoir garder en ajoutant une colonne pour le spécifier ? C'est pratique parfois de savoir que telle référence n'est pas dédiée pour le PC et ça explique sont absence d'offre commerciale pour particulier par exemple.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Usage

      Posté par  . Évalué à 2.

      Dans un premier temps, je les récupérais en même temps que les processeurs commercialisés via mes copier-coller. Puis je me suis rendu compte qu'un certain nombre d'informations étaient manquantes ou difficiles à vérifier. J'ai donc décidé de les supprimer pour ne pas mettre d'information fausse quitte à les rajouter plus tard.

  • # Et pour la préhistoire ?

    Posté par  . Évalué à 4.

    Je vois que tu es remonté assez loin ; avec des processeurs datés de 93.

    Du coup, pourquoi ne pas aller plus loin et aussi extraire les "vrais" x86, à savoir 8086, 8088, 80286, 80386 et 80486 ? En rajoutant une colonne "FPU".

    Sinon, à l'époque des premiers Pentium, j'avais eu des PC à base de Cyrix, des 6x86 (successeurs des 5x68). D'après wikipedia (https://en.wikipedia.org/wiki/Cyrix), c'est Via qui au final a récupéré tout ça, mais du coup il manque cette famille à ta liste.

    • [^] # Re: Et pour la préhistoire ?

      Posté par  . Évalué à 2.

      Pour le coup j'ai même eu un 8086 fabriqué par AMD (Amstrad 2086) avec les deux logos sur la puce.
      Bizarre pour le coup, on le compte comment ? AMD ou Intel ?

      Les vrais naviguent en -42

    • [^] # Re: Et pour la préhistoire ?

      Posté par  . Évalué à 2. Dernière modification le 02/01/22 à 23:17.

      J'ai voulu construire cette base de données dans un but "fonctionnel" plus que "historique", en listant les CPU capables de faire tourner des OS encore supportés. C'est une notion vague qui évolue sans cesse : on pouvait, par exemple, faire tourner IPFire sur un Pentium III jusqu'à cette année. En conséquence, j'aurais tendance à ajouter en priorité les CPU récents plutôt que de remonter dans le temps.
      Bien vu pour les Cyrix, je peux aussi ajouter les processeurs Transmeta.

      • [^] # Re: Et pour la (pas) préhistoire ?

        Posté par  (site Web personnel) . Évalué à 6.

        Pour les CPU x86_64 capables de faire tourner des OS actuels, il y a aussi les puces chinoises Zhaoxin.

        C’est un processeur x86_64 chinois via la branche Cyrix/Via pour répondre à la demande gouvernementale de produits x86 tout en satisfaisant les exigences chinoises (souverainisme) et américaines (restrictions). À ce que je comprends il y a aussi eu des processeurs x86 Chinois basés sur des licences Zen via des entreprises paravent pour contourner les réglementations mais il ne s’agit pas de ça.

        Il y a une dizaine d’année j’avais eu une Dedibox avec un processeur Via qui proposait aussi les extensions de virtualisation (mais kvm ne marchait pas à l’époque pour diverses raisons), donc je suppose que les itérations actuelles prennent cela en charge et proprement. Il faut donc s’attendre à des processeurs Zhaoxin qui sont entièrement compatible avec les usages actuels en terme de fonctionnalités (la question des performances est toute autre).

        Les Zhaoxin sont les descendants de la « troisième branche » Cyrix / Via qui survit confidentiellement. De la même manière les processeurs graphiques associés sont basés sur la branche Via / S3 Chrome qui survit confidentiellement. L’association de ces CPUs avec ces puces graphiques permet de produire des PCs compatible x86 faisant tourner des OS modernes tels que Windows 10 et prenant en charge OpenGL, OpenCL, DirectX, et probablement DirectX12 et/ou Vulkan.

        Il existe des PCs destinés au marché chinois, typiquement le marché des administrations. J’avais vu une vidéo sur le sujet et de ce que j’en ai compris ça donne des machines équivalentes à de l’entrée de gamme de génération précédentes qui pourraient convenir à certains métiers de bureau comme du sécrétariat (de la même manière que le marché du reconditionnement convient très bien pour cet usage).

        Mais récemment, et plus accessible au monde occidental, QNAP a sorti en 2021 un NAS basé sur ce processeur Zhaoxin.

        Il faut savoir que QNAP est généralement très permissif pour ces NAS x86. QNAP produit des NAS avec CPUs ARM et des NAS avec CPUs x86, et tous les NAS avec CPUs x86 que j’ai vu étaient en fait des PCs avec un BIOS et tout, faisant simplement tourner leur système QNAP maison.

        C’est d’ailleurs la raison pour laquelle je recommande QNAP (avec processeur AMD ou Intel) vis à vis d’autres marques de NAS comme Synology, car en achetant un QNAP x86 (Intel Xeon, AMD R-Series) bah tu achètes un serveur sur lequel tu peux installer ta Debian comme sur n’importe quel PC. Il faut bien vérifier qu’il y a un processeur x86 et une sortie graphique avant d’acheter. Typiquement les séries TVS de QNAP sont très bien pour ça.

        Bon, par contre, je ne sais pas s’il faut recommander les QNAP basé sur Zhaoxin, ça dépend de la confiance que l’on donne à la Chine. Mais sur le plan fonctionnel, vu que les Zhaoxin sont conçus à la base pour produire des clones de PC, il serait très étonnant que les QNAP basés sur Zhaoxin ne soient pas des clones de PCs comme le sont déjà les QNAPs basés sur les processeurs x86 d’Intel et d’AMD. D’autant plus que le modèle en question est de la série TVS. Le QNAP TVS 675 basé sur Zhaoxin est vendu dans une gamme de NAS qui ont ordinairement des CPUs AMD avec puce graphique Vega mobile, ou des CPUs Intel (y compris du Xeon) avec puce graphique Intel HD.

        Ce qui d’ailleurs me fait penser que, puisque je suppose que le système maison de QNAP est basé sur Linux, si le Zhaoxin KaiXian KX-U6580 du QNAP TVS-675 vient bien avec une puce graphique S3 Chrome actuelle, il existerait un pilote graphique Linux pour ces puces graphiques S3 Chrome de dernière génération.

        Ça pourra aussi te servir pour la base de donnée des GPUs, personnellement je n’ai encore jamais pu mettre la main sur une carte S3 moderne (ça veut dire, à partir de ~2008 avec la prise en charge d’OpenGL 2.1 et suivants. La page wikipédia S3 Chrome est assez difficile à lire, et probablement incomplète, par exemple je ne sais pas où se situe la S3 chrome 5400E, et la S3 chrome 860 n’est pas listé (c’est celle-ci qui serait intégrée dans les Zhaoxin).

        En vrai j’aimerai bien mettre la main sur ce genre de PC par curiosité, par exemple j’aimerai évaluer Unvanquished avec (et aussi vérifier qu’il existe bien un pilote Linux actuel pour les GPUs Chrome) mais ce genre de NAS ça coûte quelques centaines d’euros tout de même. 😅

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Et pour la (pas) préhistoire ?

          Posté par  (site Web personnel) . Évalué à 5.

          Bon bah je vais me répondre à moi-même, j’ai fouillé un peu et dans le centre de téléchargement de pilotes pour ce NAS, il y a des pilotes… Nvidia. 🤦‍♀️

          Ces puces S3 modernes sont donc vraiment introuvables… Même QNAP, pour un NAS, a préféré partir sur du Nvidia. Est-ce à cause des performances ? Il faut rivaliser avec d’autre NAS ayant du AMD Vega. Est-ce parce qu’il n’y a plus du tout de pilote propriétaire Linux pour S3? C’est d’ailleurs la première fois que je vois un pilote Nvidia sur un QNAP.

          Bref, déjà que la question de mettre un CPU Chinois dans son parc se pose, mais avec le peu de pérennité et la mauvaise intégration du pilote Nvidia, si c’est pour installer sa Debian, autant acheter un QNAP avec du AMD ou du Intel (et vérifier dans les pilotes qu’il n’y a pas d’Nvidia).

          En tout cas ça confirme bien l’architecture x86_64 de ce processeur Zhaoxin et le fait que Linux tourne dessus. 👍

          $ pwd; for m in nvidia*.ko; do printf '\n'; file "${m}"; modinfo "${m}" | egrep -v '^parm:|^filename:'; done
          
          /tmp/NvKernelDriver_h5.0.0.1900_TS-X75_20211228/NvKernelDriver/nvkerneldriver
          
          nvidia-drm.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=71be5cca79c265090fc227d53fd2c4e2d56b5d8c, not stripped
          version:        460.39
          supported:      external
          license:        MIT
          srcversion:     B0B8ECC7F96A962EBF0952E
          alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
          alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
          depends:        nvidia-modeset
          name:           nvidia_drm
          vermagic:       5.10.60-qnap SMP mod_unload 
          
          nvidia.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=6d381010513dee915f38e7a2e19ae933b176d9f8, not stripped
          alias:          char-major-195-*
          version:        460.39
          supported:      external
          license:        NVIDIA
          srcversion:     88778FD9C7BD9CA16708044
          alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
          alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
          depends:        
          name:           nvidia
          vermagic:       5.10.60-qnap SMP mod_unload 
          
          nvidia-modeset.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=0eb8151074d26c60e85426d744640b60de5f53c2, not stripped
          version:        460.39
          supported:      external
          license:        NVIDIA
          srcversion:     9B2A1468B0F791B0A33A01B
          depends:        nvidia
          name:           nvidia_modeset
          vermagic:       5.10.60-qnap SMP mod_unload 
          
          nvidia-uvm.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=615e82e8116ff6b16f479aa9f6ff3a75f5c13a29, not stripped
          supported:      external
          license:        Dual MIT/GPL
          depends:        nvidia
          name:           nvidia_uvm
          vermagic:       5.10.60-qnap SMP mod_unload 
          

          ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Et pour la préhistoire ?

      Posté par  (site Web personnel, Mastodon) . Évalué à 3.

      Du coup, pourquoi ne pas aller plus loin et aussi extraire les "vrais" x86, à savoir 8086, 8088,

      Sans oublier le clône de NEC : le v20 qui avait bien boosté mon pécé anémique de l'époque…

  • # Contribution

    Posté par  . Évalué à 5.

    Pour la partie "Format", je dirais qu'il manque l'information pour définir que l'information n'est pas connue. J'ai l'impression que c'est une colonne vide en regardant l'existant, mais ça serait bien de le préciser.

    Ensuite, je ne vois pas d'instruction pour contribuer. Je dirais qu'il faudrait au moins préciser si on veut ajouter un CPU si tu accepte d'avoir des colonnes sans infos ou pas.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Contribution

      Posté par  . Évalué à 4.

      Tu as raison : il est difficile de distinguer une info manquante d'une info non applicable. Je dois travailler ce point.

      Concernant les contributions, je voulais que cela ce fasse par remarques ouvertes dans les "Issues" que je traite à la volée, mais il y a probablement la possibilité de faire quelque chose de beaucoup plus poussé avec Git via les Pull Request. Le format de fichier CSV devient alors peu pratique pour traiter les apports : il faudrait passer dans l'un des formats proposés par Orfenor et Gil Cot.
      Barmic vient de suggérer de travailler sur Wikidata que je ne connais pas. Je vais y faire un tour de ce pas…

  • # Super, une interface pour lire tout ça ?

    Posté par  . Évalué à 1.

    Super travail déjà, avoir la patience d'organiser tout ça, c'est assez incroyable.
    Je vais voir si j'ai le temps de réfléchir à une interface web avec un serveur Flask ou Gofiber derrière, histoire de parser le fichier correctement. Le plus dur à faire sera la recherche de manière dynamique je pense, on peut imaginer le choix entre Intel et AMD, la date (voir les dates) de sorties…

    • [^] # Re: Super, une interface pour lire tout ça ?

      Posté par  . Évalué à 2.

      C'est sûr, il manque une interface pour présenter les données. Avec le temps qu'il faudra pour que je maîtrise les technos web, la base risque de devenir poussiéreuse, donc j'ai préféré la publier en l'état. Si tu maîtrises des outils pour créer des interfaces web, c'est avec plaisir que je t'encourage à en créer une !

      • [^] # Re: Super, une interface pour lire tout ça ?

        Posté par  . Évalué à 1.

        Ce serait aussi avec plaisir si je trouve le temps ! Je mettrais en réponse le lien vers le projet si ça se fait et peut-être que j'écrirais aussi un journal sur ça :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.