GCC est étrange - Page 1

Je compile sur PC un programme (un compresseur) avec les switchs -march=i686 -O3 -s -fomit-frame-pointer.

Je le teste en lui donnant 16 Mo à compresser, mode lent/compression maxi : il met 6,5 s.

Je retire 4-5 lignes de code (non-nécessaires) au milieu de la boucle principale de la fonction de compression, et recompile. Ca doit accélérer la compression en théorie.

Je teste le nouvel exécutable sur le même fichier dans le même mode : il met 9 s !

Je ne comprend plus rien


ations répétitives de choses telles que structure->champ->x; structure->champ->y; structure->champ->z;De même, mon programme est plus lent si je remplace les utilisr->z; par pointeur= structure->champ; pointeur->x; pointeur->y; pointeu !

héhé gcc powwaaaa

Tu peut faire voir les sources ??

GCC serait-il un désoptimisateur ?

oué

Voici la fonction en question : http://alineasofts.free.fr/extern/gcc_bizarre.htm

Heu tu pourrait marquer clairement dans la source les changement que tu a fait entre avant et apres "sous optimisation" de gcc ??

Déjà, strictement parlant, tu travailles avec g++ là, pas avec GCC. Ça n'a donc rien à faire ici (Prog C TI). Ensuite:

Thibaut a écrit :
Je le teste en lui donnant 16 Mo à compresser, mode lent/compression maxi : il met 6,5 s.

Je retire 4-5 lignes de code (non-nécessaires) au milieu de la boucle principale de la fonction de compression, et recompile. Ca doit accélérer la compression en théorie.
Je teste le nouvel exécutable sur le même fichier dans le même mode : il met 9 s !

Bizarre. Il faut un testcase concret pour voir ce qui se passe.

ations répétitives de choses telles que structure->champ->x; structure->champ->y; structure->champ->z;De même, mon programme est plus lent si je remplace les utilisr->z; par pointeur= structure->champ; pointeur->x; pointeur->y; pointeu !

À mon avis, c'est normal, le pass CSE (constant subexpression elimination) peut travailler plus facilement avec du structure->champ->x qu'avec du pointeur->x. Je suppose que dans le premier cas, tu as un accès par un pointeur sur structure->champ->x alors que dans le deuxième cas, tu as un accès par un pointeur sur le début de structure->champ.

Et tu peux ouvrir un "bug report" chez les développeurs de GCC ou du portage que tu utilises.

('scusez le retard, mon père téléphonait)
Ma mémoire n'est pas très bonne puisque c'est bien plus de 4-5 lignes que j'ai retirées ! C'est tout ça :

  queue[fin_queue]= octet;  // dans fenetre itérations, on ne le comptera plus
  fin_queue++;
  fin_queue&= TAILLE_QUEUE-1;
  if (decompte_queue > 0)
  {
    decompte_queue--;
  }
  else  // si la fenêtre est complète, on peut la faire glisser
  {
    occurences[queue[debut_queue]]--;  // on ne compte plus l'apparition du fenetre-ième octet traité avant l'actuel
    debut_queue++;
    debut_queue&= TAILLE_QUEUE-1;
  }

Ces lignes ne font rien d'autre que créer une fenêtre. En les retirant, la table des occurences comptabilise tous les octets du fichier, et pas seulement les fenetre derniers traités.
Mon algo qui construit l'arbre prend le même temps, quelles que soient les occurences des différents octets.

Donc, au pire, la compression devrait prendre autant de temps, en théorie elle devrait prendre moins de temps.
En pratique, elle prend plus de temps

Kevin : Ce topic avait sa place pour moi, puisque je pensais que GCC (<=> TIGCC) était responsable.

G++ n'a rien à voir avec GCC
C'est pas une version de GCC capable de compiler du C++ ?

C'est le frontend C++ de GCC. Mais ça n'a aucun rapport avec la programmation sur TI.

> C'est le frontend C++ de GCC
Donc G++ compile grâce à GCC. Donc ça a un rapport avec les TI

Ça n'a aucun rapport avec les TI parce qu'il n'y a pas g++ dans TIGCC. Il fallait poster ça là-bas!

Est-ce qu'un admin pourrait déplacer ce topic?

Ca a un rapport avec les TIs parceque G++ fait appel à GCC, et que les programmes sur TI sont compilés par GCC, donc si GCC optimise bizarrement mon code sur PC, il optimisera bizarrement le même code sur TI !

Quelle mauvaise foi, Kevin

Thibaut a écrit :
Ca a un rapport avec les TIs parceque G++ fait appel à GCC, et que les programmes sur TI sont compilés par GCC, donc si GCC optimise bizarrement mon code sur PC, il optimisera bizarrement le même code sur TI !

Pas forcément. Les bogues de pessimisation ou de mauvaise optimisation dépendent fortement du frontend (donc du langage) et du backend (donc de la plateforme) employés.

Disons que j'ai un code en C pur.
Je le compile avec GCC.
Je le compile aussi avec G++ (sensé compiler du C, nous sommes d'accord ?).
Les deux exécutables seront optimisés différemment ?

Ce n'est pas impossible.

Et de plus, ici, tu as du code qui utilise des spécificités du C++, et puis je parie que ce n'est pas pour m68k que tu as compilé.

Dans la boucle où j'ai retiré les fameuses lignes, il n'y a pas une seule ligne de C++

> je parie que ce n'est pas pour m68k que tu as compilé.
Si ! j'ai porté G++ pour le 68000

structure->champ->x; structure->champ->y; structure->champ->z;
par
pointeur= structure->champ; pointeur->x; pointeur->y; pointeur->z;


Aller en gros pkoi c'est plus lent, et pkoi ce n'est pas un bug de gcc au lieux de vous chamailler comme d'habitude.

Dans le premier gcc peut au moment de la compilation calculer directement l'adresse de x dans ta structure, jusque la tu est okay?

Alors que dans la deuxieme ligne, meme si tu declares avant ta boucle ta variable "pointeur", tu reaffecte a chaque boucle une nouvelle copie de ta structure!!! En plus c'est une erreur je pense, car si tu compares les deux adresses de pointeur et structure->champ, tu n'auras pas la meme adresse!

Dans le cas ou structure->champ et un pointeur et "pointeur" aussi, de toute facon, tu fais une affectation ca prend du temps

J'ai bien l'impression que tu es totalement à côté de la plaque

> gcc peut au moment de la compilation calculer directement l'adresse de x dans ta structure
Pas du tout. Il ne peut pas deviner à quelle adresse malloc allouera les champs.

> tu reaffecte a chaque boucle une nouvelle copie de ta structure
Pas du tout. On copie l'adresse de la structure pointée, pas la structure.

> si tu compares les deux adresses de pointeur et structure->champ tu n'auras pas la meme adresse
C'est nouveau ça

> tu fais une affectation ca prend du temps
On lit une fois pour toute structure->champ. Ca prend moins de temps que de recalculer 3 fois structure->champ.

sa doit etre un pbm d'optimisation au niveau du code asm.. :/

Gcc a du progré a faire de tte... :/

Essaye ton code avec MSVC pour voir

Compilé avec M$VC, mon programme compresse en 8 secondes, contre 6,5 avec GCC.
GCC powwwwwwaaaaaaaaaaaaaa

Mais tu as raison, je vais voir si M$VC "désoptimise" quand j'optimise, ça ne n'ai pas essayé