Le compilateur GTC est-il mauvais ? - Page 10

Il n'y a pas de décompresseur RAR libre pour le format le plus récent. Les unrar sous GPL sont vieux et ne décompressent que les vieux RAR.
Enfin, il y a de la décompression RAR soi-disant sous GPL dans la dernière libclamav, mais 1. ce n'est pas utilisable pour décompresser l'archive correctement et 2. ils ont l'air d'avoir piqué du code du unrar non-libre.

Bon ben je t'envoie ça en Zip alors.

Pfff, KK, le gars chiant par definition.
Tu peux pas telecharger un truc non GPL et apres l'effacer?

Ça n'aurait pas l'effet voulu: le format RAR doit mourir! Pourquoi pas utiliser le format 7z qui est entièrement libre? http://www.7-zip.org (logiciel 100% sous LGPL (ou BSD pour certains morceaux), sauf justement le décompresseur RAR qui est par conséquent supprimé dans les paquetages p7zip des distributions GNU/Linux vraiment libres comme Debian et Fedora). Et ça compresse mieux que le RAR aussi. Et en plus le compresseur n'est pas shareware, mais légalement gratuit.

Je ne comprends vraiment pas pourquoi quelqu'un choisirait WinRAR plutôt que 7-Zip.

Ca compresse pas mieux que WinRAR.

Si, regarde le comparatif.

Boaf, ca a l'air de compresser mieux ouais (zarb, j'avais lu le contraire avant), mais c'est plus rapide winrar
cf. http://forum.gravure-news.com/7-zip-vs-winrar-vt18015.htm
ca serait un bon compromis

STOP ! Merci

J'ai compilé TICon45 1.41 avec GTC.
Pour l'instant je n'ai comparé que les tailles (avec -Os, -O2 et -O3) et j'ai mis à jour les pourcentages dans le paragraphe Interprétation. cf post ./2.

Les moyennes des différences de tailles (pourcentage moyen de gain de place des fichiers compressés + pourcentage moyen de gain de place des fichiers non compressés)/2 sont :

Avec -Os : TIGCC donne des fichiers plus gros que GTC de 5,4 %
Avec -O2 : TIGCC donne des fichiers plus gros que GTC de 23,2 %
Avec -O3 : TIGCC donne des fichiers plus gros que GTC de 31,7 %

On constate que les tendances se confirment avec l'introduction de ce nouveau programme dans le test de taille. Je ferai les vitesses demain.

Kevin Kofler (./274) :
Pourquoi pas utiliser le format 7z qui est entièrement libre?
[ ... ]
Je ne comprends vraiment pas pourquoi quelqu'un choisirait WinRAR plutôt que 7-Zip.

Parceque WinRAR possède un client bien plus complet et pratique à utiliser que le client pourri livré avec 7-Zip. Et que WinRAR gère le 7z, que personne n'utilise de toutes façons. Et que beaucoup de gens se foutent totalement du fait qu'il soit libre ou non

Mon topic

Plus de la moitié de ce topic dévie du sujet, et de toutes façons depuis le début c'est mauvaise foi sur mauvaise foi, je pense pas que votre petit différent ait été perturbé en 2 posts, mais bon on va continuer ailleurs quand même si besoin est

Ah tu me vexes à moitié là
J'essaie de faire des comparatifs exempts de mauvaise foi (tous les chiffres sont vérifiés, revérifiés, etc, et c'est d'ailleurs pour ça que j'édite régulièrement et que je signale quand j'ai trouvé une erreur). Après, les débats qui ont lieu autour, c'est une autre histoire...

Thibaut (./282) :
J'essaie de faire des comparatifs exempts de mauvaise foi.

"raté".

Ben explique-moi STP.

En vrac : compilation avec une version complètement périmée de TIGCC, tu n'as pas voulu laisser Kevin tester lui aussi avec les mêmes sources, choix de switches discutables, etc, je t'invite à relire ton propre topic : il me semble que tu n'es pas tout blanc non plus dans l'histoire ^^

Mais je te laisse le continuer, puisque tu sembles mettre un point d'honneur à ce que malgré tout il reste "exempt de mauvaise foi"

Ben mon cher, tu te tiens vachement au courant... Ca fait longtemps que les tests ont été refaits avec TIGCC 0.96b8, que les switchs ont été admis, et que Kevin a les sources. Les résultats des posts ./2 et ./69 ont été mis à jour plusieurs dizaines de fois depuis le début

Oui je sais, je lis le topic

Mais le fait que tu aies refait la compilation avec la bonne version (encore heureux !) n'empêche pas le fait que ton premier comparatif publié était complètement biaisé, même remarque pour les autres points.

Dis-donc, dans le genre "je cherche par tous les moyens à avoir raison", t'es assez fort toi aussi
Le principal c'est que j'aie pris les remarques en compte et que tous les tests aient été mis à jour, non ? T'aurais préféré que je reste sur mon erreur ? Pardonne-moi de vouloir répondre honnêtement à la question posée par le topic...

Ah non non je ne cherche pas à avoir raison par tous les moyens, je ne fais qu'exprimer ce que je pense du problème après avoir lu le topic (et qui plus est, sans avoir aucune préférence entre TIGCC et GTC puisque je me fiche à peu près autant de l'un comme de l'autre ^^).

Ceci dit malgré ta bonne volonté à "prendre en compte les remarques" et "mettre les tests à jour", je reste légèrement suspicieux après autant d'erreurs involontaires qui curieusement étaient en faveur du compilo que tu sembles défendre, c'est tout

En effet, parmi les erreurs, il y en a eu qui donnaient plus de faveur à GTC. Elles ont été corrigées. Encore pardon de vouloir être honnête

Je suis en train de comparer les vitesses de réflexion de l'IA2 vs l'IA3 de TICon45. TIGCC semble bien parti pour gagner, avec tous les switchs

et avec les options standards ?

Ben...c'est GTC qui gagne

C'est avec les options standard, comme on a convenu depuis 3 jours maintenant. Mauvaises langues Tout est expliqué dans les posts ./1, ./2 et ./69.

GTC met 38% de temps en plus pour réfléchir (pourcentage moyen basé sur -Os et -O3 pour le moment).
Sachant que les algorithmes alpha-bêta/mini-max utilisé dans l'IA sont massivement récursifs, j'en déduis que GTC est moins performant que TIGCC pour faire des appels de fonction. Pollux, tu penses que c'est arrangeable ?

Thibaut (./294) :
C'est avec les options standard, comme on a convenu depuis 3 jours maintenant.

Comme tu as décidé unilatéralement plutôt.

Pour moi, il faut comparer meilleurs switches contre meilleurs switches, pas switches par défaut contre switches par défaut.

C'est toi qui a dit que les autres directives pouvaient faire des programmes bugués, c'est ça ?
De toute manière tu es jamais content. Tu as voulu que je mette tous les switchs que l'IDE met par défaut. Je les ai mis. Ensuite, tu as voulu que je teste avec O2 et O3, je l'ai fait. Maintenant tu veux que je teste avec des switchs bugués ? Je te laisse le faire

Thibaut (./296) :
C'est toi qui a dit que les autres directives pouvaient faire des programmes bugués, c'est ça ?

Il faut savoir ce qu'on fait.
Et on général, si les switches ne sont pas valides, on s'en rend compte tout de suite, il y a des erreurs à la compilation.

Kevin Kofler (./297) :

Thibaut (./296) :
C'est toi qui a dit que les autres directives pouvaient faire des programmes bugués, c'est ça ?

Il faut savoir ce qu'on fait.
Et on général, si les switches ne sont pas valides, on s'en rend compte tout de suite, il y a des erreurs à la compilation.

En asm, il pouvait y avoir des bugs à l'exécution mais pas à l'assemblage

C'est en phase de linking normalement les erreurs.
Le problème dont tu parles n'existe plus depuis que nos assembleurs et notre linker gèrent les relogements non optimisables.

Thibaut (./294) :
GTC met 38% de temps en plus pour réfléchir (pourcentage moyen basé sur -Os et -O3 pour le moment).
Sachant que les algorithmes alpha-bêta/mini-max utilisé dans l'IA sont massivement récursifs, j'en déduis que GTC est moins performant que TIGCC pour faire des appels de fonction. Pollux, tu penses que c'est arrangeable ?

La différence de temps ne vient pas de la récursion ; ça vient principalement d'une petite boucle, où TIGCC à réussi à déterminer qu'une valeur était constante et a pu sortir son calcul de la boucle, alors que GTC ne l'a pas fait. Si on fait le simple patch suivant dans la fonction update_score() :

    for (i=0; i<win_places; i++) {
        if (map[x][y][i]) {

=>

    Boolean *mapxy = map[x][y];
    for (i=0; i<win_places; i++) {
        if (mapxy[i]) {

alors GTC devient à peu près aussi rapide que TIGCC. Bref, comme je l'avais expliqué dans un post précédent, les bench de vitesse, c'est très très aléatoire, et ça dépend vraiment du style de l'auteur. Et puis bon, un auteur qui cherche à optimiser son programme en vitesse aura tendance à faire du profiling, et fera naturellement des petites optimisations du style de celle que j'ai données ; ça paraît donc logique que le compilateur que l'auteur a utilisé pour écrire son programme soit un peu plus efficace parce que les petites optimisations qu'il aura intégrées au programme sont adaptées au compilateur D'ailleurs dans cette même fonction update_score() il y avait déjà une de ces petites optimisations :
short **current_score_array = current_state->score_array; pour indiquer au compilateur que current_state->score_array est constant et que son calcul doit être sorti de la boucle.

Accessoirement c'est illusoire de croire qu'on peut compter sur le compilateur pour faire ce genre d'optimisation à la place du programmeur : s'il y avait eu la moindre modification de pointeur en mémoire, ou le moindre appel de fonction à l'intérieur du bloc if, la transformation n'aurait pas été faite et la petite optimisation manuelle que j'ai donnée aurait été obligatoire pour pouvoir gagner de l'ordre de 30-40% en vitesse ^^

(cela dit, je reconnais que TIGCC est pas mauvais du tout pour ce genre d'optimisations )