Quelques Benchmark

View previous topic View next topic Go down

Quelques Benchmark

Post  Yann on Sun 8 Jun - 18:29

Afin d'avoir un code compréhensible, j'ai choisi dès le début d'utiliser des noms de variables intelligibles, me permettant de bien suivre l'information manipulée.
C'est globalement un bon choix, même si les contraintes de la programmation sur calculatrice m'imposent du coup d'avoir des variables globales portant ces noms (Je n'avais pas de PC donc pas d'outil de compilation à l'époque).
Une bonne conséquence, lors de la transformation des données en registre, j'ai simplement remplacé les variables par des méthodes portant les mêmes noms.
Jusque là tout va bien. Sauf que les méthode sont elle-mêmes des variables, et coûtent du temps à être recherchées puis être exécutée.

Combien de temps est donc perdu dans ces appels de variables ?
J'ai fait un test afin de fixer les idées.
L'objectif est de comparer un code inline très simple (<< 1 DROP >>) au même code appelé par variable, puis appelé par XLIB. Les résultats sont éloquents :
Boucle Vide du test (200 fois) : 0.76 s
Test avec Code Inline : 0.90s, soit 0.14s pour le code
Test en appelant le Code par variable globale : 1.80s, soit 1.04s pour Code + Appel
Test en appelant le Code par XLIB (librairie) : 1.80s, soit 1.04s pour Code + Appel

Bien que les résultats de l'appel de variable et de l'XLIB soient identiques, il faut souligner qu'il y avait très peu de variables globales (entre 2 & 4) dans le répertoire du test. La situation change dramatiquement en augmentant le nombre de variables, alors qu'elle reste stable en XLIB.

Quoi qu'il en soit, le résultat est là : plus de 600% de performances supplémentaires par code Inline. Qu'il y ait un avantage au code Inline ne surprend personne, mais à ce point là, cela fait réfléchir.

Il reste cependant important de pouvoir 'virtualiser' de tels appels de variables. Non seulement le code est plus lisible en lisant "GoldBudget" qu'en lisant "RLA <12h> SGET6" mais surtout il est possible de modifier ces appels en une seule fois, les modifications devenant valables et cohérentes pour l'ensemble du code. C'est ce qu'il s'est passé lors du passage en registres, puis en Compact Array. On peut également envisager très simplement de déplacer les variables. C'est donc une flexibilité obligatoire.

Dans les langages évolués, type C, il existe ce qu'on appelle des instructions de pré-compilation, et des macro/micro, qui permettent de définir des instructions plus ou moins compliquées qui seront remplacées par une expression plus simple et plus lisible dans le code.
Un excellent exemple d'une utilisation massive de ce principe est, à mon humble avis, l'Operating system Contiki, développé pour les senseurs (très très faible budget mémoire/calcule/énergie), et dont la première démonstration a été faite sur un Commodore 64, une machine aux performances assez proches de la calculatrice HP48.

Globalement, l'essentiel du travail est effectué en pré-compilation, parvenant à des fonctionalités très compliquées (gestion du threading multi-tâches par exemple) en très peu de mémoire et de temps de calcul.

Je n'ai pour ma part pas besoin de choses bien compliquées, mais l'équivalent me permettrait de fixer en dur la relation entre un nom de variable de compilation ("GoldBudget") et son expression dans le code (<12h> SGET6).
Bien sûr, on y perd un peu en mémoire : au lieu d'un appel XLIB, on a un code, mais pour les codes très courts, dont font partie les appels de variables, cela vaut le coup se sacrifier quelques octets.

Toutefois, il y a un hic : les outils de compilation que j'utilisais jusqu'à présent ne permettaient pas de telles définitions de macro. Il s'agit d'une version modifiée de ExternPC, que j'avais développé en 1993, et qui n'a pas evolué depuis (c'est du Turbo Pascal, autant dire que l'environnement de compilation a un peu évolué en 15 ans).

2 solutions s'offrent à moi : soit modifier ExternPC pour y intégrer cette fonctionalité, un travail relativement lourd, soit utiliser un autre compilateur qui offre déjà cette fonctionalité.
Evidemment, la seconde solution semble meilleure, d'autant plus qu'elle me forcerait à utiliser les mnémoniques standards de la HP48, au lieu d'inventer les miennes (ce qui a été le cas jusqu'à présent avec ExternPC, se basant sur le travail de Jean Michel Ferrard).

RPLCOMP, utilisé pour MkLibZ, est un bon exemple. Le code source de MkLibZ offre d'ailleurs quelques cas identiques :
DEFINE $NoCNotList :: THREE Error ;
(Génère un code d'erreur; donc $NoCNotList est remplacé dans le code par :: THREE Error ; )
Voilà exactement ce dont j'ai besoin.
Il faudrait pouvoir compléter ça par un #include, de façon à ne pas répéter à chaque fichier la transformation à effectuer, et cela aussi est offert :
INCLUDE ENTRIES.H

Voilà, avec ces fonctionalités, on est armé pour bien programmer.
RPLCOMP n'est d'ailleurs probablement pas le seul compilateur à offrir ces possibilités. J'ai également tenté Debug4x, mais sans succès. Il y a bien d'autres possibilités mentionnées sur HPCalc, mais il faut du temps pour les évaluer.

Le problème de base, vous vous en doutez, c'est qu'il faudrait tout reprogrammer, reprendre à zéro les fonctionalités coeur du programme et la façon de les employer. Et ça c'est un lourd travail. Très lourd même.

Yann
Admin

Number of posts : 174
Registration date : 2008-05-01

http://phantasie.tonempire.net

Back to top Go down

View previous topic View next topic Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum