Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.sys.atari > #11354

Re: Dhrystone Benchmark

Show all headers | View raw

Le 19/07/2015 12:52, LE COAT François a écrit :

> Ce qui me permet de compiler et linker le source correctement. Lorsque
> j'exécute "dry060o2.tos" j'obtiens le résultat du test Drystone suivant
> "
> Microseconds for one run through Dhrystone:        0.4
> Dhrystones per Second:                       2475247.5
> VAX MIPS                                        1408.8
> "
> avec GNU/GCC 3.3.6. Alors que compilé avec GNU/GCC 4 ça donne
> "
> Microseconds for one run through Dhrystone:        0.3
> Dhrystones per Second:                       3773585.0
> VAX MIPS                                        2147.7
> "
> GNU/GCC 3.3.6 est donc 35% moins rapide que GNU/GCC 4 ... Mais c'est
> celui que j'utilise, parce qu'il me permet de compiler Eurêka 2.12,
> persistence of vision 3.1g etc.
>
> ATARIstiquement vôtre =)
>


Méfions nous des optimisations des compilateurs!

Le GCC en particulier est extrêmement fort là dedans: si une routine est 
courte, elle est intégrée au code du programme appelant, si un résultat 
est inutilisé, il n'est pas calculé!

OR.............

Dry ne fait que de petits sous-programmes inutiles, donc GCC triche en 
affirmant qu'il parcourt autant de fois TOUS les éléments de la boucle 
(car Dry est censé tester le passage de paramètres à un sous programme..!)

J'avais écrit un article il y a fort longtemps, on y croise Olivier et 
François. Comme c'est pas trop long, je me permets de le coller ici. 
Dites moi si j'ai abusé! Je ne referai plus:

	GNU: un compilateur qui réfléchit!
	**********************************


	Sans penser à mal, rien de tel qu'un désassemblage pour comprendre
comment fonctionne un programme. Il m'a souvent été donné de regarder à
l'intérieur de programmes sortis d'un compilateur "C": c'est là qu'on
comprend toute la difficulté d'un tel outil, c'est à dire comment
optimiser...

GNU et Pure C
-------------

	Je me suis intéressé à ces deux compilateurs en mode 68030 avec
une unité de calcul flottant, le FPU 68882. Je suis parti de ce petit bout
de programme:

double pourcent(a,b)
	{ return((b-a)*100.0/a); }

	Que j'appelais ainsi après avoir rempli mes deux variables x et y
avec deux nombres réels:

	z=pourcent(x,y);

	Cette fonction renvoie le pourcentage d'augmentation de y par
rapport à x. Exemple, si x=50 et y=52, il y a 4% d'augmentation.

	Je passe le programme à la moulinette des deux compilateurs et là,
surprises....

Format DOUBLE
-------------

	Première constatation, chez Pure C un nombre DOUBLE tient sur 10
octets et chez le GNU il n'en occupe que 8. D'après les informations que
j'ai pu récolter sur le FPU, les 10 octets du format étendu ne sont
utilisés qu'en interne par le coprocesseur afin de limiter les erreurs.
Par contre, dès qu'il dialogue avec l'extérieur, il n'a que 8 octets
significatifs!
	Pure C s'encombre donc de deux octets inutiles pour chaque nombre
réel qu'il utilise. Ceci occasionne une dépense de RAM dans les
applications traitant une grande quantité de données et une perte de
vitesse: transférer 10 octets prends plus de temps que 8.
	Et puis, en informatique, 8 est un nombre rond alors que 10 est
bâtard: accéder au 100eme élément d'un tableau de réels sur 8 octets
revient à faire un décalage sur 100, alors qu'avec 10...
	Un point pour le GNU.

Les sous-programmes
-------------------

	Deuxième constatation: si le Pure C contient un saut vers la
fonction pourcent, le GNU n'en a pas, et pour cause... Il a simplement
remplace l'appel à une fonction par le code de cette fonction elle-même.
	Ceci est des plus malin: il a intelligemment estimé que cette
fonction était assez courte et que lui ajouter un saut (instruction jsr)
et un retour (instruction rts) alourdit de manière conséquente le code. En
effet, ajouter deux instructions à une dizaine revient à +20% de code.
Sans compter la désoptimisation qu'occasionne une rupture d'instructions
lors d'un saut.
	Deux points pour le GNU.

Plus futé que le programmeur
----------------------------

	J'avais ensuite envie de faire des tests de temps, je transforme
mon appel en:

	for(i=0;i<LIMITE;i++)
		{ z=pourcent(x,y);}

	Ceci afin d'utiliser suffisamment le code pour en estimer la durée,
un seul passage étant non mesurable avec le Timer au 1/200eme. Je fus
alors sidéré en voyant les temps: le Pure C se trainait lamentablement
alors que le GNU ne semblait pas décoller de la seconde quelque
soit la LIMITE fixée.
	La encore, le désassemblage fut la solution. Mon bout de programme
est un non-sens de programmation. Le calcul de Z ne dépend que de X et Y.
Et comme ces deux derniers ne varient pas, calculer Z une fois donne le
même résultat que calculer Z mille fois.
	Le GNU s'en est rendu compte et ne fais effectivement le calcul
qu'une seule fois: le reste de la boucle tourne a vide.
	Trois points pour le GNU.

Encore plus que plus
--------------------

	Au sortir de ma boucle, mon programme affichait Z. J'ai retiré
cette instruction. De ce fait, Z lui même devient inutile. Le GNU s'en
rend aussitôt compte et travaille alors dans une boucle vide sans jamais
calculer la fonction pourcent! Le Pure C lui, mouline comme il peut...
	Quatre points pour le GNU.

Et même plus
------------

	Un coup d’œil au reste de la boucle montre que le GNU met un soin
particulier à utiliser au maximum les registres du CPU et du FPU. Par
exemple, mon compteur i et la valeur LIMITE sont des registres CPU. Dans
le Pure C, ce n'est pas systématiquement le cas, d'autant plus que j'avais
déclare i en LONG (4 octets) et non en INT (2 octets) ce qui semble le
perturber au niveau de l'optimisation.
	Autre optimisation, la valeur 100.0 utilisée dans la fonction
pourcent, comme toutes les puissances de 10, est une constante incluse
dans le FPU. Le GNU utilise cette constante alors que le Pure C a mis la
valeur 100 en RAM sur 10 octets qu'il faut à chaque fois charger vers le
FPU.
	Cinq points pour le GNU.

Les utilisateurs
----------------

	J'ai recueilli les avis de deux utilisateurs. L'un d'entre eux,
Olivier Landemarre, souligne les qualités du Pure C: rapidité de
compilation, programmes plus compacts en sortie, besoin de moins de RAM,
passage de paramètres par registres et non sur la pile. Mais il encense
pas moins le GNU: nombre impressionnant de paramètres permettant d'affiner
la compilation et de tirer le meilleur parti de chaque processeur, grande
portabilité, bugs corrigés car c'est un kit qui évolue encore.
	Le second, François le Coat, partage sensiblement le même avis: le
Pure C est parfait lorsque le source a été conçu en fonction de ses
limitations. En revanche, pour un programme comme POV, l'adapter au Pure C
est un travail de titan: dans ce cas le GNU se révèle bien plus à son
aise, fournit un exécutable plus rapide et moins buggé.

Ou peut-on le trouver?
----------------------

	Sur ce site FTP allemand par exemple:

ftp.tu-harburg.de/pub/software/systems/atari/gnu/gcc/2.8.1/gcc-281c.lzh

	C'est donc la version 2.8.1 la dernière en date ou moment ou
j'écris ces quelques lignes.


En Bref
-------
	Sur Atari la puissance des machines ne change pas tous les 4 mois.
Il nous faut trouver des solutions logicielles pour compenser. Le Pure C a
sans doute fait son temps, même si il est extrêmement convivial et facile
d'accès.
	Le GNU tire bien mieux parti de nos processeurs, l'optimisation
est de bien meilleure qualité, la réflexion autour du source prend
vraiment en compte l’état précédent et l'utilisation à venir des calculs
en cours. Il reste que cet outil de développement est plus obscur, mais
faire l'effort de s'en servir vaut certainement le coup.

	Et puis, le GNU C n'est pas limité au monde Atari, il permet de
récupérer les sources d'autres programmes développés sur d'autres
plateformes avec un minimum d'adaptation surtout depuis que des cartes
VGA/SVGA standard sont connectables sur un Atari (NOVA sur TT, cartes sur
Hadès, Milan). C'est d'ailleurs avec "la bible du PC" que je sais o— taper
dans les registres Hardware de ma carte NOVA.
	N'avez vous pas entendu parler de jeux sur PC dont les sources
sont disponibles? C'est tentant, non?

	Guillaume Tello
	gtello@wanadoo.fr

Back to fr.comp.sys.atari | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Dhrystone Benchmark LE COAT François <lecoat@atari.org> - 2015-07-18 22:22 +0200
  Re: Dhrystone Benchmark LE COAT François <lecoat@atari.org> - 2015-07-19 12:52 +0200
    Re: Dhrystone Benchmark Arachide <houten.van@orange.fr> - 2015-07-19 13:45 +0200
      Re: Dhrystone Benchmark OL <o.l@lutece.net> - 2015-07-19 19:32 +0200
      Re: Dhrystone Benchmark (examen rapide du binaire) LE COAT François <lecoat@atari.org> - 2015-07-20 15:15 +0200
        Re: Dhrystone Benchmark (examen rapide du binaire) Arachide <houten.van@orange.fr> - 2015-07-20 15:37 +0200
      Re: Dhrystone Benchmark (examen rapide du binaire) "Daroou" <daroouAR08A5EfreeP01NTfr> - 2015-07-20 20:08 +0200
        Re: Dhrystone Benchmark (examen rapide du binaire) "Daroou" <daroouAR08A5EfreeP01NTfr> - 2015-07-20 20:20 +0200
        Re: Dhrystone Benchmark (examen rapide du binaire) LE COAT François <lecoat@atari.org> - 2015-08-02 18:35 +0200

csiph-web