Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : GFA Basic - Compter plus vite que son ombre
(Article écrit par Dominique Lorre et extrait d'Amiga News Tech - juin 1990)
|
|
Le GFA Basic n'est certainement pas un BASIC comme les autres puisqu'il offre une rapidité d'exécution
remarquable. Ses développeurs l'ont même doté de commandes spéciales, très proches du langage machine
et du langage C, qui permettent d'améliorer sa vitesse de calcul. Ces commandes ne faisant pas partie
du BASIC standard, elles passent trop souvent sous silence. Je vous propose de découvrir quelques-unes
d'entre elles qui, je le pense, vous seront utiles.
Six mesures de rapidité
Dans le programme dont le listing suit cet article, vous pourrez consulter six mesures de rapidité
effectuées suivant le même modèle. A chaque fois, on augmente une variable d'une unité dans une boucle,
laquelle s'interrompt lorsque l'on atteint la limite fixée au préalable (ici 50 000).
Le chronomètre (timer) de l'Amiga est consulté pour chaque boucle et nous donne une indication sur
le temps écoulé. Il faut tout de même remarquer que les résultats sont très imprécis et on ne doit
les considérer que comme des ordres de grandeur. L'imprécision est due à plusieurs facteurs parmi
lesquels on peut citer en premier le fait que l'Amiga soit une machine multitâche, en second la
précision du chronomètre lui-même qui n'est pas idéale sur de courtes périodes de temps et aussi
des instructions "transparentes" du GFA Basic qui n'apparaissent pas dans le listing mais retardent
(légèrement) le déroulement du programme (on peut citer le temps d'initialisation d'une nouvelle
variable ou certains tests comme celui de la frappe d'une touche, qui sont négligeables mais expliquent
pourquoi des différences très courtes ne doivent pas être prises en compte).
Il est néanmoins possible de corriger pour une grande part ce défaut en plaçant les tests entre les
instructions Forbid() et Permit(), qui désactiveront le multitâche pendant le test, chose très
inamicale pour l'ensemble du système.
Descriptions des boucles
La première remarque que je ferai concernera l'utilisation des nombres entiers par rapport à celle
des nombres à virgule flottante. On a certainement dû vous répéter de nombreuses fois que les nombres
entiers étaient calculés plus rapidement que les nombres à virgule flottante. Cela est tout à fait
exact mais à condition que les opérations soient des opérations sur les entiers. Dans le cas du GFA Basic,
un nombre entier sera dans une opération normale converti automatiquement en nombre à virgule
flottante, d'où une perte de vitesse non négligeable. Les résultats des boucles 1 (36,76 secondes)
et 3 (49,62 secondes) confirment d'ailleurs ce fait. La même opération est effectuée dans les deux
boucles à la différence qu'une variable à virgule flottante est utilisée dans la première boucle et
une variable entière dans la troisième.
Ce résultat est d'ailleurs paradoxal quand on examine la boucle 2. Par rapport à la boucle numéro 1, une
variable à virgule flottante est utilisée dans l'instruction FOR. Cependant, le résultat (42,9 secondes)
montre l'intérêt d'utiliser des variables entières dans les boucles FOR à chaque fois que cela est possible.
La quatrième boucle démontre l'intérêt d'utiliser les opérations entières avec les entiers puisque
la vitesse d'exécution de la boucle s'en trouve plus que doublée (17,24 secondes). L'instruction
ADD est une de ces opérations sur les entiers. Son avantage est la correspondance de cette instruction
avec le langage machine. C'est ce que l'on appelle une instruction de très bas niveau (puisque
équivalente à l'assembleur).
Pour continuer dans l'optimisation, la cinquième boucle utilise l'instruction INC qui augmente un
nombre entier de une unité. Le résultat est un gain supplémentaire de 6 secondes avec 11,12 secondes.
Il faut donc ne jamais oublier cette instruction, surtout quand on est pressé.
L'utilité de la boucle FOR aurait pu être remise en question puisqu'il est possible de faire la
même chose, notamment avec une instruction WHILE. Le score obtenu étant le plus mauvais de tous
(55,225 secondes), on se rend compte à quel point l'instruction FOR est efficace.
Et pour la fin, on cherche à gagner quelques secondes précieuses en utilisant Forbid() et Permit().
Le gain n'est somme toute pas tellement spectaculaire avec 10,22 secondes. Il est évident
que l'emploi de Disable() et Enable() aurait permis d'accélérer encore la boucle mais ces
instructions sont tellement efficaces qu'elles arrêtent également le chronomètre, la
lecture du temps n'étant plus alors possible.
Conclusion
Pour conclure, je dirai que ces différentes façons de coder mettent en évidence la difficulté
d'établir des tests de performance pour comparer la rapidité du GFA Basic avec les autres langages.
Une boucle de 1 à 200 000 s'exécute en langage C en un peu moins de deux secondes.
Suivant la manière dont on aura codé le programme "équivalent" en GFA Basic, on pourra affirmer que l'interpréteur
du GFA Basic est de 5 à 30 fois plus lent que le langage C. Cela signifie également que si vous
avez un programme écrit en GFA Basic qui n'utilisait pas ces instructions très particulières que
sont INC, DEC, ADD, SUB, DIV, MUL ainsi que quelques autres (comme BTST ou AND, d'emploi beaucoup
plus complexe mais pouvant faire des miracles) et que vous vous donniez la peine de réécrire celui-ci
en fonction de ces instructions, il ne serait pas étonnant de voir sa vitesse d'exécution augmenter
de façon significative. Les inconvénients étant une légère perte de lisibilité du programme et
surtout la création d'un code spécifique au GFA Basic, qui ne serait pas compris par un autre
dialecte BASIC. Mais optimisation et portabilité n'ont jamais fait très bon ménage...
|
