Le compilateur GTC est-il mauvais ? - Page 9

rha merde déjà posté de mon coté tant pis tu recevra quelque kilos de nouilles


PS: Kevin: je te prefere largement quand tu cherche a faire des blagues (droles ou non) que quand tu veux a tout pris tenter d'avoir raison...

Martial Demolins (./218) :
Surtout que dans le cas de CF, tu avais demandé à PpHd de réduire sa consommation de RAM. Pourquoi tu fais pas pareil pour C99?

Certes, Corridor 99 devrait consommer moins de RAM, mais ça ne change pas que le kernel l'empêche de fonctionner.

Un mini-kernel alors, ça te va?

Appelle-le "code de démarrage" tout simplement, parce que c'est ce que c'est.

Kevin Kofler (./212) :
* Je veux les voir, les jeux qui utilisent 50 KO de ExtGraph. Il ne resterait plus que 14 KO pour le jeu!

Sauf avec les DLLs, tu sais, celles qui sont des vrais DLLs mais ou on peut pas faire comme en vrai avec, celle qui ont été désignées avec les pieds quoi.

La bonne solution quand on dépasse les 64 KO est d'optimiser en taille.
Cela dit, on peut aller jusqu'à 128 KO de code pur (les données peuvent être externes aussi) avec le système de DLLs de TIGCCLIB, c'est largement suffisant.

Mais tu as évite le point principal de la citation:
"Je veux les voir, les jeux qui utilisent 50 KO de ExtGraph. "

Abus de fonctionnalité? J'ai le droit de faire des expériences non?

Bah, si ça t'amuse... Le problème est que tu présentes ces méthodes comme la panacée alors que tes exemples ne prouvent pas du tout qu'elles ont un intérêt, parce que ce serait plus efficace de ne pas utiliser les méthodes que tu montres.

Et je me suis surtout rendu compte que ces features offraient bien plus que des simples "libs conditionnelles", mais permettaient de gagner en place et en facilité de développement de manière impressionnate.

Dans tous les exemples que j'ai vu, tu as perdu en place et rendu le développement plus difficile.
Par exemple, le seul gain de place de ton système avec les libs conditionnelles, c'était la RAM consommée en temps d'exécution, mais tu as réduit la RAM de quelque chose comme 10 KO à quelque chose comme 5 KO, ce qui est totalement sans intérêt étant donné qu'on est loin de la taille totale de la RAM et de ce que d'autres jeux nécessitent.
De plus, il ne faut pas oublier que pour ton pack archive, il y a d'abord un twin du pack complet compressé qui est créé en RAM par AMS, PreOs va le libérer (je suppose... je n'ai plus lu le code de PreOs depuis longtemps), mais si tu crées un pack archive de 30 KO, même si ton programme ne prend que 10 KO maximum à l'exécution grâce à la segmentation en librairies (parce que c'est bien ça ton système, une segmentation comme les overlays DOS, très obsolète comme technique de codage), il faudra quand-même 30 KO de RAM pour le faire tourner parce qu'AMS crée d'abord le twin pour tout le pack archive.

TIGCC propose quoi pour l'exécution de programmes externes?

"devrais rajouter" != "propose"
Et je fournis le code que j'ai à tous ceux qui en ont besoin (même Thibaut).

On aurait à ce moment parlé carrément de kernel embarqué

Bah, vous le faites déjà. Ce n'est pas ça qui va le rendre vrai.

C'est pas de ma faute si ton code de démarrage n'est pas générique

C'est ton code qui n'est pas générique, justement.

et peut-être facilement optimisé.

Pour un cas particulier, peut-être. Mais il faut savoir ce que tu veux, du code parfaitement optimal à tout prix ou la facilité de programmation.
Nous nous sommes cassés pas mal la tête à rendre le code de démarrage aussi compact que possible.

Ceci dit, quand on propose des contributions, c'est comme si on pissait dans un bazooka

Je n'ai jamais vu une version de ton handler F-Line (pour citer un exemple) qui s'intègre correctement au code de démarrage de TIGCCLIB, satisfait les contraintes sur les registres détruits de cet endroit du code de démarrage, est aussi flexible que celui qu'on a actuellement (morceaux activables sur demande) et est compatible à 100% avec les programmes existants. (Indice: il faut une dixaine de fichiers .s, pas un seul, et il faut aussi qu'il y ait le bon contenu dedans.) Donc la "contribution", je ne vois pas où elle est.

Ce que tu as contribué et qui n'est pas encore mergé (j'ai mergé ta première optimisation de la routine de gris le 30 octobre 2006), ce sont des optimisations qui gagnent 2 octets chacune, pour un total de combien? 4? 6? 8 octets? Enfin, rien qui changera le monde.

donc on fait par soi-même. D'ailleurs, je ne sais si tu connais ce proverbe français qui dit "On n'est jamais si bien servi que par soi-même", je ne fais que l'appliquer.

Mais du coup tu es mal placé pour dire que le _nostub complique la vie, parce que c'est toi qui te la compliques en réinventant la roue.

Attends, un peu de bonne foi, en tant que linuxien tu dois bien savoir que pour arriver à faire ce qu'on veut avec sa machine, pour faire de la configuration avancée et pour exploiter les capacités a fond, on doit nécessairement mettre les mains dans le cambouis.

Justement, le but des distributions modernes est de rendre ça inutile.

Et je n'ai jamais vu de logiciel GNU/Linux qui dit qu'il faut installer un "kernel" supplémentaire parce que celui de Linux ne lui convient pas. Alors pourquoi faire ça avec AMS?

Quant à dire que je suis un monopole au même titre que chez Bilou, je ne vois vraiment pas d'où tu sors ça. Le jour où Windows sort sous GPL, on pourra en reparler.

Kevin, peux-tu aller débattre à ce sujet ailleurs ? Merci


Godzil : Justement, GCC est très rapide à s'initialiser, puisqu'il lui faut largement moins d'une demie seconde pour compiler un projet de 10 lignes. Le rapport est donc à peu près de 5 (en étant sympa, car le rapport est plutôt de 3/0.5=6).
Pour calculer le temps de compilation, j'utilise deux choses : de la concentration et un chronomètre Je fais chaque mesure 3 fois d'affilée pour être sûr.


Pour avoir une idée un peu plus précise des performances de vitesse de GTC, j'ai fait un second test de vitesse. Les résultats sont toujours au même endroit.

et comment tu lance gcc ?

gcc *.c -o fichier.exe ?

tu sais il ya une foultitude de raison qui peu faire que gcc met un poil plus de temps de gtc a s'initialiser, surtout si il y a plusieurs fichiers.

OK. Y-a-t-il un switch qui permet d'afficher une quelconque information permettant de savoir que gcc a commencé à compiler à proprement dire ?

Tes tests de vitesse, tu les fais en mode optimisation taille? Si oui, ça ne veut rien dire, quand tu dis à GCC d'optimiser en taille, il va le faire, il ne va pas faire de compromis en direction de la vitesse.

Bon, j'ai voté Thibaut au sondage de Jyaif. J'explique: Onur développe son propre compilateur et le défend. Thibaut, lui, ne développe aucun compilateur, il ne fait que de la pub pour celui de Pollux, se faisant passer pour objectif alors qu'il ne l'est clairement pas, et est tellement lourd avec sa pub qu'il rend GTC détestable, alors que Pollux lui-même est assez modeste. C'est dommage, Thibaut, si tu passais ton temps à développer plutôt qu'à faire de la pub (contreproductive) pour le boulot de quelqu'un d'autre, tu serais plus utile dans la communauté.

J'ai pas envie de me sentir utile pour les utilisateurs de TI68k tu vois. Les gens qui mettent des programmes sur leur TI68k le font pour le fun, alors ça ne changera rien à leur vie si les programmes sont mieux ou pas.
Mais toi, si tu veux être utile, tu peux arrêter de nier systématiquement l'évidence et aider Pollux dans son projet

et est tellement lourd avec sa pub qu'il rend GTC détestable

Les commentaires laissés à l'attention de Pollux dans ce topic sont plutôt positifs, au contraire ("bravo Pollux", "félicitations", "j'utilise GTC sur ma machine depuis 1 an et je trouve ça super pratique", "beau travail Pollux", "j'ai envie de faire un frontend pour GTC", etc....)

Kevin Kofler (./247) :
Tes tests de vitesse, tu les fais en mode optimisation taille? Si oui, ça ne veut rien dire, quand tu dis à GCC d'optimiser en taille, il va le faire, il ne va pas faire de compromis en direction de la vitesse.

Qui te dit que GTC ne fait pas pareil ?
Je veux bien demander à TIGCC d'optimiser en vitesse si tu veux... Mais le binaire va grossir. La taille est ton critère primordial, non ?

D'après les tests de ce topic, GTC offre un meilleur rapport vitesse/taille que TIGCC. Sur ce point, GTC est meilleur d'après les tests.
Allons Kevin ! Tu étais ouvert et objectif au début du topic, mais depuis ce matin tu trouves 1000 prétextes plus ou moins pertinents pour nier des résultats clairs dans leur contexte bien défini.

Maintenant, si on oublie ces histoires de rapports, de quotient, alors GTC et TIGCC sont en moyenne équivalents (d'après ces tests). Ce topic est là pour monter rien d'autre. C'est ma façon de me rendre utile : montrer aux gens qui ont trop lu ta propagande que GTC n'a rien d'un jouet inutilisable.

Si certains me trouvent lourd, j'espère qu'ils me laissent au moins ce mérite.

Je viens de comparer les vitesses de la routine de calcul de racines, compilée avec -O2 sur les deux outils. Ca n'a rien changé par rapport à -Os. Je vais faire de même avec Einstein et après dodo.

Voilà, les tests sont faits avec -O2. Le résultat est toujours au même endroit
GTC devance largement TIGCC : sur les 3 tests en -O2, les binaires générés par GTC sont en moyenne 8,8% plus rapides.

Qui a dit que ce compilateur est un jouet inutilisable ?

Et -O3?

Conclusions provisoires :


J'ai mis à jour les résultats pour les tailles des fichiers avec -O2. TIGCC produit des fichiers plus gros que GTC. Ils sont plus gros de 18% en moyenne.
Pour ce qui est de -Os, TIGCC produit des fichiers plus gros que GTC, de 5,7% en moyenne (détail des pourcentages dans le post ./2). Et les exécutables produits par GTC sont 8% plus rapides que ceux de TIGCC (détail des pourcentages dans le post ./69).


Assez peu de programmes (3) et de routines (4) ont été testées pour l'instant. Mais une chose est sûre : GTC se défend bien. Une autre chose est très probable : GTC a des performances comparables à TIGCC.
En tout cas, la réponse à la question du topic se précise au fur et à mesure des tests.

-O2 n'est pas le bon flag pour l'optimisation vitesse totale, c'est -O3 le bon flag pour ça! Voire -O4 (le -O3 du GCC non modifié, qui fait de l'inlining brutal).

Au fait, es-tu au courant que d'après la définition du standard C, ton bench de la racine carrée est strictement équivalent à void _main(void) {}? Mais visiblement aucun des deux compilateurs n'arrive à prouver ça. (Il faut prouver que le code termine, après on peut le supprimer parce que l'assignement n'est utilisé nulle part.) Il faut faire quelque chose avec le résultat, par exemple l'afficher, pour éviter que le compilateur triche, et garantir que le résultat est vraiment calculé. De plus, il faut que l'entrée soit une entrée en temps d'exécution (argument estack par exemple), sinon un compilateur pourrait calculer tout en temps de compilation et sortir directement la constante résultante.

Kevin Kofler (./256) :
Il faut prouver que le code termine, après on peut le supprimer parce que l'assignement n'est utilisé nulle part.)

Bah si c'etait facile a faire

Compiler pour une VM, lancer le code dans la VM avec un timeout suffisamment élevé. On ne peut pas prouver qu'un code ne termine pas avec cette méthode, mais on peut prouver qu'il termine si le timeout est suffisant. Je verrais bien un TIGCC futur faire ça. (Lancer chaque fonction à entrées constantes 3 secondes dans une VM. )

faudra refaire des benchs apres alors

Kevin Kofler (./255) :
Au fait, es-tu au courant que d'après la définition du standard C, ton bench de la racine carrée est strictement équivalent à void _main(void) {}? Mais visiblement aucun des deux compilateurs n'arrive à prouver ça. (Il faut prouver que le code termine, après on peut le supprimer parce que l'assignement n'est utilisé nulle part.) Il faut faire quelque chose avec le résultat, par exemple l'afficher, pour éviter que le compilateur triche, et garantir que le résultat est vraiment calculé. De plus, il faut que l'entrée soit une entrée en temps d'exécution (argument estack par exemple), sinon un compilateur pourrait calculer tout en temps de compilation et sortir directement la constante résultante.

C'est marrant, je suis sûr que si TIGCC avait été devant GTC, tu n'aurais pas posé autant de questions

Pour -O3, Kevin, je veux bien, mais ça va servir à quelque chose ? On va se retrouver avec des écarts de tailles encore plus importants et je doute que le gain de vitesse dépasse les 8,8% qui séparent TIGCC de GTC en -O2.

Thibaut (./261) :
Pour -O3, Kevin, je veux bien, mais ça va servir à quelque chose ?

Je pense que oui.

J'étais fatigué cette nuit J'avais oublié de diviser par 2 la somme des pourcentages d'écart des tailles en -Os. La moyenne n'est pas de 11,4% mais de 5,7%. Voilà c'est bon, doit plus y avoir d'erreurs !

Les conclusions du ./253 sont à jour.

Une tendance semble se dégager :
Plus on demande aux compilateurs d'optimiser en vitesse, plus l'écart entre GTC et TIGCC se creuse : GTC génère des programmes plus rapides et beaucoup plus petits.
GTC semble donc offrir donc un compromis taille/vitesse bien meilleur que TIGCC. Dans l'absolu, il paraît meilleur quelle que soit la directive d'optimisation.


Qu'en penses-tu Kevin ?

Tes codes sources sont 100% identiques pour les deux compilos ?

Ceci dit je vais répondre pour lui : tes benchs ne sont pas reproductibles et pas représentatifs puisqu'isolés.
Bien sûr, je salue la performance de GTC, mais arrête de partir en vrille comme ça avec tes benchs
(et tu connais KK, il n'en dira jamais de bien, cf le postavince)

Avec -Os : TIGCC produit des fichiers plus gros de 5,7% par rapport à GTC mais 8% plus lents.
Avec -O2 : TIGCC produit des fichiers plus gros de 18% par rapport à GTC mais 8,8% plus lents.
Avec -O3 : TIGCC produit des fichiers plus gros de 28% par rapport à GTC mais 10,3% plus lents.

Tu as du te gourer dans tes %-ages

plus le chiffre augmente plus c'est sensé etre rapide (a l'execution)

"10,3% plus lent avec -O3" ne signifie pas "plus lent par rapport à -O2" mais "plus lent par rapport à l'exécutable généré par GTC". J'ai réarrangé les phrases du post ./264 pour qu'elles soient moins ambiguës.

Ximoon (./265) :
Tes codes sources sont 100% identiques pour les deux compilos ?

Vi vi A part la syntaxe ASM.

Ceci dit je vais répondre pour lui : tes benchs ne sont pas reproductibles et pas représentatifs puisqu'isolés.

Il a les sources d'Einstein et de TIChess s'il veut vérifier...
Et s'il nie les résultats parcequ'ils sont faits sur 3 programmes seulement, il peut faire des benchs sur ce qui lui chante et les poster ici

Mais les tendances qui se dégagent de mes tests sont à confirmer, oui. Avec 5000 visites en 4 jours, la question du topic a l'air d'intéresser du monde. Parmi les lecteurs, ceux qui veulent m'envoyer des sources ou faire des benchs par eux-mêmes sont bienvenus

-- correction d'un oubli --

Thibaut (./267) :
Il a les sources d'Einstein et de TIChess s'il veut vérifier...

Tu m'as envoyé les sources de Einstein en un format que je ne peux pas décompresser.

Ben moi j'ai trouvé avec google au moins un décompresseur libre