Le compilateur GTC est-il mauvais ? - Page 1

Dans ce topic, je vais comparer les performances des deux compilateurs C les plus sérieux du monde TI68k : TIGCC et GTC.

GTC, qu'une ou deux personnes qualifient de "jouet", compile pourtant des gros projets comme TICon45, TIChess, ou encore Einstein.



Directives utilisées :

TIGCC : Par défaut (-Os -Wall -W -Wwrite-strings -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -fomit-frame-pointer)

GTC : Par défaut (-Os).

Pour chaque test, -Os sera remplacé successivement par -O2 et -O3 afin de pouvoir comparer les performances des compilateurs pour trois niveaux d'optimisation différents.


Cliquez :
./2 COMPARAISON DES TAILLES
./69 COMPARAISON DES VITESSES
./322 BILAN ET CONCLUSION

Voici les résultats concernant la taille des fichiers générés par les compilateurs.



Voici les résultats pour Einstein 3.1 :

Avec la ligne de commande par défaut (explicitée dans le post ./1) :


Version binaire (càd non compressée) :

1) GTC          : 30066 octets
2) TIGCC 0.96b8 : 30237 octets

Version compressée (lanceur + ppg) :

1) GTC          : 16695 octets
2) TIGCC 0.96b8 : 18458 octets

Avec la ligne de commande par défaut, mais en remplaçant -Os par -O2 :


Version binaire (càd non compressée) :

1) GTC          : 30368 octets
2) TIGCC 0.96b8 : 35565 octets

Version compressée (lanceur + ppg) :

1) GTC          : 16849 octets
2) TIGCC 0.96b8 : 20762 octets

Avec la ligne de commande par défaut, mais en remplaçant -Os par -O3 :


Version binaire (càd non compressée) :

1) GTC          : 30440 octets
2) TIGCC 0.96b8 : 38117 octets

Version compressée (lanceur + ppg) :

1) GTC          : 16833 octets
2) TIGCC 0.96b8 : 21428 octets

Voici les résultats pour TI Chess 4.0 :

Avec la ligne de commande par défaut (explicitée dans le post ./1) :


Version binaire (càd non compressée) :

1) TIGCC 0.96b8 : 48119 octets
2) GTC          : 48936 octets

Version compressée (lanceur + ppg) :

1) GTC          : 26227 octets
2) TIGCC 0.96b8 : 29786 octets

Avec la ligne de commande par défaut, mais en remplaçant -Os par -O2 :


Version binaire (càd non compressée) :

1) GTC          : 49288 octets
2) TIGCC 0.96b8 : 56919 octets

Version compressée (lanceur + ppg) :

1) GTC          : 26397 octets
2) TIGCC 0.96b8 : 33751 octets

Avec la ligne de commande par défaut, mais en remplaçant -Os par -O3 :


Version binaire (càd non compressée) :

1) GTC          : 49456 octets
2) TIGCC 0.96b8 : 66264 octets => "Program size of 66264 bytes exceeds maximum by 750"

Version compressée (lanceur + ppg) :

1) GTC          : 26447 octets
2) TIGCC 0.96b8 : N/A

Voici les résultats pour TICon45 1.41 :

Pour la compilation avec TIGCC, j'ai rajouté -mregparm=5 dans la ligne de commande explicitée au post ./1. C'est parceque cette option figurait dans les options originelles du build.bat de ce programme.
De plus, 2 petites modifications ont été apportées au code :
- à la ligne 405 de c4algo.c, j'ai mis if (random(num_of_equal)==0) en commentaire. La raison est que l'algorithme de l'IA ne doit prendre aucune décision au hasard si l'on veut pouvoir comparer les vitesses de réflexion.
- à la ligne 24 de ticon45.c, j'ai mis #define USE_FLINE_ROM_CALLS en commentaire, car GTC ne supporte pas cette directive. La directive USE_INTERNAL_FLINE_EMULATOR reste définie.

Avec la ligne de commande de base :


Version binaire (càd non compressée) :

1) TIGCC 0.96b8 : 10693 octets
2) GTC          : 11078 octets

Version compressée (lanceur + ppg) :

1) GTC          : 7191 octets
2) TIGCC 0.96b8 : 8138 octets

Avec la ligne de commande de base, mais en remplaçant -Os par -O2 :


Version binaire (càd non compressée) :

1) GTC          : 11224 octets
2) TIGCC 0.96b8 : 13803 octets

Version compressée (lanceur + ppg) :

1) GTC          : 7271 octets
2) TIGCC 0.96b8 : 9690 octets

Avec la ligne de commande de base, mais en remplaçant -Os par -O3 :


Version binaire (càd non compressée) :

1) GTC          : 11284 octets
2) TIGCC 0.96b8 : 15063 octets

Version compressée (lanceur + ppg) :

1) GTC          : 7309 octets
2) TIGCC 0.96b8 : 10084 octets

Interprétation :

Avec -Os :

GTC produit des exécutables plus gros que TIGCC. Ils sont plus gros de 1,6% en moyenne.
TIGCC produit des fichiers compressés plus gros que GTC. Ils sont plus gros de 12,4% en moyenne.

Avec -O2 :

TIGCC produit des exécutables plus gros que GTC. Ils sont plus gros de 18,5% en moyenne.
TIGCC produit des fichiers compressés plus gros que GTC. Ils sont plus gros de 28% en moyenne.

Avec -O3 :

TIGCC produit des exécutables plus gros que GTC. Ils sont plus gros de 30,9% en moyenne.
TIGCC produit des fichiers compressés plus gros que GTC. Ils sont plus gros de 32,6% en moyenne.



Le vainqueur globalement est GTC.

Remarque : la prochaine version de GTC prendra encore 230 octets de moins pour la version compressée

alors moi j'ai une autre question depuis un petit moment : Pollux, tu le paies combien Thibaut ?

Wow, respect Pollux.

Zephyr (./4) :
alors moi j'ai une autre question depuis un petit moment : Pollux, tu le paies combien Thibaut ?

je le paye en betas de GTC

ok ^^

Oui oui, rien de plus On se connaît même pas et aucun € n'a jamais transité entre nos comptes bancaires.

Pour clarifier les choses : Je souhaite juste apporter le soutien et la reconnaissance que Pollux mérite. Son travail remarquable est bafoué avec trop d'énergie par certains.

Thibaut (./8) :
Son travail remarquable est bafoué avec trop d'énergie par certains.

"Certains" au singulier, et c'est pas la première fois qu'ils bafouent quelque chose avec énergie, ça fait même un certain temps qu'ils ont perdu toute crédibilité à cause de cette attitude amha

Enfin pour présenter les choses autrement : je ne pense pas que l'avis complètement biaisé de Kevin et ses éternelles critiques entachent ton compilateur préféré, mais bien sûr ça n'empêche pas de féliciter Pollux pour son boulot (enfin perso j'ai pas testé faute d'intérêt pour les ti, mais d'après ce que je lis ça a l'air très bien ^^)

Tu utilises quelle version de TIGCC là? Si c'est la 0.95, réessaie avec la 0.96 Beta 8.

Et sinon, tu n'as peut-être pas activé les bonnes options, il y a souvent moyen de gagner de la place si on sait ce qu'on fait. Si tu m'envoies ton projet, je peux voir ce que je peux faire pour réduire la taille.

J'utilise les options par défaut de TIGCC :

-Os -Wall -W -Wwrite-strings -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -fomit-frame-pointer

C'est bon, ce sont plutôt les options du linker et/ou de TIGCCLIB que tu devrais tuner (certaines des options de TIGCCLIB jouent aussi sur le linker, par exemple les formats de relogements). Pour le linker, vérifie que toutes les options d'optimisation sont cochées. Pour TIGCCLIB, le format par défaut pour les ROM_CALLs est le plus portable, mais aussi le moins efficace. TIGCC gère des formats plus efficaces, par exemple les F-Line ROM_CALLs. Ou bien sûr le classique OPTIMIZE_ROM_CALLS. D'autres options pourraient aussi être intéressantes, par exemple les relogements compressés (le format MLink est probablement le plus efficace), une fonctionnalité de ld-tigcc que GTC n'a pas.

Il est aussi possible que Einstein soit un des logiciels qui se retrouvent avec une section BSS avec plein de petites variables (pas très efficace), essaie de compiler avec -mno-bss pour voir si ça change quelque chose.

La section BSS d'Einstein fait 36 octets
Pour le reste des options, je veux bien essayer. Mais si c'est pour faire perdre de la vitesse, je préfère compiler avec GTC.

Je viens de terminer un portage de TI Chess. Il vient de compiler 456 ko de sources en moins d'une seconde.
Les comparaisons de la taille des fichiers sont ci-dessus et sont encore plus éloquentes.

GTC est vraiment pas mal pour un "jouet" "inutilisable", tu trouves pas ?

Euh attends, l'exécutable par défaut de TI-Chess est compilé avec des switches différents par fichier, ce n'est pas entièrement optimisé taille. C'est quoi la version exacte que tu as compilée?

Thibaut (./2) :
Version compressée (lanceur + ppg) :

GTC     : 26007 octets
TIGCC   : 35474 octets

Je veux bien savoir d'où tu sors cette taille. Quand je compile TI-Chess 4.17 (la dernière version) avec le script de compilation de Lionel et TIGCC CVS HEAD, j'ai un .9xy de 25179 octets, ce qui comprend le header côté PC, donc 25091 octets on-calc. Le lanceur ne fait qu'1 KO, donc la différence n'est pas là non plus. Et ce n'est pas entièrement optimisé taille. Si je change le script pour compiler engine.c aussi avec -Os, j'ai un PPG de 23597 octets sur PC ou 23509 on-calc.

À ces tailles s'ajoute le lanceur de 1055 octets.

Je viens de tout compiler avec -Os -fomit-frame-pointer -c -Wall -W -Wwrite-strings. J'ai mis à jour les résultats.

J'ai porté la version 4 et c'est celle-là qui a servit pour la comparaison. Tu ne peux pas comparer la 4.17 à la 4.

[edit ] J'ai en finalement compilé avec les options par défaut de TIGCC (listées dans le ./1) le 01/10 à 13h15, donc les résultats ont changés et sont à jour dans le post ./2

Thibaut (./16) :
En effet. Je viens de tout compiler avec -Os -fomit-frame-pointer -c -Wall -W -Wwrite-strings.

Sauf que ce ne sont pas les options utilisées par TI-Chess normalement, mais:
-DUSE_TI92P -DUSE_V200 -DMLINK_FORMAT_RELOCS -DLANG_$1 -Os -fno-if-conversion -fno-function-cse -fomit-frame-pointer -mregparm=5 -ffunction-sections -fdata-sections --merge-constants -fmerge-all-constants -Wa,--all-relocs -c -Wall -W -Wwrite-strings -save-temps -mno-bss -freg-relative-a5
Pas mal de ces options ne sont pas du tout supportées par GTC, donc TIGCC permet bien d'avoir des exécutables plus petits.

C'est les options du build.bat de TI Chess 4. Je vais regarder avec tes options.

Plus petits, ok ,mais combien de fois plus lents...

Attention, c'est pour la compilation, ça. Il faut aussi les bons switches pour la phase de linking:
tigcc -DUSE_TI92P -DUSE_V200 -DMLINK_FORMAT_RELOCS -DLANG_$1 -Os -fno-if-conversion -fno-function-cse -fomit-frame-pointer -mregparm=5 --optimize-code --cut-ranges --reorder-sections -ffunction-sections -fdata-sections --merge-constants -fmerge-all-constants -Wa,--all-relocs -Wall -W -Wwrite-strings -save-temps -mno-bss -freg-relative-a5 tichess.c logo.o generic.o bg_ti92.o interrupt.o input.o menu.o gui.o engine.o clocks.o board.o loadsave.o infoboards.o -o ticstart -pack tichess

Thibaut (./18) :
Plus petits, ok ,mais combien de fois plus lents...

-mregparm=5 ne ralentit pas, au contraire.
-fmerge-all-constants ne ralentit pas non plus (aucune influence sur la vitesse).
-freg-relative-a5 ne ralentit pas, au contraire.
MLINK_FORMAT_RELOCS ne ralentit pas non plus (aucune influence sur la vitesse).

Version binaire (càd non compressée) :

GTC       : 48598 octets
TIGCC -Os : 47409 octets

Version compressée (lanceur + ppg) :

GTC       : 26007 octets (25777 avec le prochain GTC)
TIGCC -Os : 25459 octets

GCC passe légèrement devant pour le PPG, et l'écart est un peu plus significatif pour le binaire.

Mais es-tu sûr qu'on ne perd pas en vitesse par rapport à -Os -fomit-frame-pointer -Wall -W -Wwrite-strings ?

Presque sûr. Les seuls switches qui pourraient ralentir dans tout ça, ce sont -fno-if-conversion et -fno-function-cse. Mais il n'est pas dit qu'ils ralentissent vraiment en pratique. Les autres switches accélèrent ou laisse la vitesse inchangée.

Donc tout ceci est activé par défaut quand on crée un nouveau projet ?

Non, parce qu'il y a des cas où ces switches ne fonctionnent pas ou pas bien.
Ce qui est activé par défaut pour les nouveaux projets dans l'IDE, ce sont les switches pour l'optimisation linker (--optimize-code --cut-ranges --reorder-sections -ffunction-sections -fdata-sections --merge-constants, et aussi --remove-unused que Lionel n'a pas mis). De plus, -fomit-frame-pointer est maintenant impliqué par -Os (et -O2 et -O3 et -O4 (l'-O4 de TIGCC est l'-O3 de GCC, notre -O3 est moins aggressif dans l'inlining parce que les réglages de GCC en -O3 sont tellement gourmands en taille que c'est inutilisable sur calculatrice pour beaucoup de projets)).

OK. Pour compiler Einstein, j'ai rien retiré à la ligne de commande et je n'ai pas décoché de case dans l'onglet du linker. Il est donc compilé avec la plupart des options d'optimisation.

GTC semble donc plus performant que TIGCC avec les options d'optimisation par défaut.

Attends, tu utilises quoi comme switches pour GTC? Si tu actives EXE_OUT, ça active silencieusement les F-Line ROM_CALLs aussi (plus petits, mais moins compatibles et plus lents), cf. _nostub.h qui teste #if defined(USE_FLINE_ROM_CALLS) || defined(EXE_OUT). Donc il faudra utiliser USE_FLINE_ROM_CALLS avec TIGCC aussi pour que ce soit comparable.

Je suppose que l'émulateur utilisé par GTC dans ce cas est interne au code de lancement, c'est mauvais, ça va boguer sur HW3/HW4 sans HW3Patch. Je déconseille aussi USE_INTERNAL_FLINE_EMULATOR pour un explorateur de fichiers, pour la même raison. (Mais la méthode de GTC, si j'ai bien compris comment ça fonctionne, bogue même pour un programme "normal", c'est pour ça qu'il n'y a pas d'émulateur F-Line dans le pstarter de TIGCC!) Mais il faudra faire très attention pour que ton explorateur marche sous ces conditions de toute façon, je ne pense pas que ton code actuel fonctionnera.

TI-Chess 4.17 définit USE_FLINE_ROM_CALLS et USE_INTERNAL_FLINE_EMULATOR dans hardware.h. Si ce n'était pas déjà mis dans ta version, essaie de les définir dans la ligne de commande. C'est pour ça que -fno-function-cse est utilisé aussi, c'est nécessaire pour que la substitution F-Line puisse être faite partout.

Voilà les options TIGCCLIB dans le hardware.h de TI-Chess 4.17:

//#define OPTIMIZE_ROM_CALLS // makes ROM calls smaller and faster
//#define NO_EXIT_SUPPORT    // new directive from TIGCCLIB 2.4SP1 (we need no
                           // exit support so code becomes smalles this way)
#define USE_FLINE_ROM_CALLS
#define USE_INTERNAL_FLINE_EMULATOR
#define MIN_AMS 100

OPTIMIZE_ROM_CALLS est en commentaire parce que c'est inutile avec les F-Line ROM_CALLs, NO_EXIT_SUPPORT parce que TIGCC >=0.95 détecte ça automatiquement.

Je n'utilise aucune option de GTC Pas de F Line Emulator, donc.
C'est quoi EXE_OUT ? Je viens d'essayer de chercher dans la doc de GTC, mais elle a été retirée.

[edit] de toute façon, il ne doit pas y avoir plus d'une dizaine d'appels en ROM dans Einstein.

Le #define MIN_AMS 100 est important en tout cas, parce que l'AMS minimum par défaut est 1.01 et TIGCC vérifie si l'AMS minimum est satisfait contrairement à GTC qui crée des programmes qui plantent sans avertissement si on les lance sur un AMS insuffisant (le seul endroit où or higher apparaît dans les sources, c'est dans le binaire de son IDE, qui est compilé avec TIGCC). Donc on perd de la place si on demande AMS 1.01 alors que 1.00 suffirait.

Thibaut (./28) :
C'est quoi EXE_OUT ? Je viens d'essayer de chercher dans la doc de GTC, mais elle a été retirée.

En fait je ne sais pas non plus. Je pensais que c'était utilisé pour la compression automatique, mais après avoir regardé les sources de plus près, j'ai l'impression que non. Faut demander à Pollux.