RDSTC et fréquence du processeur

Bonjour,

J'ai lu cette page à propos du RDSTC:
http://haypo.developpez.com/article/frequence_cpu/

Mais je pense que la solution pour Linux donnée dans cet article pose un problème avec les processeurs d'aujourd'hui; à cause du multicoeurs et des fréquences variables.

J'ai l'impression qu'au final, le mieux semble être de calculer soit même, à l'aide d'un timer, le nombre de cycles que peut faire le processeur en une seconde et donc en déduire sa fréquence.
Mais je n'ai aucune idée de comment faire ça, ni même si je suis sur la bonen voie. Vous auriez une idée par hasard?

Merci!
Creak

J'ai essayé un code simple en utilisant usleep:

Code:

---

1 2 3 4 5

unsigned long long int test1 = rdtsc(); usleep(500000); unsigned long long int test2 = rdtsc();   printf("%f\n", (double)(test2 - test1) / 500000);

---

Mais les résultats sont assez dépendant de l'occupation du cpu.
J'ai fait tourner une boucle infini en shell a coté et j'obtiens des différences de plus de 60MHz de temps en temps. Ca semble logique, usleep s'arrête qu'après une durée d'au minimum celle donnée en paramètre, il peut y avoir quelques microsecondes en plus et ça provoque quelques MHz en plus dans le calcul!

Je vois pas trop comment faire :/

Edit> J'ai testé avec nanosleep (remplaçant de usleep qui est devenu obsolète), c'est un peu mieux, en parallèle avec une boucle infinie l'écart type est moins grand et la différence par rapport à la fréquence réelle est plus petite (environ +15MHz à vu de nez).

Voici le code:

Code:

---

1 2 3 4 5 6 7 8

timespec req = { 0, 500000000 }; timespec rem = { 0, 0 };   unsigned long long int test1 = rdtsc(); nanosleep(&req, &rem); unsigned long long int test2 = rdtsc();   printf("%f\n", (double)(test2 - test1) / 500000);

---

Mais bon... c'est pas des calculs digne de la Nasa tout ça! Si vous avez une technique encore meilleure, je suis preneur! :)

Bonjour ( et bienvenue ),

Il est vrai que cpuinfo est un vieux fichier qui existe depuis longtemps, pourtant il est encore d'actualité ( sauf que la méthode de lecture doit être un peu plus complète ).

En fait, les fréquences affichées ( et toute autres informations ) dans cpuinfo, sont correctes. Mais dans le cas du multicore, au lieu d'afficher qu'un seul processeur, il en affichera deux, ce qui donne par exemple:

Citation:

---

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2050 @ 1.60GHz
stepping : 8
cpu MHz : 1600.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor est tm2 xtpr
bogomips : 3196.83
clflush size : 64

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2050 @ 1.60GHz
stepping : 8
cpu MHz : 1600.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor est tm2 xtpr
bogomips : 3192.19
clflush size : 64

---

On vois bien que les fichiers sont toujours utilisable.

Pour votre essai, vous étiez mal parti. Car le compilateur va tout faire pour essayer d'optimisé votre programme, ce qui va donc modifié le nombre de cycles d'une boucle while ( donc on ne peut pas se baser sur le nombre de cycles )

De plus, nanosleep, comme usleep, et comme sleep, dépande du système. Le système est un système multi tache, donc il va perdre en précision car il va aussi s'occuper des autres processus. ( Donc les (nano)(u)sleep, ne vont pas être à 100% précis, dépendant de la charge du système ).
Et finalement, pour la même raison, le système ne va pas s'occuper de votre processus à 100% ( à moins de mettre une priorité absolue ( jouez avec le nice :aie: ) )

[EDIT]
Et le dernier exemple en assembleur, de la page que vous aviez donné, n'est t'il pas suffisant ?

C'est pas tant la vieillesse du fichier qui me fait peur en fait, il y en a plein dans Linux dans ce cas là et qui pourtant continuent de donner des infos pertinentes :)

Mon problème était (voir la suite pour comprendre pourquoi j'utilise le passé) lié aux nouvelles technologies des récents processeurs. Par exemple, avec les derniers Intel Core i7 980X et AMD Phenom II X6 1090T et respectivement leur technologie TurboBoost et Turbo Core qui permettent d'endormir 3 cœurs inactifs afin d'augmenter la fréquence des trois cœurs restants. (Source: http://www.clubic.com/processeur/pro...090t-test.html)
Du coup, il faudrait faire une fonction qui va chercher la fréquence "dynamique" à chaque trame dans la boucle de mon jeu et ça c'est pas envisageable!

Pour ce qui est du code assembleur, j'ai l'impression (je prends des pincettes, je ne suis pas un expert assembleur :)) qu'au final il fait la même chose que mon code: rdtsc, timer, rdtsc, puis calcul de la différence.

Code:

---

1 2 3 4 5

rdtsc ; nombre de cycles depuis le lancement mov ebx,eax ; partie basse mov ecx,edx ; partie haute hlt ; attente du timer rdtsc ; nombre de cycles depuis le lancement

---

En fait, je pense avoir résolu mon problème en le prenant dans l'autre sens: mon but est d'obtenir une différence de temps entre deux trames de mon jeu. J'utilise donc la fonction clock_gettime pour obtenir le temps de l'horloge CLOCK_PROCESS_CPUTIME_ID, qui est une horloge haute résolution.

J'obtiens une précision exactement identique à mon ancien système basé sur rdtsc, donc c'est nickel. Cependant, je vais garder ma fonction rdtsc pour faire les benchs de mes opérations vectorielles; le nombre de cycles c'est le meilleur moyen de savoir très précisément si on a effectivement optimisé sa fonction.

Merci bien pour votre réponse!

Est ce vraiment utile d'obtenir le temps de différence entre deux frames? ( Surtout avec une precision astronomique, comme vous semblez vouloir le faire ).

De plus pour le benchmarking, ok pour un temps en ms, mais après je ne suis pas sur que ce soit utile de pousser plus loin ... à moins que vous ayez une application ultra lourde, et qu'il faut optimiser toute les nano secondes, mais encore là, ce n'est pas vraiment une bonne chose.

Le temps de différence entre deux frames est très important, c'est ce qui permet d'éviter au jeu d'aller plus ou moins vite en fonction de la vitesse du CPU.

Pour la précision astronomique, vous avez très probablement raison, mais j'aime bien être sûr de ce que je fais :mrgreen:
En ayant une précision à la nanoseconde, je suis au moins sûr d'avoir un temps correct à la microseconde (pas d'arrondi par exemple).

Pour votre boucle de jeu, vous devriez lire ceci: http://dewitters.koonsolo.com/gameloop.html

Pour la précision, même une précision à la milliseconde ( avec arrondi ) sera suffisant. Les optimisation à la nanoseconde, ça n'existe pas ... et puis cela dépend toujours de la charge du PC ;)

Citation:

---

Envoyé par LittleWhite

Pour la précision, même une précision à la milliseconde ( avec arrondi ) sera suffisant. Les optimisation à la nanoseconde, ça n'existe pas ... et puis cela dépend toujours de la charge du PC ;)

---

C'est surtout quelque chose qui s'est perdu. Du temps des huits bits, les micro-processeurs étaient cadencés à une fréquence de l'ordre de 1 Mhz. Par contre, ils n'étaient pas déclinés en des dizaines de variantes chez plusieurs fondeurs.

À l'époque, donc, lorsque les ordinateurs étaient principalement mono-tâches, on désactivait les interruptions et on comptabilisait le nombre de cycles de chaque instruction, lequel était consigné dans la table du fabricant. Ce qui fait que non seulement les programmes − assembeur, en tout cas − étaient cadencés au cycle près, mais la stabilité était celle du quartz qui formait l'horloge système (oui, à 1 Mhz, on utilisait encore un quartz).

Les accès aux lecteurs de disquettes, par exemple, qui nécessitaient une synchro assez précise, étaient souvent effectués de cette manière. Certains jeux, également, parvenaient à utiliser deux modes d'affichage différent à la fois sur le même écran…

Citation:

---

Envoyé par Obsidian

Les accès aux lecteurs de disquettes, par exemple, qui nécessitaient une synchro assez précise, étaient souvent effectués de cette manière. Certains jeux, également, parvenaient à utiliser deux modes d'affichage différent à la fois sur le même écran…

---

En même temps, c'était mieux quand il y avait un controlleur dédié pour les disquettes, au lieu de faire tout dans le CPU.

Et les microcontrolleur on toujours la table des cylces machines ( vu que j'ai vu ça dans mon lycée ) \o/

Citation:

---

Envoyé par LittleWhite

En même temps, c'était mieux quand il y avait un controlleur dédié pour les disquettes, au lieu de faire tout dans le CPU.

---

Ce n'était pas « mieux ». Il y a toujours eu un contrôleur de disquettes, plus ou moins intelligent. C'est intéressant quand ça permet de délester la CPU de ces tâches ingrates, mais si ça doit l'empêcher de pouvoir les mener, ce n'est pas non plus un investissement. Ceci t'empêcherait de reconnaître certains formats exotiques, par exemple, très courants avec les disquettes. Pratiquement chaque fabricant d'ordinateur avait un format qui lui était propre.

Citation:

---

Et les microcontrolleur on toujours la table des cylces machines ( vu que j'ai vu ça dans mon lycée ) \o/

---

Je n'ai pas dit le contraire. Je dis que plus personne ne s'en sert. Et que c'est bien dommage.

Citation:

---

Envoyé par Obsidian

Ce n'était pas « mieux ». Il y a toujours eu un contrôleur de disquettes, plus ou moins intelligent. C'est intéressant quand ça permet de délester la CPU de ces tâches ingrates, mais si ça doit l'empêcher de pouvoir les mener, ce n'est pas non plus un investissement. Ceci t'empêcherait de reconnaître certains formats exotiques, par exemple, très courants avec les disquettes. Pratiquement chaque fabricant d'ordinateur avait un format qui lui était propre.

---

Je pensais pas que pour les disquettes, mais aussi pour le controlleur son, les ports manettes et autre...
Enfin, pour conclure ( et j'ai peur de lancer un débat ici ), je dis que l'architecture du bon vieux temps ( Atari, Amiga ) était plus appréciable ... par contre c'est mort ( ou presque )).

Citation:

---

Envoyé par LittleWhite

Pour votre boucle de jeu, vous devriez lire ceci: http://dewitters.koonsolo.com/gameloop.html

---

Bon article! Il faudrait que j'étudie l'idée de l'interpolation. Ca à l'air évident quand on parle de positions d'objets dans l'espace, mais j'ai le sentiment que tout n'est pas toujours interpolable...