Le compilateur GTC est-il mauvais ? - Page 5

Oui mais le programmeur lambda n'a pas envie - ou pas le temps - de réécrire la bibliothèque de son compilateur à chaque programme qu'il fait.

Thibaut, j'attends toujours que tu refasses tes tests avec TIGCC 0.96 Beta 8. Parce que tes résultats là sont vraiment sans valeur.
(D'ailleurs en relisant le topic, je me rends compte que je t'ai demandé ça dès le ./10, tu as fait exprès de ne pas répondre à ma question et de continuer à tester avec la version de 2004, c'est ça que j'appelle de la mauvaise foi. )

Et en fait:

Thibaut (./16) :
[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

Il manque -ffunction-sections -fdata-sections dans tes "options par défaut", peut-être là aussi parce que ta version de TIGCC est obsolète.

Maintenant j'ai plutôt envie que ETP soit un frontend de GTC et pas de TIGCC.

L'architecture de GTC n'est pas faite pour ça, tu auras des problèmes de licence aussi (le compilateur C est dérivé d'un compilateur sous une licence non-libre - bah oui, c'est aussi une adaptation d'un compilateur existant, tu es le seul à réinventer la roue!), et puis tu pourras générer seulement du code 68k avec ça.

Et puis le code généré est moins efficace que celui de GCC 4, Thibaut a comparé avec un GCC 3 de 2004.

J'ai édité mon ./39.

Kevin Kofler (./115) :

Pollux (./114) :
Et puis bon l'arrêt du support n'empêcherait pas les mises à jour, seulement il faudra utiliser un AMS patché plutôt que celui d'origine...

Tu sais faire un patch pour contourner la vérification des signatures? Du coup ça m'intéresse.

Non j'en sais rien, ça m'intéresse pas pour le moment, mais 1) c'est sûrement faisable 2) c'est sûrement possible de remplacer la clé publique par une autre 3) sans la contourner c'est aussi possible de préinstaller la Flashapp dans la ROM... (c'est ce que fait le programme d'Extended, très pratique pour tester rapidement une app dans un ému)

Alors il faudra que tu m'expliques le format utilisé...

Moi, pour un ROM_CALL relogé, je compte un jsr + le placeholder pour l'adresse absolue (6 octets), plus l'information de relogement. Et je ne vois pas comment faire aussi rapide que ça en moins de place.

C'est compressé, donc même si ça prendra 6 octets en RAM une fois chargé, dans le programme compressé ça ne prend pas tant de place que ça

Martial Demolins (./116) :
Pollux -> Mais il convient pour 95% des cas. Sauf si la routine graphique principale de ton jeu est bourrée de ROM calls, mais alors tu dois pas chercher la vitesse.

95% ça m'étonnerait ; évidemment dans pas mal de cas les F-line peuvent suffire, mais ça ne me paraît pas très raisonnable comme configuration par défaut : la taille est peut-être minimale (et encore, il faut installer un émulateur de F-line qui prend pas mal de place), mais comme c'est très très lent c'est pas un très bon compromis entre taille et vitesse...

Martial Demolins (./122) :
Surtout que la vitesse d'un mem* par rapport à l'exécution du handler de f-line (j'en ai écrit , ça doit taper dans les 12-14 lignes...)

En mode F-line, l'overhead est de 400 cycles ; un appel à strcpy()/strcmp()/etc avec une petite chaîne de caractères en prend nettement moins, donc ça veut dire que pas mal de programmes seront 3x plus lents à cause de ça :/
(pareil pour des trucs comme HeapDeref() qui ne font pas grand-chose mais qu'on est bien obligé d'appeler si on veut éviter de faire des hacks)

Pollux (./128) :
C'est compressé, donc même si ça prendra 6 octets en RAM une fois chargé, dans le programme compressé ça ne prend pas tant de place que ça

Ça sera toujours plus gros que le F-Line, je pense.
Mais ld-tigcc gère ça aussi (KERNEL_FORMAT_ROM_CALLS).

Je dis pas que tigcc le gère pas, hein ^^ Juste qu'à mon avis c'est le meilleur compromis ; on peut peut-être grapiller des octets avec les F-line, mais c'est dangereux niveau vitesse.

Kevin Kofler (./126) :
L'architecture de GTC n'est pas faite pour ça, tu auras des problèmes de licence aussi (le compilateur C est dérivé d'un compilateur sous une licence non-libre - bah oui, c'est aussi une adaptation d'un compilateur existant, tu es le seul à réinventer la roue!), et puis tu pourras générer seulement du code 68k avec ça.

Oui, pour la portabilité je recommande encore une fois de générer du code C plutôt que dépendre d'un seul compilateur (mais ça dépend de l'expressivité du langage, pour le savoir il faudrait qu'Onur sache à peu près vers où il veut mener ETP).

Quant aux histoires de licences, GTC pourrait bien devenir libre (mais je préfère ne pas trop m'avancer là-dessus)

Eh bien Kevin, on dirait que tu paniques !
Malheureusement j'ai pas que des comparaisons de compilateurs à faire Je suis pris par des cours, une copine, des potes (et accessoirement : ma vaisselle, mes courses).
Je vais faire la comparaison que tu attends, quand j'aurais à nouveau du temps.

vince, tu devrais te reconvertir dans la voyance Ca paie bien en plus.

Kevin Kofler (./133) :
topics/2-103177-comment-ne-pas-faire-un-benchmark

Enorme ce topic

(mais c'était peut-être pas le but recherché... ^^)

Voilà, pour faire plaisir à Kevin, j'ai pris le temps de recompiler Einstein avec TIGCC 0.96b8 (version non officielle mais à utiliser absolument d'après ce qu'il dit ici, mais pas d'après ce qu'il dit sur son site).
J'ai aussi recompilé avec le tout dernier GTC que m'a fourni Pollux hier.

Le test de taille est fait, il est dans le post ./2.

Pour les premiers tests d'il y a 2 jours, j'avais oublié de citer -ffunction-sections dans la liste des options utilisées, mais elle était bien présente dans la ligne de commande.

joli travail Pollux [bis]

Mais ce test n'utilise toujours pas tout le potentiel de TIGCC, les options sont les options par défaut.
Il n'a pas mis les MLINK_FORMAT_RELOCS par exemple.
De plus, un TIGCC public est comparé avec une version de GTC qui n'a jamais été publiée.

Kevin Kofler (./138) :
Mais ce test n'utilise toujours pas tout le potentiel de TIGCC, les options sont les options par défaut.

Faut être un peu cohérent D'un côté tu dis qu'il ne faut surtout pas changer les options par défaut, et de l'autre tu râles parce qu'il les a conservées...

Je dis qu'il ne faut pas les supprimer, en revanche, il convient souvent d'en rajouter!
Je dis bien les options "strict minimum" quand je poste, ça veut dire que je conseille celles-là et plus.

Mais a un moment, il faut s'arreter. Tu ne vas pas faire changer les options de compilation suivant le type de code a compiler.
gtc a deux types d'options (default et vitesse) d'apres ce que j'ai compris, et donc le test doit se faire pareil avec tigcc: l'option par defaut est fournie dans l'IDE si je me rappelle bien, et celles de vitesse, tu peux les donnees si tu veux

Kevin : Tu es drôle

Kevin Kofler (./138) :
De plus, un TIGCC public est comparé avec une version de GTC qui n'a jamais été publiée.

C'est tout ce que tu as comme "argument"

Je viens de faire le test sur TI Chess 4, cf ./2.
TIGCC produit un exécutable plus petit de 1,7%.
Par contre, la version compressée de GTC est plus petite de 12% que la version compressée de TIGCC.

nEUrOO (./141) :
Mais a un moment, il faut s'arreter. Tu ne vas pas faire changer les options de compilation suivant le type de code a compiler.

Bah si, c'est bien comme ça que fonctionne TIGCC, c'est très flexible, et on peut faire des choix en fonction du programme. Par exemple, un programme avec beaucoup de relogements est mieux en MLINK_FORMAT_RELOCS ou COMPRESSED_FORMAT_RELOCS, un programme avec peu de relogements est mieux avec le format natif. Et si le programme est compatible avec ces options (il y a des limitations dans les 2 cas), on peut aussi éliminer les relogements complètement avec -freg-relative=an (n = 4 ou 5 normalement) ou -mpcrel.

Les options par défaut sont choisies pour:
* fonctionner dans tous les cas (ce qui élimine -freg-relative=an ou -mpcrel),
* ne pas créer un overhead fixe, la logique étant que les options par défaut sont optimales pour un petit programme, pour un gros projet on voudra choisir les meilleurs options pour son programme.

C'est marrant comment tu changes de discours quand ça t'arrange. Dans un autre topic tu soutenais qu'il était ridicule et dommageable de toucher aux options de TIGCC.

Je posterai le comparatif des vitesses ce soir.

Thibaut (./142) :
TIGCC produit un exécutable plus petit de 1,7%.

Et hop.

Par contre, la version compressée de GTC est plus petite de 12% que la version compressée de TIGCC.

Ça montre à quel point il y a de la redondance dans le code généré par GTC.

Cf le post de Vince

Thibaut (./144) :
C'est marrant comment tu changes de discours quand ça t'arrange. Dans un autre topic tu soutenais qu'il était ridicule et dommageable de toucher aux options de TIGCC.

Non, tu n'as pas compris ce que j'ai dit dans l'autre topic! Une fois de plus:

Kevin Kofler (./140) :
Je dis qu'il ne faut pas les supprimer, en revanche, il convient souvent d'en rajouter!Je dis bien les options "strict minimum" quand je poste, ça veut dire que je conseille celles-là et plus.

Ximoon (./146) :
Cf le post de Vince

Écoutez, vous faites tout pour me reprocher une incohérence, manque de chance cette incohérence n'existe pas, c'est vous qui n'avez pas compris (ou faites semblant de ne pas comprendre, au choix) ce que j'avais dit dans l'autre topic.

Le maximum que vous pouvez me reprocher est de m'être mal exprimé, mais je n'ai pas changé d'avis:
* oui, il faut toujours passer les switches par défaut (sauf cas très particuliers), mais
* non, il n'est pas toujours optimal de ne passer que les switches par défaut, ils ne sont que les switches minimum.

Je ne te reproche pas d'incohérence, juste une lourdeur extrême qui n'a pas bougé en une bonne demi douzaine d'années, c'est tout. Ça aurait beau être aussi évident que le Mont Blanc au milieu des Alpes françaises, que GTC est meilleur que TIGCC (attention, c'est théorique, je ne prends pas position), tu refuserais de l'admettre, par principe.

vince avait bien deviné comment tu essayerais de t'en sortir

Kevin Kofler (./145) :

Par contre, la version compressée de GTC est plus petite de 12% que la version compressée de TIGCC.

Ça montre à quel point il y a de la redondance dans le code généré par GTC.

Et alors ?
1- Si l'exécutable est plus rapide que TIGCC, ça compense (une des contraintes pour un compilateur, c'est de chercher un compromis entre la taille et la vitesse, tu es d'accord ?)
2- Si, en plus, ça lui permet de prendre 12% de place en moins en Flash, c'est génial !


Il semble que les performances de GTC sont équivalentes à TIGCC. Pas mal pour un petit "jouet" "obsolète"....... Sacré Kevin va.
Bon moi je file faire mes courses. Plom plom plom.