Discussion :

[screetch]

GCC est peut-être gratuit, mais côté vitesse de compilation, la copie est très nettement à revoir je trouve par rapport à VS.

je peux etre d'accord avec le reste mais ca ca tient surtout du mythe. La rapidité de visual studio vient surtout du fait que le compilateur est lancé une fois pour tous les fichiers a compiler, tandis que les (cons de) makefiles relancent un nouveau processus a chaque fois que l'on souhaite compiler un fichier.
De plus, la vitesse de compilation peut etre améliorée en utilisant des Precompiled Headers, option assez simple a mettre en place dans un IDE mais que l'on rechigne a utiliser en ligne de commande.
J'ai eu l'occasion de faire des essais sur ma machine avec un build "neutre" (ni l'IDE visual studio, ni un makefile)
c'est GCC le plus rapide, et meme sans precompiled headers il tient la route en vitesse.

[Mac LAK]

je peux etre d'accord avec le reste mais ca ca tient surtout du mythe.

Mêmes fichiers, même nombre de processus concurrents sur les deux cibles (identique au nombre de coeurs), GCC configuré pour utiliser les pipes, VS en réglage "normal", aucun PCH ni sur l'un, ni sur l'autre.

Bilan : VS deux fois plus rapide que GCC (20 minutes contre 40 minutes sur mon projet)... Et ceci de façon constante.

[screetch]

ce n'est pas le meme systeme de build, tu ne compares pas la vitesse du compilateur la

[Mac LAK]

Je compare la vitesse de création / compilation de mon projet pour chaque chaîne de génération, ni plus, ni moins. Et GCC est très nettement plus lent même en étant lancé en parallèle et sans fichiers temporaires... Je me fiche de savoir si c'est le linker, le makefile ou le trucmuche qui est plus lent, je constate le résultat.

Après, si t'as une solution miracle pour lancer GCC sans makefiles, je suis preneur, mais le résultat est le même en lançant la compilation VS en ligne de commande via MSBuild...

[screetch]

tu te fiches du resultat mais blame le compilateur, c'est con. si tu passais moins de temps a critiquer et plus a optimiser ca serait pit etre pas le meme ratio...

mais plus facile de critiquer que de faire un effort effectivement

[Mac LAK]

tu te fiches du resultat mais blame le compilateur, c'est con. si tu passais moins de temps a critiquer et plus a optimiser ca serait pit etre pas le meme ratio...

Bien, donc on va reprendre : entêtes précompilés impossibles à utiliser pour cause de code conditionnel, nombreux templates et pas de point central rendant intéressant cette option (pas même sous VS, d'ailleurs). Makefiles impératifs avec GCC, il n'y a rien d'autre disponible. Optimisations de compilation standard effectuées (pipes notamment, gros gain de temps). Et VS n'est pas "mieux réglé", les deux compilos utilisent en gros les mêmes options.

mais plus facile de critiquer que de faire un effort effectivement

Compiler plus de 10.000 fichiers sources répartis sur une cinquantaine d'unités (librairies et exécutables) sur trois cibles différentes, quoi qu'il arrive, ça ne se fait pas en cinq secondes et ça se fait encore moins à la main...

Mais ça, c'est quelque chose que l'on n'apprends pas à l'école, et qu'il est assez difficile de simuler à la maison en benchant un fichier ou deux !

[screetch]

tu pretends que ton benchmark est pas foireux ?
vous avez fait vous meme le makefile ?

d'ailleurs il y a moyen d'optimiser la compilation, sans utiliser les PCH. ca ne marche pas directement (quelque fois ca declenche des petits problemes) mais ca permet en general de gagner 25% du temps de compilation.

apres, que ca ne vous derange pas de compiler pendant des heures, ca n'est pas mon probleme. Je trouve ca juste dommage qu'un informaticien vienne poster ici par méconnaissance (et feignantise) une information incorrecte.

[Mac LAK]

tu pretends que ton benchmark est pas foireux ?
vous avez fait vous meme le makefile ?

Vous avez fait le même IDE que VS pour GCC ?

LeS makefileS sont basés sur une base commune nécessaire (cohérence des options de compilation oblige) : utiliser quelque chose comme automake produisait un résultat bien trop long (et donc coûteux) en temps de génération.
Ils sont tout aussi "manuels" que les projets VS, eux-mêmes basés sur des propriétés communes héritées par tous les projets.

[screetch]

mais meme sans parler de cela, je dis que les Makefile par défaut compilent un fichier a la fois, tandis que l'IDE visual studio compile tous les fichiers d'un coup.
Il existe d'autres systemes de build, plus récents, qui compilent plus vite car sont capables de rassembler plusieurs fichiers sur une ligne de commande. Et meme si vous ne souhaitez pas utiliser ce genre de trucs, ce qui me chiffonne c'est que tu dis que GCC est plus lent alors qu'en fait c'est make qui est lent (et un peu passé de date, quand meme...)

[Mac LAK]

mais meme sans parler de cela, je dis que les Makefile par défaut compilent un fichier a la fois, tandis que l'IDE visual studio compile tous les fichiers d'un coup.

Non : tu parlais d'optimisation, je t'encourage à regarder l'option "-j" de make... Je lance autant de compilations simultanées avec GCC qu'avec VS, c'est à dire une par cœur de processeur, et le cache disque est activé bien entendu. VS compile de toutes façons les fichiers séquentiellement quoi qu'il arrive, il faut lancer plusieurs fois le compilateur pour profiter des cœurs.

Ensuite, pour ma part, GCC m'envoie sur les roses quand je veux spécifier une destination (-o) avec une compilation multiple (-c + plein de fichiers), contrairement à VS (option "/Fo")... Obtenir les .o dans le répertoire courant n'est pas envisageable, pas plus que de "réfléchir à l'envers" pour aller dans le répertoire objet et ensuite aller pêcher les sources.

Reste enfin le souci qu'un appel à GCC avec plusieurs fichiers recompile systématiquement TOUS les fichiers passés en paramètre, il faudrait donc calculer à l'avance les fichiers à réellement recompiler. Ce dernier point est surtout gênant sur les postes de développement, bien entendu, et pas en production. Le souci existe peut-être avec Visual, mais c'est totalement masqué et transparent au niveau de l'IDE comme de la génération en ligne de commande.

Dans tous les cas, cela commence à faire vraiment beaucoup de contraintes pour pas grand-chose...

Il existe d'autres systemes de build, plus récents, qui compilent plus vite car sont capables de rassembler plusieurs fichiers sur une ligne de commande. Et meme si vous ne souhaitez pas utiliser ce genre de trucs, ce qui me chiffonne c'est que tu dis que GCC est plus lent alors qu'en fait c'est make qui est lent (et un peu passé de date, quand meme...)

Make est le seul utilisable partout, et créer / déployer / maintenir un système de build n'est pas aussi trivial que tu sembles le croire (du moins, pas sur un truc aussi volumineux et multi-plateformes). Tu as également des contraintes de production qui s'appliquent bien entendu, ainsi que la gestion de l'existant : en effet, on ne compile pas QUE du C/C++ avec GCC/VS... On a d'autres langages, du code généré, des compilateurs spécifiques, de la documentation, des drivers, la fabrication des masters, etc. Le système de build doit s'intégrer là-dedans.

Pour finir, même en ligne de commande multiple, GCC est plus lent chez moi que VS sur les quelques tests que j'ai pu faire... Je parle bien de compilation pure : pas de link, pas de make, juste l'appel en ligne de commande de CL et de GCC, et plusieurs appels consécutifs avant mesure afin d'être certain que le cache disque est actif pour les deux compilos.

Sûr que si je teste un coup avec VS sur des sources "jamais touchés", puis sur GCC, ce dernier profite du cache disque qui n'a pas profité à VS, ce qui fausse les résultats. La réciproque est tout aussi vraie, bien entendu. Il faut donc soit être certain d'avoir le cache activé (plusieurs appels consécutifs avant mesure), soit inhiber à 100% le cache disque (plus difficile, le matériel possédant son propre cache).

[screetch]

tu lis ce que tu veux bien lire. Concernant make, la liste des sources qui ont changées se fait avec $?

[Mac LAK]

tu lis ce que tu veux bien lire. Concernant make, la liste des sources qui ont changées se fait avec $?

C'est make qui fait sa sauce : il prends la liste intégrale des fichiers (wildcard), et il se débrouille tout seul via les dépendances. Il fait le boulot que l'on attends de lui, donc...

[screetch]

ce n'etait pas une question. dans uen règle avec une liste de dépendances, les dépendances qui ont effectievment changé et doivent causer la recompilation sont stockées dans la variable automatique $?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$(DEPENDS) $(OBJECTS) : $(SOURCES)
	gcc -pipe -c -MD $? && mv *.d *.o .objs/ && touch .objs/*

[Mac LAK]

Non, syntaxe de type "g++ $(CFLAGS) $< -o $@".

[screetch]

la reponse peut pas etre non, c'etait pas une question...
la variable $? (dollar point d'interrogtion) dans la regle que j'ai montré permet de recuperer la liste des fichiers pas a jour pour les recompiler en une fois

[Mac LAK]

la variable $? (dollar point d'interrogtion) dans la regle que j'ai montré permet de recuperer la liste des fichiers pas a jour pour les recompiler en une fois

Ce qui ne change rien à l'affaire : le répertoire de sortie n'est pas précisable, et il n'est pas question non plus de repartir en logique inverse et de compiler à partir du répertoire intermédiaire.

[screetch]

cf la regle que je viens de faire, elle compile et place dans .objs/

ou meme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$(DEPENDS) $(OBJECTS) : $(SOURCES)
	cd .objs && gcc -pipe -c -MD $(foreach s,$?,../$s) && touch *

[Mac LAK]

Donc, ta règle (avant-dernière) détecte les fichiers à recompiler alors que :

• Elle compile "sur place" les fichiers source,
• Elle déplace les objets et dépendances dans un répertoire après compilation.

Et elle est censée voir la différence de timestamp entre le source et l'objet par magie ?

Quand à la règle "à l'envers" (à partir du répertoire objet, la dernière), c'est niet : ce serait un boxon sans nom pour inverser la logique de fonctionnement, qui cela dit en passant serait "spécifique" à GCC : les autres compilateurs, eux, savent parfaitement spécifier un répertoire de sortie sans présupposer que c'est forcément le chemin courant...

Comme je te l'ai précisé, cette compilation ne porte pas que sur quelques fichiers bien tranquillement rangés dans leur coin : les projets sont interdépendants, et il est hors de question de rajouter des "../" partout pour tenir compte du fait que l'on n'est plus dans le répertoire racine de chaque librairie / exécutable. Je passe volontairement les problèmes de portabilité, cibles matérielles et autres configurations spécifiques clients. Bref, tu as des conditions de partout, dans le code comme dans les makefiles, et on ne va pas inverser la logique de compilation pour ça.

La compilation multiple, c'est très bien en soi, mais faudrait surtout voir pourquoi celui qui l'a ajoutée n'a pas pensé à rajouter également une option spécifiant un répertoire de sortie, sauf si bien sûr il n'a jamais compilé autre chose que des petits projets "organisés" en fourre-tout monorépertoire.

[screetch]

tu pourrais essayer un autre systeme de build, "waf" : c'est tres portable car ecrit en python. ca peut valoir le coup car c'est beaucoup beaucoup plus rapide que make.

[Mac LAK]

tu pourrais essayer un autre systeme de build, "waf" : c'est tres portable car ecrit en python. ca peut valoir le coup car c'est beaucoup beaucoup plus rapide que make.

Je me suis mal fait comprendre : je n'ai PAS la possibilité d'utiliser autre chose que make, car c'est le seul système commun à TOUTES les plate-formes, qui, je te rappelle, utilisent les mêmes sources (et les mêmes makefiles). Je n'ai pas Python sur toutes mes cibles, par exemple.

Le problème serait différent si GCC permettait de spécifier un répertoire de sortie (chose triviale, supportée par tous les compilateurs normaux), mais ce n'est pas le cas. Donc, au final, on obtient le résultat suivant : GCC deux fois plus lent que VS sur un build complet.

Ceci étant dit, comme je te l'ai dit un peu plus haut, c'est le cas aussi sur de la compilation "pure", y compris en compilation multiple.