[CPU-X] Une outil similaire à CPU-Z, pour GNU/Linux

[kozaki]

@Xorg dans le PKGBUILD comme indiqué (hésité avec le mettre au frigo mais un strip au fridge ça m'a paru trop chelou )

Bien l'implémentation de i7z dans libcpuid pour les core Intel.

ps ton avatar ressemble bigrement à celui de Xpra

[benjarobin]

Belle contribution, mais je ne comprend vraiment pas ce code : https://github.com/X0rg/libcpuid/commit ... b60ca4a8c0
Pourquoi utiliser une variable static et vérifier le coup précédent ? Cela me semble complètement faux. Et pourquoi ces goto, ils sont moches et inutile. Les goto ne devraient utilisé que pour améliorer la lecture ici tu fait des nœuds au cerveaux

[Xorg]

Belle contribution, mais je ne comprend vraiment pas ce code : https://github.com/X0rg/libcpuid/commit ... b60ca4a8c0
Pourquoi utiliser une variable static et vérifier le coup précédent ? Cela me semble complètement faux. Et pourquoi ces goto, ils sont moches et inutile. Les goto ne devraient utilisé que pour améliorer la lecture ici tu fait des nœuds au cerveaux

Oui, ce que j'ai fait dans INFO_CUR_MULTIPLIER n'est pas très beau, je sais pas je devais manquer d'idées quand j'ai fait ça. C'est un peu mieux dans le commit 32ddb7d.
Je sais que l’utilisation des goto en C reste prohibée la plupart du temps. Je t'avoue que c'est à cause de l'ASM, dès qu'on en a fait on voit tout de suite le code sous un autre angle, mais ce n'est pas toujours une bonne chose.

[benjarobin]

Tu as certes supprimé les goto, mais quel est le besoin du static, pourquoi vérifier l'appel précédent de cette fonction ? Ce que tu fais est toujours très très étrange !
Comprends tu le sens d'une variable static ? Son implication ?

[Xorg]

Bien l'implémentation de i7z dans libcpuid pour les core Intel.

ps ton avatar ressemble bigrement à celui de Xpra

Il faudrait que je bosse aussi sur l'implémentation du TPC pour les CPUs AMD. Mais n'ayant pas de CPU AMD, c'est moins évident de faire quelques tests basiques.
Mon avatar n'est que temporaire, j'avais trouvé ça marrant de faire ce jeu de mots/image, mais voilà quoi.

Tu as certes supprimé les goto, mais quel est le besoin du static, pourquoi vérifier l'appel précédent de cette fonction ? Ce que tu fais est toujours très très étrange !
Comprends tu le sens d'une variable static ? Son implication ?

L'idée c'est de déclarer une variable statique nulle. Au premier test, elle est affectée, et aux tests suivants l'affectation est volontairement sautée. J'ai mis en statique car c'est des variables qui ne changent pas, alors autant éviter de recalculer systématiquement les mêmes valeurs.

Est-ce que tu essayes de me dire que :

Code : Tout sélectionner

static int a = 0;
if(!a)
  a = fonction();

Est équivalent à :

Code : Tout sélectionner

static int a = 0;
a = fonction();

?
Je ne me rappelle plus de toutes les subtilités avec le type static.

[benjarobin]

Je n'avais pas compris que l'idée était d'éviter de "recalculer" certaine chose, ce que tu fais est syntaxiquement juste. La 2ième proposition n'est pas du tout équivalente à la 1ier. Il manque des commentaires, car ce n'était pas immédiat ce que tu cherchais à faire...

Mais cela reste faux ! En effet tu un handle, tu n'as pas forcément qu'un CPU ! Si tu dois cacher l'information, alors elle doit être stocké avec le handle, enfin je ne connais pas le code de la lib, mais cela me semble 1000 fois plus propre.

Plus globalement utiliser une variable static dans une lib est à éviter, ou en mesurer les conséquences et le documenter !!!

[benjarobin]

Tant que l'on est dans les remarques https://github.com/X0rg/libcpuid/commit ... e37b9abece Ceci aussi ne va pas du tout. Tout d'abord pourquoi ne pas retourner le type enum au lieu du int ?
La dernière ligne r = est forcément égale à 0, donc tu ignore une erreur et tu dis que le CPU est de type intel...

Tu aurais pu cacher l'information ici dans un static, mais cela aurait été encore mieux de le mettre dans le handle !

[Xorg]

La 2ième proposition n'est pas du tout équivalente à la 1ier.

On est d'accord, niveau syntaxique c'est correct.

Mais cela reste faux ! En effet tu un handle, tu n'as pas forcément qu'un CPU ! Si tu dois cacher l'information, alors elle doit être stocké avec le handle, enfin je ne connais pas le code de la lib, mais cela me semble 1000 fois plus propre.

J'aurais tendance à dire que le BCLK est toujours le même, peu importe le nombre de CPUs.
Par contre, je viens de trouver qu'il est possible de mixer différents CPUs sur un CM multi-sockets (avec de nombreuses contraintes), donc effectivement si on a un CPU A et un CPU B identiques sauf en fréquence, ce que j'ai fait est à revoir. J'étais parti du principe qu'on ne pouvait pas mixer, ça change tout...

Tout d'abord pourquoi ne pas retourner le type enum au lieu du int ?

Pour moi, enum = int. Mais c'est vrai que j'aurais dû mettre cpu_vendor_t, ça aurait été plus clair.

La dernière ligne r = est forcément égale à 0, donc tu ignore une erreur et tu dis que le CPU est de type intel...

Oui. Mais il me semble qu'on ne peut jamais arriver dans le else en réalité. Cela dit, j'avais effectivement pas pensé à ce détail.

Bon, ça fait plusieurs choses à revoir tout ça. Je m'y mets dès que je peux. En tout cas merci pour ton aide, je ne suis pas un expert en C, et c'est vrai que j''ai écrit des choses limite, mais c'est en constatant ses erreurs qu'on s'améliore.

[benjarobin]

C'est pour cela qu'il ne faut pas prendre mal mes remarques, certes elles sont peu brutales, mais c'est mieux que c'est nul
Oui je sais que c'est un peu ce que j'avais dis à l'époque sur CPU-X, mais je n'ai jamais pris le temps de détailler le pourquoi, désolé...

Pour le enum et int, non ce n'est pas forcément le même type, c'est architecture dépend que je sache. Mais en tout cas certain compilateur (clang) vérifie que l'on assigne pas un mauvais type dans un autre, donc si tu assignes un enum dans un autre type de enum, clang te met un warning, de plus c'est mieux de mettre directement le type, tu sais ce que retourne la fonction, pas besoin de lire sa doc / description.

Sinon dans l'idéal, à moins d'avoir des grosses contraintes en terme de performance, c'est mieux de ne pas faire trop d'hypothèse, ou alors il faut mettre un pavé de commentaire expliquant les choix fait. Surtout que le pour cpu_vendor() tu peu cacher sans aucun souci et que tu ne l'as pas fait.

[Xorg]

C'est pour cela qu'il ne faut pas prendre mal mes remarques, certes elles sont peu brutales, mais c'est mieux que c'est nul

Du moment que c'est un minimum argumenté et que les arguments se valent, je ne le prends pas mal. Je sais très bien qu'on peut toujours faire mieux en programmation, on écrit du code et quelques jours après on se dit "Ah mais non, j'aurais dû faire comme ça !". Puis je commence à te connaître, je sais bien que si tu as posté c'est aussi pour m'aider à avancer.

Pour le enum et int, non ce n'est pas forcément le même type, c'est architecture dépend que je sache. Mais en tout cas certain compilateur (clang) vérifie que l'on assigne pas un mauvais type dans un autre, donc si tu assignes un enum dans un autre type de enum, clang te met un warning, de plus c'est mieux de mettre directement le type, tu sais ce que retourne la fonction, pas besoin de lire sa doc / description.

Oui, je suis d'accord que retourner un entier pour dire "Aller voir là-bas pour voir à quoi cet entier correspond" n'est pas l'idéal, autant retourner directement le type concerné. Fait dans 63907c.

Surtout que le pour cpu_vendor() tu peu cacher sans aucun souci et que tu ne l'as pas fait.

Oui en plus j'appelle plusieurs fois cette fonction, c'est vrai que c'était plutôt là qu'un static aurait été utile. Grosso-modo je m'y prends de la même manière que la première proposition (message posté à 16:18) ou bien il y a une méthode plus "propre" pour cacher cette variable ?

[benjarobin]

Avant de s'occuper de cacher cette information, j'aurais personnellement fait un petit refactoring pour pouvoir extraire que le cpu_vendor et non toutes les informations depuis le CPU, informations que l'on n'utilise pas. En gros découper la fonction cpuid_basic_identify en 2 et créer une interface publique + Rajouter une fonction pour extraire juste les 3 mots nécessaire au décodage du cpu_vendor

[Xorg]

Ok, je vois bien que le nom du vendeur est extrait par les lignes suivantes :

Code : Tout sélectionner

memcpy(data->vendor_str + 0, &raw->basic_cpuid[0][1], 4);
memcpy(data->vendor_str + 4, &raw->basic_cpuid[0][3], 4);
memcpy(data->vendor_str + 8, &raw->basic_cpuid[0][2], 4);

Et que l'affectation du type énuméré se fait dans la boucle, quand les deux chaînes de caractères sont identiques :

Code : Tout sélectionner

data->vendor = matchtable[i].vendor;

Mais la partie MSR ne dépend pas de la fonction cpuid_basic_identify, elle est complètement à part. Du coup là je vois mal comment créer une fonction de prototype cpu_vendor_t cpu_vendor(void), car il me faut forcément les deux structures cpu_raw_data_t et cpu_id_t pour pouvoir extraire cette donnée (mais justement, la partie MSR n’utilise pas ces structures). Donc à un moment ou à un autre, je suis obligé d'extraire quelques informations du CPU.

Après je peux toujours m'inspirer de ce qui est fait au début de la fonction cpu_identify, puis réutiliser les 3 lignes nécessaires au décodage du cpu_vendor, là je pense que ça pourrait marcher et être un peu moins lourd.

[benjarobin]

Par exemple comme ceci : http://pastebin.com/5BHUiCB1
Vite fait, non testé, ni compilé

[Xorg]

Maintenant que tu m'as donné la solution, ça me paraît plus évident. Je n'ai pas eu besoin de faire beaucoup de modifications, tel quel ton patch fonctionnait correctement, j'ai relu pour mieux comprendre ce que tu avais fait et il ne m'a pas semblé y avoir de problème.
Ajouté dans a853fcd. Je te suis très reconnaissant de m'avoir aidé à améliorer ce que j'aurais pu/dû mieux faire.

[Xorg]

Salut Xorg,

Juste une petite idée, serait-il possible d'intégrer la T° des CPU (et éventuellement des GPU) ?

J'y travaille. Pour prouver que ce n'est pas un fake, voici un screenshot : http://i.imgur.com/MMnDyif.png. De toute façon, c'est le code qui est actuellement présent sur mon dépôt Git.
C'est encore expérimental, trop de choses sont encore partielles. Je préfère avertir sur certains points :

• La tension n'est supporté que sur les processeurs Intel, depuis la famille Core ix (code provenant d'i7z)
• La finesse de gravure n'est disponible que sur les processeurs Intel gravé en 45nm et moins (il faut juste que j'ajoute ce qu'il manque...)
• La température du CPU est supportée que sur les processeurs Intel, depuis la famille Core ix (code provenant d'i7z)
• Il faut que je m'occupe de backporter les changements de la GUI en GTK 3.14+ sur la GUI en GTK 3.8
• Il faudrait que le module MSR soit chargé automatiquement (à voir si c'est pas mieux de le faire directement dans libcpuid)
• Je mettrai à jour la traduction française sous peu

Plusieurs choses à m'occuper de mon côté en plus de cette liste : tension et température sont celle du cœur 0, c'est similaire avec les GPU (ça devrait être celle du premier GPU trouvé). Donc ça fait de quoi faire.
Concernant le code source en lui-même, à force d'ajouter ou retirer des trucs à droite et à gauche, je suis pleinement conscients qu'il y a beaucoup de choses à revoir dedans. Je compte m'en occuper pour une future version majeure, j'ai déjà beaucoup d'idées en tête.

[Xorg]

J'ai publié la version 2.2.0. Il est préférable de mettre à jour libcpuid-git si ce n'est pas déjà fait. Ça m'embête un peu car il n'y a pas le support de la tension et de la température du processeur avec les processeurs AMD dans Libcpuid 0.2.2.

Donc dans les grosses nouveautés, on a maintenant le report de la finesse de gravure, de la température et de la tension du processeur (enfin, pas pour tous).
Il y a l'ajout d'un nouvel onglet "Caches", dans lequel j'ai introduit un benchmark (Bandwidth), ce qui donne une idée approximative du débit des différents niveaux de cache (c'est un test séquentiel en lecture sur 128 bits).
Et enfin, l'ajout de la température du GPU dans l'onglet Graphiques.

Concernant la version portable, l'exécutable n'arrive pas à lancer le mode NCurses sur certaines distributions, l'erreur étant la suivante :

Code : Tout sélectionner

Error opening terminal: xterm.

Le bug n'a pas été résolu, je cherche, je sais juste que ça vient de l'initialisation de NCurses elle-même.

Voilà, si vous êtes confrontés à des bugs, n'hésitez pas à m'en faire part.

[brunoo]

Bonjour,
D'abord merci à toi pour cet outil !
Depuis la mise à jour, il ne fonctionne plus sur mon pc (proc:intel E5300 dual core).
Voici le retour du terminal

Code : Tout sélectionner

CPU-X:core.c:314: erreur lors de la recherche de la tension du CPU
CPU-X:core.c:340: erreur lors de la recherche de la température du CPU
Erreur de segmentation (core dumped)

Merci

[oktoberfest]

Mêmes erreurs que @brunoo. Pour ma part j'ai essayé avec un AMD E-350

[Xorg]

Ah oui, j'ai mis longtemps à sortir cette version, et il y avait quelque chose que je ne sentais pas. Malheureusement, je ne peux que constater les problèmes engendrés par cette version 2.2.0 chez d'autres utilisateurs... J'ai déjà eu un rapport de bug sur GitHub (normalement le problème est réglé).

Pouvez-vous me donner la sortie de la commande cpu-x -v s'il vous plaît ? Ça me permettra de voir si c'est le même soucis ou non. Je suis désolé que ça rende le logiciel inutilisable pour vous, mais j'ai besoin de vos sorties pour patcher tout ça et sortir rapidement un fix.
Je travaille déjà sur une réécriture plus profonde du code, ces erreurs de segmentation témoignent d'un code peu robuste visiblement.

[brunoo]

Re,
voici le retour de la commande:

Code : Tout sélectionner

$ cpu-x -v
Configuration de la locale accomplie
Configuration des pointeurs pour les labels
Configuration du nom des labels
Lecture de la valeur BogoMIPS
Remplissage partiel des labels (étape libsystem)
Remplissage partiel des labels (étape libprocps)
Remplissage des labels (étape libcpuid)
Recherche de la finesse de gravure du CPU
Recherche de la tension du CPU
CPU-X:core.c:314: erreur lors de la recherche de la tension du CPU
Recherche de la température du processeur
CPU-X:core.c:340: erreur lors de la recherche de la température du CPU
Suppression des espaces non-nécessaires dans le label Spécification
Amélioration du label Vendeur pour le CPU
Recherche des instructions du CPU
Filling labels (libbandwidth step)
Erreur de segmentation (core dumped)

merci