Le compilateur GTC est-il mauvais ? - Page 8

3 secondes à multiplier par le C_n^p pour les tests de combinaisons de switch, ça peut rapidement arriver à quelques heures...

Bon, ça me fait mal de devoir argumenter du même côté de Thibaut, mais puisque tu soulèves ce sujet:

Martial Demolins (./182) :
Mouarf, la place du kernel est à peine plus grosse que la taille de l'éran poussé par TIGCCLIB

* On prend cette place sur la pile, cette place ne sert pas normalement.
* On ne consomme pas de la place en RAM en permanence (même quand le programme ne tourne pas), ni sur le heap, ni sur la pile. Cette consommation de place peut être un vrai problème, par exemple Corridor 99 ne fonctionne pas si on a un kernel installé, pas assez de mémoire restante.

tes divers hacks viennent égaliser la-dite taille

Preuve?

le micro-kernel embarqué dans le code de démarrage

Arrête d'appeler notre code de démarrage un "micro-kernel"!

pour les handler f-line, détection de calcs, détection AMS et tout le reste sont répétés à chaque pauvre programme de 10 lignes

Ça prend très peu de place tout ça. Et au moins ça ne remplit pas la RAM pour les programmes qui n'utilisent pas ces fonctionnalités.

et pour finir, tu te retrouves avec 100 ko de ExtGraph (2 fois 50 ko identiques en fait) au bout de deux jeux...

* Je veux les voir, les jeux qui utilisent 50 KO de ExtGraph. Il ne resterait plus que 14 KO pour le jeu!
* Je conseille d'utiliser des routines plus optimisées en taille, par exemple celles de TIGCCLIB, ou celles de Joey Adams (versions optimisées en assembleur de celles de TIGCCLIB, avec aussi des versions clippées), actuellement en attente parce qu'il n'y a pas de documentation pour les nouvelles routines, mais Joey ou moi pouvons vous les envoyer.

Mais perso, je compte bien prouver de fait que PreOS kasdébrik par des programmes.

* Faut déjà que tu les sortes, tes programmes.
* Ils pourraient être plus efficaces sans tes abus des fonctionnalités de PreOs. Tu utilises ces fonctionnalités juste pour les utiliser, même quand ça ne sert à rien. Par exemple, ça ne sert à rien de couper un programme de 5 ou 10 KO en plusieurs morceaux, avec des exportations et importations dans tous les sens, et pour ensuite les regrouper dans un pack archive de toute façon, tu devrais plutôt linker tout ensemble avec le bon vieux ld-tigcc.

Martial Demolins (./191) :
Thibaut : si je comprends bien tu es prêt à sacrifier un max de place

Un max de place certainement pas. Déjà, ça ne sacrifie de la place que si on ne compte pas la taille du kernel, et puis "un max" est carrément exagéré.

D'ailleurs, pour le code de lancement, il pourrait être plus simple si on présuppose les conditions du kernel (au moins h220xTSR, HW[23]Patch ou équivalent), mais mon code est volontairement codé de manière à fonctionner sans tout ça.

et à compliquer la tâche au programmeur et au mainteneur

Compliquer la tâche comment? Pour le code de lancement? Je devrais rajouter quelque chose comme ça à TIGCCLIB effectivement. Mais pour le reste, TIGCC fait déjà tout pour toi.

Toi, tu t'es compliqué ta tâche toi-même quand tu as essayé le _nostub, étant donné que tu as refusé d'utiliser notre code de démarrage (alors que je t'ai expliqué exactement comment l'utiliser en assembleur) et voulu tout recoder par toi-même. Mais ce n'est pas la faute du _nostub ça. Notre code de démarrage est là pour être utilisé.

pour éviter à l'user moyen de devoir taper "preos()" une fois de temps en temps?

Pour lui éviter de devoir aller chercher la version la plus récente de PreOs (ce qui est déjà suffisant pour en confondre pas mal!), envoyer preos et stdlib et les archiver aussi.

Le manuel de la TI dit que pour lancer un programme en assembleur, il suffit de le lancer dans HOME, c'est aux programmes de correspondre à cette attente.

Et je trouve que ça débilise l'utilisateur (billou?) de ne pas vouloir lui faire comprendre un minimum comment ça marche

Moi, j'appelle ça plutôt "forcer l'utilisateur à faire du boulot supplémentaire qui ne sert strictement à rien étant donné qu'on peut très bien faire des programmes qu'il suffit de lancer pour qu'ils fonctionnent".

vince (./211) :
3 secondes à multiplier par le C_n^p pour les tests de combinaisons de switch, ça peut rapidement arriver à quelques heures...

Personne ne teste toutes les combinaisons.
Si on sait ce qu'on fait, on a déjà une idée des switches qui conviennent.

./210 : Kevin, tu fais semblant d'avoir 50 de QI ? J'ai bien compris que tu es prêt à tout, même ça, pour essayer de convaincre ton propre esprit que tous les constats faits ici sont faux... C'est dommage.

Bref, je t'explique : Ce n'est pas le temps absolu qui est important, mais le quotient. GTC donne un code proche de celui de TIGCC en 5 fois moins de temps. C'est remarquable.
Faut cependant noter que, comme l'a dit geogeo, ce sont souvent les optimisations les moins sensibles qui prennent le plus de temps.

geogeo (./209) :
Sérieux chercher à améliorer les 2 compilos au lieu de savoir quel est celui qui est le plus pourri par rapport à l'autre.

On essaie justement de montrer qu'ils sont équivalents avec leurs options par défaut.

J'allais dire...

Edit > cross

Euh un seul test de temps d'exécution ça ne te permet pas de dire grand chose hein, c'est tout à fait possible que tigcc ait juste un plus gros overhead, tu ne peux absolument pas en déduire si ça va toujours mettre 3 secondes de plus que gtc ou si ça va toujours mettre 5 fois plus longtemps, les deux sont possibles... (mais aucun n'est vraisemblable)
Dit autrement, non le quotient n'est pas spécialement plus significatif que la différence, Kevin et toit dites tous deux n'importe quoi ^^

Sally : TIGCC compile en moins d'une demi-seconde un projet de 10 lignes, donc je ne pense pas qu'il y ait d'overhead génant pour calculer un rapport de vitesses.

Martial Demolins (./218) :

Kevin Kofler (./212) :

le micro-kernel embarqué dans le code de démarrage

Arrête d'appeler notre code de démarrage un "micro-kernel"!

Un mini-kernel alors, ça te va?

Mini c'est plus gros que micro, donc je dirasi plutot nano voir pico, et pourquoi pas femta ?

Thibaut (./215) :
Ce n'est pas le temps absolu qui est important, mais le quotient.

Qui dit ça? Monsieur Barthélémy?

Je ne vois pas pourquoi on devrait se casser la tête à rendre plus efficace du code qui ne prend que 3 secondes au total, ce serait totalement peine perdue.

Maintenant ça ferait du bien à GCC d'être plus rapide parce qu'il est aussi utilisé pour de gros programmes, mais du côté de TIGCC, on s'en fiche pas mal.

ld-tigcc, lui n'est carrément pas optimisé en vitesse (mais en facilité de codage, par exemple tout est liste chaînée, nous n'avons aucune table de hachage dans ld-tigcc), ça ne servirait absolument à rien vu les tailles de programmes sur lesquels il est utilisé.

Thibaut (./215) :
On essaie justement de montrer qu'ils sont équivalents avec leurs options par défaut.

... où "on" == "Thibaut".
Moi, j'essaye de montrer que TIGCC est meilleur. Et les résultats sur TI-Chess montrent bien ça. De plus, je suis de l'avis qu'il faut comparer les meilleurs flags de GTC contre les meilleurs flags de TIGCC, pas les flags par défaut. Maintenant, GTC n'a presque pas de flags, mais ce n'est pas mon problème, ça.

Sally (./217) :
Dit autrement, non le quotient n'est pas spécialement plus significatif que la différence, Kevin et toit dites tous deux n'importe quoi ^^

Ni le quotient, ni la différence, ne sont significatives quand il s'agit de 3 secondes, on se fiche totalement du temps d'exécution exact dans cet ordre de grandeur-là!

Et tu continues à faire semblant de pas comprendre... Relis bien :

Thibaut (./215) :
Ce n'est pas le temps absolu qui est important, mais le quotient. GTC donne un code proche de celui de TIGCC en 5 fois moins de temps.

Ca y est, tu as saisi pourquoi le quotient est intéressant ?

Kevin Kofler (./222) :
Et les résultats sur TI-Chess montrent bien ça.

C'est sûr que 1,7% c'est super significatif !
Ce qui me paraît significatif, c'est les 6% de vitesse en plus qu'apporte GTC en moyenne sur la dé/compression des 3 fichiers testés.

De toute façon, que l'un ou l'autre soit tantôt meilleur tantôt moins bon, ça ne change pas le fait que les petites différences indiquent que GTC est très performant et comparable à GTC, mais tu ne l'admettras évidemment jamais, comme l'avait écrit vince

??? Vous faites tous exprès C'est une conspiration

Martial Demolins (./224) :

Et franchement Thibaut, qu'est ce qu'on en a à foutre du temps de compilation, 3 secondes, c'est vraiùent rien...

oui quand je vois qu'au boulot je me tape des 15/20min de compilation (malgres un make -j4)

Oui, 3 secondes on s'en fout. Par contre, le rapport de 5 permet de faire cette analyse :

Thibaut (./215) :
GTC donne un code proche de celui de TIGCC en 5 fois moins de temps.

sur 2 cas c'est tres loin d'eter significatif...

Je t'invite à m'aider

[sondage=15959]

(ceci dit, c'est 3s sous XP, avec win9x c'est largement plus #feed# )

Thibaut (./223) :

Thibaut (./215) :
Ce n'est pas le temps absolu qui est important, mais le quotient. GTC donne un code proche de celui de TIGCC en 5 fois moins de temps.

Ca y est, tu as saisi pourquoi le quotient est intéressant ?

Non, et ce n'est pas en répétant la même phrase encore une fois que tu vas me convaincre. Oui, GTC compile ~5 fois plus rapidement (il faudrait plus de tests pour connaître le rapport exact, mais peu importe). On s'en fout, étant donné qu'il n'est question que de 3 secondes. Je ne nie pas que GTC (version PC, hein... essaie avec la version on-calc ) compile plus rapidement, mais la réduction du temps de compilation n'est pas du tout dans les objectifs de TIGCC, ça ne sert strictement à rien. (En revanche, le projet GCC officiel fait parfois des améliorations qui réduisent le temps de compilation, donc il se peut que le temps se réduise un peu dans les versions futures de TIGCC quand je mergerai un GCC plus récent. Mais si ce n'est pas le cas, ça ne changera pas grand chose.)

Kevin Kofler (./222) :
Et les résultats sur TI-Chess montrent bien ça.

C'est sûr que 1,7% c'est super significatif !

Mais 3 secondes le sont?

Bordel. Kevin. Reprenons. C'est le rapport 3/0.5 qui importe. OK ? Et ce rapport c'est 6 (disons 5 pour être sympa). Ce qui donne 500% de rapidité en plus. Ca c'est significatif. OK ?
Et ça n'a aucune autre conclusion que cette anecdote : GTC donne du code à peu près aussi performant que TIGCC en prenant 5 fois moins de temps.

Jyaif> J'hésite entre Thibaut et Onur.

Ximoon (./231) :
(ceci dit, c'est 3s sous XP, avec win9x c'est largement plus #feed# )

Win9x/Me n'est plus du tout supporté par l'entreprise qui le développe (même pas de mises à jour de sécurité critiques), donc je n'en ai plus rien à battre, et d'ailleurs le support sera terminé complètement dès le passage à KTIGCC 2 (parce que KDE 4 ne le supporte pas).

Thibaut (./233) :
Bordel. Kevin. Reprenons. C'est le rapport 3/0.5 qui importe. OK ? Et ce rapport c'est 5. Ce qui donne 500%. Ca c'est significatif. OK ?

Non. C'est une statistique sans intérêt.

Mettons que j'aie 0 pomme. Maintenant, j'en ai 5 fois plus, j'en ai toujours 0, ce n'est pas ça qui va me faire avoir moins faim.

Maintenant, mettons que j'aie un raisin sec. Maintenant, j'en ai 5 fois plus, soit 5 raisins secs, tu penses que ça va être suffisant pour me nourrir?

5 fois presque rien, c'est toujours presque rien, donc ça ne change rien en pratique.

(PS: Pas la peine d'envoyer les paquets alimentaires, c'étaient des exemples purement hypothétiques. )

./220 > il fallait faire un sondage à choix multiples

Donc 5% de rapidité en moins pour ETP, c'est pas grave alors?

Ps: puisque je peux éventuellement etre élu comme relou, autant participer au débat.

Jyaif fait ça pour déconner je pense. S'il n'aime pas les débats, il peut arrêter de lire le topic.

Sally : Bah non, la question c'est "qui est le plus lourd ?" C'est pas "qui est lourd ?"

Kevin : mouai... Cela dit, vous vous attachez sur cette analyse qui est sans rapport avec la question du topic.

thibaut: le pbm c'est que ton temps de compilation est TROP COURT

ce n'est absolument pas significatif. Si bien il faut 2/2.5 seconde a GCC pour s'initialiser, et apres le temps est identique que pout GTC, donc pour 1H de compilation GCC prendrait 1h et 2s et GTC 1h etc...

bref ton test est absolument pas significatif...


Ensuite tu calcule comment le temps que ça prend ? je ne t'ai vu poster aucun screen aucune utilisation d'un utilitaire qui compte le temps pris etc... tu fait comment tu compte les secondes par toi meme ?

Moi! Moi!! Moii!!!! Ze veux etre Prézident!!