GTC : un TIGCC sur votre calculatrice ? - Page 9

Je n'ai utilisé que:

- -Os, parce que c'est toi qui as commencé à l'utiliser pour ton benchmark et parce que:

Pollux
a écrit : GTC n'a pas encore de mode optimisation vitesse ou mémoire en switch, mais la version que j'avais compilé était en mode plutôt optimisation mémoire...

- -fomit-frame-pointer, parce qu'il me semble bien que GTC fait ça par défaut. Et s'il ne sait pas faire (ce n'est certainement pas une option parce que Pollux dit qu'il n'y a pas de switches d'optimisation), c'est un défaut de GTC, donc on ne va pas limiter GCC pour avoir les mêmes défauts, juste parce que tu n'as pas lu la documentation (où toutes les options sont expliquées).

Les améliorations seraient-elles dues à GCC 3.3 ?

Oui.

> on ne va pas limiter GCC pour avoir les mêmes défauts
N'importe quoi Il faut comparer 2 générations de code réalisées dans les mêmes conditions !
Souviens-toi de l'histoire du vélo et du camion soulevé par uin ballon d'hélium

Là, je suis un peu d'accord avec Thibaut. On fait un bench avec les options plutôt taille, un bench avec les options plutôt vitesse (il ne semble pas y avoir vraiment de distinction dans GTC, d'après ce que tu dis), et pour finir on fait un bench avec les optimisations "wild", tout activé.
Il faut faire le bench avec plusieurs programmes différents, bien entendu. tthdex pourrait être utilisé en tant que programme de la classe des 13 KO, mais il utilise un certain nombre de trucs non (non encore ?) supportés par GTC...

C'est idiot ça!
On fait un bench avec les meilleures options proposées! Ce que Thibaut propose revient à dire: "On va faire une course entre un vélo et un camion. Mais comme le vélo en question ne peut pas dépasser 40 km/h, le camion n'aura pas le droit d'aller plus vite lui non plus. Et hop, le vélo a gagné, donc le vélo est plus rapide que le camion. " Ne viens pas me dire que ça peut vraiment être le cas pour certains camions: si ça te gène vraiment, remplace "camion" par "voiture de Formule 1", ça ne change rien à mon argument.

Et puis, Thibaut, je te signale que je n'ai mis aucune option autre que -Os -fomit-frame-pointer. En particulier, je n'ai pas mis d'options pour supprimer du "startup code" (parce que GTC le permet aussi, que tu ne l'as pas fait, et que d'un certain point de vue, les #defines font partie de la source, pas des options). Le code compilé par les 2 compilateurs est exactement le même.

Et je te signale aussi que même Pollux n'a pas critiqué l'utilisation de -fomit-frame-pointer pour les comparaisons. J'ai l'impression que tu cherches tout simplement une excuse pour nier l'évidence (que GCC 3.3 optimise mieux que GTC).

Bien sûr qu'il optimise mieux en vitesse ! Pour la taille, je ne sais pas.

> On va faire une course entre un vélo et un camion. Mais comme le vélo en question ne peut pas dépasser 40 km/h, le camion n'aura pas le droit d'aller plus vite lui non plus.

N'importe quoi ! Tu limites le camion en vitesse, mais pas le vélo :
- tu lances le camion avec l'option --bloquer_moteur_à_40km/h
- tu lances le vélo sans option
Les vitesses ne peuvent pas être comparées puisque les options sont différentes !
Ca revient à dire :
- on pèse le camion en limitant son poids par un ballon
- on pèse le vélo sans limiter sont poids

Moi je te demande de ne mettre aucune option :
- on pèse le camion sans ballons
- on pèse le vélo sans ballons

Et là, le meilleur gagne

Ce que tu n'as pas compris, c'est que les règlages standard de GCC ne sont pas les règlages qui donnent la meilleure optimisation, et que l'équipe de GCC conseille de ne jamais lancer GCC sans options. (Tu as mis -Os au moins dans tes tests (heureusement, parce que le standard est -O0), mais tu devrais aussi mettre au moins -fomit-frame-pointer.) Alors que GTC, lui, met les règlages qui donnent la meilleure optimisation dès le départ. Ton problème, c'est que tu ne connais pas le fonctionnement de la ligne de commande de GCC.

Au fait: comme je ne m'appelle pas Pollux, j'ai mis une bêta publique de GCC 3.3 pour TIGCC sur http://tigcc.ticalc.org/gcc33/ (c'est une redirection vers l'endroit de mon site où il se trouve réellement).

> Ton problème, c'est que tu ne connais pas le fonctionnement de la ligne de commande de GCC
Ha bon ? Possible, mais je me demande ce qui te fait dire ça

-Os correspond aux optimisations faites par GTC. Voilà pourquoi je n'ai rien mis d'autre pour lancer GCC.
Si GTC emploie aussi fomit-frame-pointer, alors OK : ma comparaison est fausse

Il faudra que Pollux réponde à ces 2 questions-là:
- GTC permet-il de compiler sans "frame pointer"?
- Si oui, est-ce activé dès le départ?

Si la réponse aux 2 questions est "oui", on est d'accord. Si la réponse aux 2 questions est "non", alors GTC a un défaut qu'il ne faut pas essayer de cacher en désactivant l'option correspondante de TIGCC.

Alors pour ta remarque I DISAGREE !!!! Espèce de tricheur
On va comparer le gouvernement Autrichien au gouvernement Français en demandant aux politiques d'extrême-droite Autrichiens de partir avant...
Non, désolé, je trouve vraiment qu'on ne doit rien enlever à TIGCC pour comparer !

Arrête avec ces comparaisons stupides qui ne font que détourner du sujet d'origine: si GTC était (je mets la phrase au conditionnel en attendant la réponse de Pollux) trop con pour supprimer le frame pointer, ça serait un défaut de son optimiseur, et ça voudrait dire qu'il optimise moins bien.

N'insulte pas GTC !!! Tu es incapable de faire ce qu'a fait Pollux. GTC va être utile à beaucoup de monde.
Ca ne mérite pas des insultes.

Moi j'ai insulté une fois TIGCC, mais c'est parceque je suis un con. Toi, ne fais pas pareil

>> On fait un bench avec les options plutôt taille, un bench avec les options plutôt vitesse (il ne semble pas y avoir vraiment de distinction dans GTC, d'après ce que tu dis), et pour finir on fait un bench avec les optimisations "wild", tout activé.
> C'est idiot ça!
Peut-être que c'est idiot... Cependant, ça me paraît être la meilleure façon de faire des tests clairs et pas biaisés...
On manque vraiment d'infos sur GTC pour pouvoir continuer plus loin... Espérons que Pollux éclaircira cela assez rapidement...

> On va comparer le gouvernement Autrichien au gouvernement Français en demandant aux politiques d'extrême-droite Autrichiens de partir avant...
Ca, c'est off-topic, ça n'apporte rien et ça détourne le débat...

Pour une fois que c'est moi qui détourne

Donne-moi une source sans ASM avec paramètres, et je la compile avec les deux versions de GTC : la "normale" et celle qui optimise un peu en vitesse.

Ne fais pas exprès de me donner un truc bourré d'extensions que personne n'utilise en temps normal

Comme je l'ai déjà dit, tthdex serait très bien, mais il utilise les ASM inline avec et sans opérandes C, et des fonctions "static inline"...

Pour les sources sans ASM avec paramètres, c'est pas compliqué: il y a bien un certain nombre de programmes de TICT (TICT fait du open-source...) qui est dans ce cas-là... Ca n'est pas le cas de TI-Chess 4.00, mais c'est sûrement le cas de TI-TimeWaste, TI-TiltMaze, TI-LIDS et plusieurs autresd'autres programmes... Va faire un tour sur tict.ticalc.org et télécharge les dernières versions des softs.
Les bêtas internes seraient peut-être mieux, notamment un header qui unifie certains trucs, mais l'utilisation n'en est pas possible car rien n'est fini...

Ce sont des sources "multifichiers" je crois. Théoriquement, il suffit que je fasse un header incluant tous les fichiers et que je compile ce header ?

Non. En principe, tous les projets de TICT sont fournis avec un makefile, un .bat. Edite-le simplement pour changer les options de compilation...
Il doit y avoir TI-Miner, aussi...

Il faudrait faire un bench avec TIGCC 0.94 Final, et un bench avec TIGCC 0.94 Final + la prerelease de GCC 3.3... GCC 3.3 semble optimiser mieux (au moins en taille, TRgenius a descendu très légèrement la taille de son programme avec une recompilation sous GCC 3.3).

Ouai bon c'est pas joyeux, j'ai tenté de compiler tiltmaze, mais GTC est trop bogué, j'en ai marre de modifier la source pour contourner les bugs. A chaque fois des nouveaux arrivent
Je rappelle que c'est une BETA que j'ai. Je vais envoyer un rapport à Pollux.

Bon déjà je vais essayer de répondre aux 'vieux' posts (d'il y a 3 jours...)

C'est quoi qui est mieux? La possibilité de programmer on-calc? Je veux voir comment tu veux faire rentrer un programme réel (pas de "Hello, World!") on-calc. Quelques exemples de programmes réels:
- Backgammon: fichier .c de 87494 octets, trop grand pour la calculatrice
- TI-Chess 4.00: 21 fichiers .c et 14 fichiers .h pour un total de 472 KO. Le plus grand fichier .c est engine.c qui fait 105760 octets, ce qui est trop grand pour la calculatrice. ...

Primo : les sources que tu as citées sont dans de gros fichiers, on peut très bien les couper en plusieurs.
Secondo : les sprites transformés en 0b**/0x** prennent bcp trop de place, et GTC supporte parfaitement le incbin et possède un format de ressource qui permet une gestion transparente des sprites.

Ceci dit, je suis d'accord que TI-Chess ne pourra pas être compilé en entier on-calc (sauf sur V200 ), mais rien n'interdit de compiler sur PC les grosses parties une fois qu'elles sont terminées (par exemple, l'interface si on veut améliorer le moteur, ou le moteur si on veut améliorer l'interface), ce qui permet de diviser la taille par 2 ou 3...
Le code source contient pas mal de commentaires et les tabulations sont tous les 4 caractères et elles sont converties en espaces : tout ça peut être compressé de manière transparente par GTC... (le fichier engine.c passe de 103 à 67 ko après la compression ultra-rapide de GT-Dev, soit un gain de plus de 35% )
D'ailleurs je viens de regarder : si on ne garde que l'anglais et qu'on convertit les graphiques en binaires, on gagne 100 ko...

Donc on peut raisonnablement penser qu'on peut faire passer la taille à 200 ko, ce qui est acceptable pourvu qu'on ait un peu de place sur sa calc : même le plus gros projet sur TI pourrait être compilé avec GTC

Si j'avais le temps, je ferais bien la même chose avec Backgammon, mais je n'ai pas que ça à faire...

Un compilateur on-calc est quelque chose de bien, mais il ne pourra jamais remplacer TIGCC. Quant à la version PC de GTC, je ne vois pas pourquoi on utiliserait un compilateur avec des extensions en moins et presque rien en plus. (Je peux rajouter le __attribute__((regparm(3,2))) (donc à 2 paramètres) à GCC pour TIGCC 0.95. Et il paraît que c'est la seule chose qu'il y a en plus.)

'presque rien en plus'... Je ne crois pas que tu diras ça quand tu verras à quoi ressemble GTC

Un exemple: TI-Chess 4.00 est compilé en entier en 118 secondes, alors qu'il y a 8 versions compilées (version TI-89 en 4 langues et version TI-92+ en 4 langues). Ça ne fait même pas 15 secondes par version. Franchement, ce n'est pas beaucoup. Et la raison pour laquelle GCC est moins rapide que GTC est le nombre d'optimisations apportées à la source compilée.

D'accord, mais un temps de compilation 3x plus élevé pour un gain en vitesse de 10%, je trouve ça un peu inutile pendant le développement (après, pour les releases, rien n'interdit d'utiliser TI-GCC)

Squale92:
je suis assez d'accord.
du moins, pr les gros projets
(ou, en fait, pr n'importe quel projet une fois qu'on a un certain niveau de prog)

qd on débutte, c bien pratique, surtout vu qu'on écrit que de petits progs (là, je parle pr l'ASM... mais ça doit être pareil pr le C)

Déjà, pour les très gros projets comme TI-Chess ou GTC, cf ma réponse à Kevin.
Ensuite, pour 99% des projets, je crois que tu as franchement tort... C'est vrai qu'avec AS92 (ou encore avec CC ou les premières versions de GTC), c'était absolument inviable de gérer un projet dont le programme faisait plus de 5 ko (c'est d'ailleurs ce qui m'a amené à créer GT-Dev). Mais ça n'est plus du tout le cas avec GT-Dev; il y a tout un paquet d'outils (entre autres navigation dans le projet type Visual Studio, création de libs et bientôt compilation séparée) qui permettent de gérer des projets d'à peu près n'importe quelle taille : je ne sais pas si tu connais un certain jeu sur PC répondant au doux nom de StarCraft... Ce n'est certainement pas un 'petit projet' (et je ne crois pas non plus que je débute en programmation ), et pourtant j'ai commencé à le programmer avec GTC (le code source dépasse les 30 ko, et j'écris de manière très compacte, sans commentaire et sans retour à la ligne inutile).
En fait, avec l'IDE de GTC, c'est même presque plus rapide qu'avec l'IDE de TI-GCC.

Tu sous-entends là que TIGCC n'acceptera pas le code accepté par GTC. Ça ne devrait pas être le cas normalement.

Si, cf plus haut : GTC aura pas mal d'extensions (d'où l'utilité d'un compilateur sur PC, même s'il n'a pas forcément vocation à concurrencer TI-GCC).

--- Ici, il y avait un bug-report ---

Pollux, cf ta signature: on est aux vacances de Noël, peux-tu préciser la date de sortie?

> J'ai déjà fait mon choix. Je n'attend que l'IDE on-PC
Il n'y aura pas d'IDE on-PC (mais si quelqu'un veut en faire une, je ne lui interdis pas et je lui souhaite pas mal de courage si il veut refaire l'IDE on-calc )

> D'ailleurs, Pollux, si tu veux que j'adapte l'IDE de TIGCC en attendant, pas d'p, je connais pas mal Delphi.
A mon avis l'IDE de TI-GCC est pas trop mal pour une IDE basique (même si elle n'a rien à voir avec l'IDE on-calc)...



> La vitesse sur un PC moderne (même un P-133), n'est pas un argument. 30 secondes reste parfaitement acceptable pour compiler un projet ! Tant pis pour ceux qui sont impatients...
Je ne sais pas si tu programmes bcp, mais même moi sur une calc qui n'a pourtant qu'un 68000 à 10 MHz je trouve ça ennuyeux de devoir attendre 5-10 secondes à chaque compilation (pdt la phase de développement, pas pour le release bien entendu)

Je n'ai utilisé que:

-Os, parce que c'est toi qui as commencé à l'utiliser pour ton benchmark et parce que:

Pollux a écrit : GTC n'a pas encore de mode optimisation vitesse ou mémoire en switch, mais la version que j'avais compilé était en mode plutôt optimisation mémoire...

Oui, mais l'allocation de registres se fait en optimisation vitesse Il faut que je rajoute le switch optimisation mémoire totale...

-fomit-frame-pointer, parce qu'il me semble bien que GTC fait ça par défaut. Et s'il ne sait pas faire (ce n'est certainement pas une option parce que Pollux dit qu'il n'y a pas de switches d'optimisation), c'est un défaut de GTC, donc on ne va pas limiter GCC pour avoir les mêmes défauts, juste parce que tu n'as pas lu la documentation (où toutes les options sont expliquées).

Oui, GTC fait ça par défaut.

C'est idiot ça! On fait un bench avec les meilleures options proposées! Ce que Thibaut propose revient à dire: "On va faire une course entre un vélo et un camion. Mais comme le vélo en question ne peut pas dépasser 40 km/h, le camion n'aura pas le droit d'aller plus vite lui non plus. Et hop, le vélo a gagné, donc le vélo est plus rapide que le camion. " Ne viens pas me dire que ça peut vraiment être le cas pour certains camions: si ça te gène vraiment, remplace "camion" par "voiture de Formule 1", ça ne change rien à mon argument.

Je suis d'accord avec Kevin sur ce point, sauf si la qualité s'en trouve sévèrement affectée (exemple : F-Line...)

Ce qui fait que GTC est peut-être un peu moins bon ou un peu meilleur que TI-GCC, mais peu importe : le temps de développement d'un prog avec GT-Dev est bien inférieur au temps de dév avec TI-GCC... (ne me demandez pas de preuve pour l'instant, vous verrez bien quand il sortira )

Théoriquement, il suffit que je fasse un header incluant tous les fichiers et que je compile ce header ?

Oui.


> Ouai bon c'est pas joyeux, j'ai tenté de compiler tiltmaze, mais GTC est trop bogué, j'en ai marre de modifier la source pour contourner les bugs. A chaque fois des nouveaux arrivent
Ca c'est la joie du beta-test

En tout cas merci, je vais essayer de corriger ça


stpatrick> environ dans une semaine, mais des problèmes inattendus peuvent toujours arriver

Est-ce qu'on pourra linker ensemble des sources asm et C ? Ou au moins est-ce qu'on pourra taper dans un asm (" "); du code qui ressemble à de l'asm (sans 0x, % et \n partout) ?

Le bug est corrigé... Ca venait de la ligne :
char* s2 = "http://tict/ticalc.org";
GTC croyait que le // était le début d'un commentaire


ExtendeD>
la syntaxe est bien mieux que celle de TI-GCC :

asm {
myfunc:
 pea "Hello world!"(pc)
 move.l 0xC8,a0
 move.l ST_showHelp*4(a0),a0
 jsr (a0)
 addq.l #4,a7
 rts
}

(ce sera même possible de faire :

asm {
myfunc:
 pea "Hello world!"(pc)
 move.l 0xC8,a0
 ST_showHelp(a0)
 addq.l #4,a7
 rts
}

)

Pour les 0x, ils seront obligatoires (car 1) ça complique pas vraiment le code 2) rien n'interdit à une variable de s'appeler $200...)

Pour les \n, j'ai oublié de mentionner la syntaxe #macro/#endm qui permet d'éviter les \ (et qui permettra quelques autres fonctions plutôt puissantes, mais je vous laisse la surprise )