on peut savoir pourquoi proc ne te convient pas?
vince Le 23/03/2012 à 09:40 En fait, c'est comme les benchmarks... Si tu te renseignes sur les benchmarks CPU sous linux, on te filera un lien vers /proc/cpuinfo qui affiche généralement la fréquence "de référence" du CPU et pas la fréquence actuelle... Quant au test de performance, tu peux oublier...
vince Le 23/03/2012 à 09:44 sinon, t'as le package cpufrequtils qui permet de tuner la fréquence ET de lire la fréquence actuelle...
squalyl > comme l'as dit Vince, la fréquence du CPU dépend des paramètres d'économie d'énergie définis dansl e BIOS.
vince > je ne maitrise pas l'installation de packages sur le Linux où tourne le code. Et installer un package pour connaitre la fréquence du CPU me laisse un peu perplexe... et l'idée d'inclure le code de CPUFREQUTILS dans mon code ça sent la galère.
Gare à celui qui touche a mes chips quand je code !
vince Le 23/03/2012 à 11:51 en fait il s'appuie sur le module CPUID, s'il est présent sur ta machine, tu peux probablement l'interroger directement
Az : c'est des procs x86, ou ça doit être portable ?
Dans le premier cas, j'avais fait un bout de code pour faire ça il y a longtemps, faut que je regarde.

—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT Turbo4: j'avais pas pensé à ça.
sinon le code de la lib en question doit être recompilable en statique dans $home, puis intégrable à ton code.
c'est des x86 :-p (sans commentaires, merci)
Gare à celui qui touche a mes chips quand je code !
OK, je vais regarder.
Le principe de base : lire périodiquement le TSC et un autre timer de fréquence connue, et en déduire la fréquence du proc. Sous Windows j'avais utilisé QueryPerformanceCounter(), qui s'appuie dans le pire des cas sur le PIT (sa fréquence est ~ 1,2 MHz). On doit pouvoir faire pareil sous Linux.

—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT TurboC'est un peu la technique dont je parlais plus haut, il y a gettimeoftheday par exemple, mais ça impose qu'il n'y ait pas trop de latence entre les appels des deux compteurs si on veut avoir des temps pas trop faux.
Gare à celui qui touche a mes chips quand je code !
Exact, mais ça, de toute façon, c'est un problème fondamental. Le seul moyen de l'éviter serait de désactiver les interruptions temporairement, pour que l'ensemble lecture TSC+lecture autre compteur soit atomique. Vu que ça va fondamentalement à l'encontre du principe d'un OS préemptif, je sais même pas si c'est possible en user-mode, et même si c'était le cas il faudrait que le processus soit SUID root.
Cependant je pense que si tu fais faire ça par un thread dédié, auquel tu donnes une priorité élevée, les résultats devraient être relativement précis.

—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT Turbosi y'a une latence d'appel, tu peux la négliger si tu mesures assez longtemps, et l'éliminer en faisant 2 mesures et en trouvant l'offset (y=ax+b) a donne la vitesse en instructions par seconde et b le temps de latence constant à ajouter aux mesures.
pour virer l'influence des irq on peut moyenner plusieurs mesures.
Je pense qu'il n'y a que le kernel qui peut désactiver les irq, et que de toute façon ce n'est pas nécessaire:
le performance counter compte un nb de cycles, irq ou pas (enfin je pense, non?)
la rtc donne le vrai temps écoulé.
Si, c'est nécessaire. Le problème n'est pas le fait que les compteurs ne soient pas lus simultanément (si tu supposes que le temps d'exécution est constant, ça s'annule quand tu calcules la différence, et de toute façon c'est complètement négligeable par rapport à la durée mesurée), mais le risque qu'il y ait un context-switch entre la lecture des deux compteurs. Dans ce cas ta mesure va être faussée (plus ou moins, suivant le temps passé à exécuter un autre processus).
Tu peux moyenner, mais ça pose 2 problèmes :
- l'erreur n'est pas centrée sur zéro (la durée ne peut être que rallongée, pas diminuée)
- vu que la fréquence du processeur n'est pas fixe, moyenner revient à effectuer un filtre passe-bas, donc à détruire de l'information

—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT Turbo vince Le 23/03/2012 à 14:45 (jusqu'à l'installation de cpuid, je n'avais que la fréquence de référence, il faut donc des modules en plus, et azrael a l'air de dire qu'il ne peut rien installer)
Zerosquare >
J'ai toujours connu ça:
-avant 2000: CPU à fréquence constante
-après 2008 (pour moi, pour le TSC je n'en sais rien): incrément variable pour le TSC.
Gare à celui qui touche a mes chips quand je code !
vince Le 23/03/2012 à 16:25 je dis juste ce que j'ai vu : un cpu qui gère inteligent step (j'ai pas le nom exact, le truc d'intel de gestion de la freq) renvoyait toujours la valeur "usine" je suis ptet tombé sur une config atypique ou sur un noyeau non compatible, je ne sais pas...
Peut-être simplement qu'il ne changeait pas sa vitesse dynamiquement avant que tu n'installes ces softs ?
Sur la plupart des distribs, cette fonctionnalité n'est pas utilisée par défaut car elle dégrade la réactivité perçue par l'utilisateur.
Sur Ubuntu (10 je crois), sur mon laptop, par défaut il est en powersave sur batterie, et en performance sur secteur, et le scaling dynamique (ondemand governor) n'est même pas disponible.
utilise l'instruction RTDSC pour lire le TSC (ou l'intrinsic __rtdsc(), peu importe)
t'as pas besoin de bencher 1 s... si tu utilise un timer qui a une granularite pas trop pourrie, juste 5 ou 10 ms c'est largement suffisant.
sinon, t'appelle l'instruction CPUID et tu recupere la string de description CPU.
c'est tres probablement pas standard du tout, mais tu peux eventuellement parser cette string pour essayer de voir si il y a la frequence dedans.
(et eventuellement fallbacker sur la mesure de qques millisecondes avec __rtdsc() si tu trouve pas.
par exemple, sur mon CPU, la string processeur, c'est ca:
"Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz"
retournee par l'instruction "cpuid" dans 3 des 4 registres de retour: ebx, ecx et edx, lorsque tu l'appelle avec eax et ecx a 0

HURRRR !
vince Le 23/03/2012 à 17:27 (tu peux ptet remplacer source=asm par un simple pre)