Histoires de benchs - Page 1

Tout d'abord,bonjour à vous qui lisez ce topic!
Bon, voila je voudrais savoir comment on fait pour calculer la vitesse d'un code en assembleur et en C.
Si vous pouviez m'expliquer le principe et me donner des exemples tout simple, genre affichage de pixel,ça serait bien cool parce que là je ne sais pas comment faire...

En vous remerçiant !

Tu comptes combien d'appel de ta fonction tu peux faire en un temps donné ...

heu, je t'ai pas mis de code, pke je sais pas si c sur PC ou TI .. et j'ai pas envie demettre du code pour les deux

bah,en fait c pour TI et comme je suis en debut d'apprentissage C et assembleur ce serait pour mesurer la vitesse de codes pour pouvoir comparer a ceux que je vais faire prochainement.
voilà...

oki, tu détournes l'auto-int 5 (vers un dummy_handler, cf doc)
pis tu comptes
y'a preqque tout dans la doc de tigcc

Ou alors tu prend une documentation du timing Motorola 68000 et tu comptes les cycles. (Pour du code en C, tu le compiles d'abord en assembleur avec tigcc -S.)

Conseil : pense aux interruptions (va voir la doc de intr.h tu auras tout ce qu'il faut dedans)

Ok, merci
Personne a une idéée de la marche a suivre en asm ?

Comme en C, mais en ASM

regarde jhw89.txt

Encore une ch'tite question, pour calculer le fps on se base aussi sur l'auto-int 5 ou bien là je viens de dire une enormite ?

oui, c ce que je te disais ...

DarkS
: pour calculer le fps on se base aussi sur l'auto-int 5

Oui, c'est une possibilité.

Sinon, encore une autre méthode de benchmarking est d'ignorer complètement les interruptions et de travailler au chronomètre tout simplement.

Tu peux te baser sur l'AI5.
Tu peux aussi te baser sur l'AI3 si tu es sur une HW2. Ce qui est pratique avec l'AI3, c'est que sa fréquence est exactement d'une seconde, donc pour mesurer le fps ça simplifie pas mal les choses. Attention cependant à le détourner proprement (sans gêner AMS).

La méthode du chronomètre, personnellement je n'ai jamais testé, mais j'ai beaucoup de doutes quant à sa précision...
Ou alors il faut laisser tourner le prog pendant plus de 1 minute.

Ok, je vous remercie tous de m'avoir eclaire sur le sujet

@++

Pour tester un code en ASM, on peut tout simplement le nombre de fois que l'on sort de cette fonction en incrémentant une vraible et au bout d'un certain temps afficher le résultat de la variable incrémenté, c'est ce que "j'utilise" pour tester la consommation CPU de PolySnd.

Voici mon code: // C Source File // Created 08/08/2003; 22:05:40 //#define USE_TI89              // Compile for TI-89 #define USE_TI92PLUS          // Compile for TI-92 Plus //#define USE_V200              // Compile for V200 #define MIN_AMS 100           // Compile for AMS 1.00 or higher #define USE_KERNEL #define SAVE_SCREEN           // Save/Restore LCD Contents #include <tigcclib.h>         // Include All Header Files #include "polysnd2.h" #include "cool.h" INT_HANDLER OldInt1 = NULL; INT_HANDLER OldInt2 = NULL; INT_HANDLER OldInt5 = NULL; volatile unsigned long counter ; DEFINE_INT_HANDLER (myint1) {    counter++; } void _main (void) {   long cpu_speed=0;      OldInt1 = GetIntVec (AUTO_INT_1);   SetIntVec (AUTO_INT_1, myint1);   counter=0;         while (_keytest (RR_ESC)!=TRUE) {        cpu_speed++;                if (counter>=256) {             printf_xy (0,0,"%lu",cpu_speed);                          cpu_speed=0;             counter=0;        }   }    SetIntVec (AUTO_INT_1, OldInt1); }

Bien sûr il manque des choses et ça doit être adapté en ASM.

geogeo: quand on fait un bench on essaie de ne rien mettre d'autre que la fonction testée dans la boucle; ici ton test de ESC déséquilibre le tout.

Et on évite aussi de définir #define USE_KERNEL sans raison. Il n'y a rien qui nécessite un kernel dans ton code.

si, l'inclusion de "polysnd2.h", qui doit être l'header dynamique, d'où l'obligation de compiler en kernel

geogeo: quand on fait un bench on essaie de ne rien mettre d'autre que la fonction testée dans la boucle; ici ton test de ESC déséquilibre le tout.

J'y avait bien pensé.
Mais je donne juste une méthode, j'ai pas dit de reprendre ce code à l'identique.... Le principe y est c'est tout.

Et on évite aussi de définir #define USE_KERNEL sans raison. Il n'y a rien qui nécessite un kernel dans ton code.

Oui, désolé.

ah ben c'était pas l'header dynamique

Ah oui, désolé, en effet j'ai mis USE_KERNEL, car j'utilisais la version dynamique de PolySnd et cela pour diverses raisons.

Bref j'ai donné le code pour lui donner une idée de comment procéder rien de plus.

donc c'est bien l'header dynamique

Si ta fonction est très petite, tu peux détourner l'ai1 qui a une fréquence de 350Mhz sur HW1 et 256Mhz sur HW2 (si je ne me trompe pas).

La méthode de Kevin est bonne mais uniquement si le temps d'execution est [très] long pour rendre la marge d'erreur due au temps de réaction négligeable par rapport au temps réellement mesuré.

l'ai1 qui a une fréquence de 350Mhz sur HW1 et 256Mhz sur HW2

Sachant que le proc est à 12 MHz, le code de l'interruption ne peut donc pas prendre plus de 0,04 cycle d'horloge

Heu merde. Retirez le M