Le compilateur GTC est-il mauvais ? - Page 6

Thibaut (./150) :
1- Si l'exécutable est plus rapide que TIGCC

Ah bah ça, ça reste à prouver. Tu n'as fait aucun test de vitesse avec la 0.96 Beta 8, et le test que tu as fait ne portait pas sur l'IA de TI-Chess.

Ximoon (./149) :
Ça aurait beau être aussi évident que le Mont Blanc au milieu des Alpes françaises

ptdr ce troll

Kevin Kofler (./143) :

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.

Et bien sûr, à chaque nouvelle compilation, il faut essayer toutes les combinaisons de switchs, y compris celles qui peuvent faire bugger le programme

faut arrêter de fumer et considérer les cas pratiques... combien de projets ont des options autres que celles par défaut ?

Une très grande partie des projets TIGCC. Ceux qui ne le font pas, ils se font conseiller (ou flamer, selon notre humeur ) par Lionel ou par moi si on le voit et la prochaine version a des switches plus efficaces.

Non mais Kevin, frotte toi un peu au monde du travail et à ses réalités, hein. Et tu comprendras que, si même dans le milieu professionnel on ne fait pas des tonnes de tests pour changer des switches d'exécution, de configuration ou de compilation, alors tu imagines bien que dans le milieu amateur, ça ne va pas non plus être le cas.
Bien sûr, il y a quelques nerds/geeks qui vont toujours chercher à faire mieux. Mais c'est quantité négligeable (en dehors de certains domaines où l'optimisation est cruciale). Aujourd'hui, on se focalise généralement sur de RAD et la portabilité. Le reste, c'est "si on a le temps" (soit, dans environ 90% des cas, jamais).
Je ne dis pas que taille et vitesse sont secondaire, bien sûr que non, mais qu'il y a des ordres de grandeur qui font qu'on n'en a rien à faire de gratter quelques ko ou quelques millisecondes. Après, que ça soit un défi, un point critique du développement ou un vrai problème de concurrence, ok, pas de problème. Mais il faut voir la réalité en face. Mais là, il n'est même pas question de concurrence : ce sont deux produits différents (d'autant que l'un est en version bêta depuis des années, l'autre est distribué à un entourage très réduit), sans aucun enjeux derrière autre que le plaisir.
Va me dire où est le plaisir dans ta détestable attitude ? (Je n'ai pas dit que Thibaut était blanc comme neige, il est un peu provocateur parfois, mais c'est à 1000 lieux de tes réactions).

./154 > Super user-friendly tout ça

Et une fonction qui compilerait avec toutes les combinaisons successives de switchs possibles et ne garderait que le meilleur résultat ?

C'est vrai que c'est terriblement galère de trouver les switchs qui vont bien, surtout vu le temps que met TIGCC pour compiler...

D'ailleurs TIGCC est-il capable de lancer la compilation de plusieurs sources en parallèle pour rentabiliser les processeurs modernes ?

Nil (./155) :
Non mais Kevin, frotte toi un peu au monde du travail et à ses réalités, hein. Et tu comprendras que, si même dans le milieu professionnel on ne fait pas des tonnes de tests pour changer des switches d'exécution, de configuration ou de compilation, alors tu imagines bien que dans le milieu amateur, ça ne va pas non plus être le cas.
Bien sûr, il y a quelques nerds/geeks qui vont toujours chercher à faire mieux. Mais c'est quantité négligeable (en dehors de certains domaines où l'optimisation est cruciale). Aujourd'hui, on se focalise généralement sur de RAD et la portabilité. Le reste, c'est "si on a le temps" (soit, dans environ 90% des cas, jamais).
Je ne dis pas que taille et vitesse sont secondaire, bien sûr que non, mais qu'il y a des ordres de grandeur qui font qu'on n'en a rien à faire de gratter quelques ko ou quelques millisecondes. Après, que ça soit un défi, un point critique du développement ou un vrai problème de concurrence, ok, pas de problème. Mais il faut voir la réalité en face. Mais là, il n'est même pas question de concurrence : ce sont deux produits différents (d'autant que l'un est en version bêta depuis des années, l'autre est distribué à un entourage très réduit), sans aucun enjeux derrière autre que le plaisir.
Va me dire où est le plaisir dans ta détestable attitude ? (Je n'ai pas dit que Thibaut était blanc comme neige, il est un peu provocateur parfois, mais c'est à 1000 lieux de tes réactions).

full , comme souvent...

Ximoon (./156) :
D'ailleurs TIGCC est-il capable de lancer la compilation de plusieurs sources en parallèle pour rentabiliser les processeurs modernes ?

Non. Tu peux faire ça si tu utilises un makefile et le switch -j + nombre de jobs parallèles, mais TIGCC lui-même ne gère pas ça. Personnellement, je trouve que ça a peu d'intérêt, surtout pour un programme TI où la compilation est très rapide. (As-tu essayé de compiler kdelibs, par exemple?)

Donc encore une feature request ignorée à coup de "JE trouve" ? (je ne dis pas que tes arguments ne sont pas justifiés)

Et oui bien sûr je passe mes journées à compiler kdelibs (par contre compiler 778350_1.S3, oui ça prend du temps).

Ceci dit, quand on développe, plus ça va vite, mieux c'est, et tu ne peux rien dire contre ça. Il paraît d'ailleurs que GTC est très rapide, c'est pour ça que je parlais de vitesse de compilation. Tu sais que je me suis déjà plaint de nombreuses fois de l'absence de possibilité d'avoir un makefile intelligent, disons que c'est dans la même veine

Bah, je rajouterai peut-être la compilation parallèle dans KTIGCC 2 ou 3, mais je ne promets rien, il y a des TODOs plus importants (supprimer les *nix-ismes pour que la version Win32 fonctionne correctement, par exemple ).

Ximoon (./159) :
...Il paraît d'ailleurs que GTC est très rapide, c'est pour ça que je parlais de vitesse de compilation...

D'ailleurs Pollux, dans un de tes posts precedents, tu disais que la version oncalc et la version PC avaient des differences au niveau des optimisations (sur l'oncalc il y en a de désactivées).
Si c'est une question de hardware limitant je comprend, mais si c'est juste pour gagner en rapidité de compilation il serait peut-etre interressant d'avoir un pragma (comme opt(speed)) qui réactive ces optimisations non ?
Parce que quitte a perdre quelques secondes (voire plus si le projet est gros) a la compilation je prefererais disposer ds memes optimisations que son homologue PC
Enfin, c'est mon avis, libre a toi de voir si ca vaut vraiment le coup ou pas

Edit> Bon vala j'espere que c'est plus clair ^^

(ximoon n'est pas l'auteur de GTC )

(Mais il n'a jamais dit que Ximoon était l'auteur de GTX )

(Oui pardon j'ai un peu sauté du coq a l'ane lol)

(il cite Xi)

hummm GTX ça sonne sympa comme nom de projet

reste plus qu'à trouver son utilité, mais c'est un détail

Raaaah pourquoi on a fait des claviers avec des touches si proches x_x
(sinon, le X de GTX peut vouloir dire Ximoon )

Ximoon
: Ceci dit, quand on développe, plus ça va vite, mieux c'est, et tu ne peux rien dire contre ça. Il paraît d'ailleurs que GTC est très rapide

C'est même fulgurant.

TIGCC compile TI Chess 4.0 en 3 secondes (environ) sur mon Athlon 64 3500+.
GTC compile le même code en 1/2 seconde.

On a donc un compilateur qui donne des exécutables aux caractéristiques comparables à ceux générés par un compilateur qui compile 5 fois plus lentement. Chapeau Pollux

Personnellement, j'ai GCC sur ma calto depuis près d'un an et je n'ai plus TIGCC sur mon pc depuis 2 ans.

Je trouve que GCC est formidable :
1) faire du C sur sa calculatrice, le rêve qui devient réalité!!!
même si il y avait déjà CC et AS, mais c'était assez incomplet lol
2) un éditeur de source très sympatique et bien pensé étant donné la taille d'affichage relativement limitée
3) un compilateur plutot efficace
4) beaucoup de fonctions disponibles sachant que c'est une version calto, c'est assez incroyable!

Donc ceux qui disent que c'est un joujou, ben essayez d'atteindre le niveau de pollux!

je crois qu'il y a confusion entre GTC et GCC, d'ailleurs c'est même un contresens pour le coup ^^

(TIGCC utilise, comme son nom l'indique, GCC)

On est d'accord. J'ai dit la même chose ici : topics/103139-le-compilateur-gtc-est-il-mauvais/3#86
C'est pas parceque je dis "chapeau Pollux" que je relègue GCC au rang de merde. C'est vrai que des fois je provoque un peu en le laissant penser : c'est simplement pour que Kevin comprenne ce qui est inadmissible dans ses propres paroles.

T'as pas l'air de devoir trop te forcer non plus

C'est sûr que ça fait du bien de chatouiller quelqu'un qui te fait chier depuis 6 ans

Tu m'inclues dans la communauté nostubienne ? Méchant !

Au niveau des trolls, je n'ai pas l'impression d'être ici très actif. Je fais des tests et je commente.

Thibaut (./150) :

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 !

Pollux a déjà dit, si je ne me trompe pas, qu'il préfère toujours utiliser des opcodes identiques à perf équivalentes, parce qu'il pense à la compression : c'est peut être grâce à ça

Il a peut-être aussi mis à sa sauce la routine de compression ? (en changeant des paramètres (du genre : taille du dictionnaire, je sais pas j'y connais rien) ou en divisant l'exécutable en plusieurs flux (op codes, paramètres des opcodes, données, etc))