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

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

Re: Dhrystone Benchmark (examen rapide du binaire)

Show all headers | View raw

Salut,

Arachide écrit :
> J'ai commencé à tracer le binaire DRY030O2 (car sur le TT, PURE DEBUGGER
> marche bien).
>
> Un début d'examen de la boucle principale montre que DRY ne teste plus
> du tout ce qui était voulu à l'origine mais bien la puissance du
> compilateur.
>
> entre crochets mes commentaires!
>
> On commence:
>
>      /***************/
>      /* Start timer */
>      /***************/
>
>      Start_Timer();
>
>      for (Run_Index = 1; Run_Index <= Number_Of_Runs; ++Run_Index)
>      {
>
>        Proc_5(); [appel disparu]
>        Proc_4(); [appel disparu]
>      /* Ch_1_Glob == 'A', Ch_2_Glob == 'B', Bool_Glob == true */
>
>          [le binaire se contente de remplir les 3 variables ci-dessus
> car il a remarqué que Proc_5 et Proc_4 renvoyaient des constantes, deux
> procédures éliminées!!]
>
>        Int_1_Loc = 2;
>        Int_2_Loc = 3;
>        strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 2'ND STRING");
>          [cet appel existe!)]
>
>        Enum_Loc = Ident_2;
>        Bool_Glob = ! Func_2 (Str_1_Loc, Str_2_Loc); [celui-là aussi!]
>      /* Bool_Glob == 1 */
>
>
>        while (Int_1_Loc < Int_2_Loc)  /* loop body executed once */
>
> [la boucle a disparu entièrement !!!! Le binaire assigne simplement les
> valeurs aux constantes car le résultat de la boucle est prévisible]
>        {
>      Int_3_Loc = 5 * Int_1_Loc - Int_2_Loc;
>        /* Int_3_Loc == 7 */
>      Proc_7 (Int_1_Loc, Int_2_Loc, &Int_3_Loc);
>        /* Int_3_Loc == 7 */
>      Int_1_Loc += 1;
>        } /* while */
> [fin de disparition]
>
>      /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
>        Proc_8 (Arr_1_Glob, Arr_2_Glob, Int_1_Loc, Int_3_Loc);
> [l'appel est fait avec Int_1_Loc et Int_3_Loc passées comme constantes
> car valeurs prévisibles]
>
>      /* Int_Glob == 5 */
>        Proc_1 (Ptr_Glob); [l'appel est fait ici aussi]
>
> Bref, au final, on voit bien l'intention de départ n'est plus du tout
> respectée. Proc_5 et Proc_4 qui vont tester des assignations binaires ne
> sont plus dans la course.
> Le While est sauté également, les passages de paramètres à partir de
> variables deviennent des constantes, etc...
>
>      Et pourtant, le compilateur n'est pas forcément omniscient, j'ai
> remarqué un petit détail dans cette ligne:
>      Bool_Glob = ! Func_2 (Str_1_Loc, Str_2_Loc);
>
>      Le résultat de Func_2 se trouve dans le registre D0.L à un moment.
>      Il suffirait de faire:
>      NEG.L D0    ; pour inverser le résultat
>      MOVE.L D0,Bool_Glob    ; pour le stocker.
>
>      Avec donc un seul accès mémoire.
>
>      Et pourtant, le GCC fait:
>
>      MOVE.L D0,Bool_Glob    ; stocke Func_2
>      NEG.L Bool_Glob        ; l'inverse
>
>      Et donc on a deux accès mémoire en écriture. Pas optimisé ça!!!!

Si le programmeur écrit un code, c'est parce que son exécution est
nécessaire. En ne réalisant pas les opérations, le binaire risque de ne
pas être conforme aux sources. Je suppose que c'est la raison pour
laquelle il y a une quantité impressionnante d'alertes à la compilation.
Mais on a affaire à un compilateur optimisant, qui ne réalise pas ce
qui est écrit. On peut donc considérer que le bench n'est pas valide.
Le programme exécuté devient à ce point réduit, que la boucle
principale tient dans le cache, et son exécution devient ultra rapide.

Le benchmark Drystone n'a pas été écrit pour un compilateur optimisant,
je suppose aussi qu'une grande quantité d'anciens codes deviennent
complètement obsolètes. Ça ne ressemble pas à la philosophie de
compatibilité au niveau des sources fondatrice du système Unix. Et
en plus, pour un très gros effort d'optimisation à la compilation, le
binaire n'est que très peu accéléré ... Ça ne vaut même pas le coup :-(

Je me demande s'il est possible par des options de compilation de
supprimer ces optimisations ? Elles sont particulièrement gênantes
dans certaines situations. Il est très facile d'optimiser un code
"à la main". Si c'est le compilateur qui s'en charge, je ne suis pas
d'accord. Les optimisations automatiques ne sont jamais bonnes, elles
ne font pas d'un mauvais codeur un bon code, et ne font gagner que très
peu de temps de calcul, au risque de produire un résultat faux. Si un
programme est lent, c'est souvent qu'il faut le repenser. Et ça, un
compilateur optimisant est trop "idiot" pour le faire automatiquement.

On est arrivé avec GNU/GCC 4 à un stade où la génération du code
échappe à la volonté du programmeur. C'est très grave selon moi !

ATARIstiquement vôtre =)

-- 
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/

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