Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Temp quand tu nous tiens...

Temp quand tu nous tiens...

17 réponses
Avatar
bruckner.olivier
Bonjour !

Me balladant sur différents forums, site internet etc, j'ai remarqué
qu'un critère me semblait crucial au yeux des programmeurs qui préfere
le C au C++ (expecté un débat sur l'OO), Il s'agit du temp de compilation.

Je suis d'accord que le C est plus vite compilé que le C++, mais je me
demande pourquoi y attacher tant d'importance, le programmeur est-il
impatient de nature ? personnellement je pense que le temp de
compilation n'es pas un paramètre crucial, j'entends par là que ce qui
doit se compiler se compilera (pas mal hein ?) et je demande donc si
l'impact sur un grand projet est sensible ou bien est-ce purement
quelque chose que l'on chéri en programmation ?

De mon point de vu celà me semble etre un faux argument (débutant) mais
j'aimerais avoir l'avis d'experts tels que vous.

Merci de m'éclairer.
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Rémy
a écrit dans le message de
news:
Christophe de VIENNE wrote in message
news:<newscache$kakwxh$bom$...
wrote:
Christophe de VIENNE wrote in message
news:<newscache$oo4vxh$084$...

En solution libre sous unix il y a distcc. Il existe aussi ccache
qui le complète très bien. Perso j'utilise les deux et je gagne des
heures et des heures de compilo chaque semaine...



[...]

Le GNU make actuel lancerait plusieurs tâches en parallel, mais tous
sur la même machine. Il ne doit pas être trop difficile à précéder
chaque tâche par un préfixe qui le fait exécuter sur une autre
machine.


Et le préfixe le + simple c'est 'distcc', qui envoit le fichier une
fois passé par le préprocesseur vers une des machines du pool.


Mais quel est alors l'intérêt ? C'est souvent la lecture des fichiers
d'en-têtes qui prend le plus de temps. Et la sortie du préprocesseur, ça
fait des fichiers d'une certaine taille, qu'on balance en plus sur le
reseau.

Je suppose que ça dépend de la configuration, mais chaque fois que j'ai
eu des problèmes des temps de compilation, le problème était le reseau,
et non le compilateur. (Mais c'était avant l'époque de tout est un
template ; avec les templates, je crois que le compilateur a bien plus à
faire aussi.)



J'ai eu beaucoup de déconvenues en essayant de paralléliser des compilations
avec des templates. Chaque compilateur a sa façon de gérer les
instanciations et utilise des fichiers temporaires "personnels" pour éviter
de recompiler ce qui a déjà été compilé.

La compilation en parallèle sur un multiprocesseur nous amenait à des
erreurs de link car les instances de compilateurs ne coopèrent pas entre
elles pour la gestion des fichiers temporaires.
La compilation distribuée fait perdre tout l'intérêt de la compilation
unique du code du template : chaque machine du parc recompile les templates
dont elle a besoin...

(Mon expérience sur Solaris, HP-UX et Tru-64)

Rémy




Avatar
Christophe de VIENNE
wrote:
Le GNU make actuel lancerait plusieurs tâches en parallel, mais tous
sur la même machine. Il ne doit pas être trop difficile à précéder
chaque tâche par un préfixe qui le fait exécuter sur une autre
machine.




Et le préfixe le + simple c'est 'distcc', qui envoit le fichier une
fois passé par le préprocesseur vers une des machines du pool.



Mais quel est alors l'intérêt ? C'est souvent la lecture des fichiers
d'en-têtes qui prend le plus de temps. Et la sortie du préprocesseur, ça
fait des fichiers d'une certaine taille, qu'on balance en plus sur le
reseau.



La lecture ou bien l'interprétation des fichiers d'entêtes ? Le
préprocessing en lui-même est assez rapide je crois.
De plus sur un réseau local à 100Mb passer des fichiers de quelques
centaines de ko c'est presque négligeable comme temps (moins d'une
seconde en général) alors que la compilation d'un .o en c++ peut prendre
plusieurs dizaines de secondes.

Je suppose que ça dépend de la configuration, mais chaque fois que j'ai
eu des problèmes des temps de compilation, le problème était le reseau,
et non le compilateur. (Mais c'était avant l'époque de tout est un
template ; avec les templates, je crois que le compilateur a bien plus à
faire aussi.)



Je te garanti que sur toutes les applications que je compile avec je
gagne un temps fou. Même le kernel linux, qui n'a évidement pas de
templates, compile plus vite en réparti avec distcc.
L'idée c'est de toujours avoir plus de jobs que de machines. Ainsi le
traffic réseau est fait alors que toutes les machines sont en train de
compiler. On ne perds du temps qu'à l'entrée et la sortie d'un dossier
(avec gnu make).


Le gros avantage de distcc est qu'il ne necessite pas la recopie des
entêtes sur toutes les machines de la "ferme".


Mais puisque toutes les machines de la ferme sont aussi des machines de
dévelopement, ou bien on récopie, ou bien la majorité des gens font le
préprocessesseur sur une autre machine qu'où il y a des en-têtes, ou
bien toutes les machines ont leur copie des en-têtes.



Justement, dans ma société toutes les machines de la ferme ne sont pas
forcément des machines de developpement (j'utilise le temps processeurs
d'autres machines peu solicitées, et des postes de travail des
développeurs). De plus toutes les machines de développement ne
travaillent pas forcément pour le même produit et donc n'ont pas
toujours toutes les bibliothèques nécessaires d'installées.

Je suppose qu'il y a des cas où c'est intéressant, mais c'est toujours
assez limité par rapport à ce que fait par exemple ClearMake.


Tu devrais essayer, je suis sûr que tu ne pourras plus t'en passer :-)
cf http://distcc.samba.org/

--
Christophe



Avatar
kanze
"Rémy" wrote in message
news:<c8dcf5$k4c$...
a écrit dans le message de
news:
Christophe de VIENNE wrote in message
news:<newscache$kakwxh$bom$...
wrote:
Christophe de VIENNE wrote in message
news:<newscache$oo4vxh$084$...

En solution libre sous unix il y a distcc. Il existe aussi
ccache qui le complète très bien. Perso j'utilise les deux et
je gagne des heures et des heures de compilo chaque semaine...



[...]

Le GNU make actuel lancerait plusieurs tâches en parallel, mais
tous sur la même machine. Il ne doit pas être trop difficile à
précéder chaque tâche par un préfixe qui le fait exécuter sur
une autre machine.


Et le préfixe le + simple c'est 'distcc', qui envoit le fichier
une fois passé par le préprocesseur vers une des machines du pool.


Mais quel est alors l'intérêt ? C'est souvent la lecture des
fichiers d'en-têtes qui prend le plus de temps. Et la sortie du
préprocesseur, ça fait des fichiers d'une certaine taille, qu'on
balance en plus sur le reseau.

Je suppose que ça dépend de la configuration, mais chaque fois que
j'ai eu des problèmes des temps de compilation, le problème était le
reseau, et non le compilateur. (Mais c'était avant l'époque de tout
est un template ; avec les templates, je crois que le compilateur a
bien plus à faire aussi.)


J'ai eu beaucoup de déconvenues en essayant de paralléliser des
compilations avec des templates. Chaque compilateur a sa façon de
gérer les instanciations et utilise des fichiers temporaires
"personnels" pour éviter de recompiler ce qui a déjà été compilé.


Intéressante observation. Mon expérience avec la compilation répartie
date d'avant les templates. Je n'ai donc constaté aucun problème.

Je crois que les problèmes dépendraient de l'implémentation des
templates -- je ne crois pas que la façon que procède g++, par exemple,
poserait un problème.

Je serais intéressé comment ClearCase résoud ce problème. En tant que
produit commerciel qui supporte (ou supportait) la compilation répartie
d'office, il faudrait bien qu'ils aient une solution.

La compilation en parallèle sur un multiprocesseur nous amenait à des
erreurs de link car les instances de compilateurs ne coopèrent pas
entre elles pour la gestion des fichiers temporaires. La compilation
distribuée fait perdre tout l'intérêt de la compilation unique du code
du template : chaque machine du parc recompile les templates dont elle
a besoin...

(Mon expérience sur Solaris, HP-UX et Tru-64)


Avec les compilateurs du constructeur, je suppose. Ni g++ ni les
compilateurs Windows ne se servent d'un « repository ».

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34





Avatar
Jean-Marc Bourguet
writes:

Je serais intéressé comment ClearCase résoud ce problème. En tant
que produit commerciel qui supporte (ou supportait) la compilation
répartie d'office, il faudrait bien qu'ils aient une solution.


Je crois l'avoir deja ecrit: mal, tres mal. On a du filouter avec
SparcWorks et perdre l'interet de son modele de "repository" pour les
templates en suivant a peu pres la doc de ClearCase la-dessus. Pour
les autres compilateurs, on utilisait le mode a la Borland ou on met
tous dans les objets et laisse le linker jeter ce qui est inutile.

La compilation en parallèle sur un multiprocesseur nous amenait à des
erreurs de link car les instances de compilateurs ne coopèrent pas
entre elles pour la gestion des fichiers temporaires. La compilation
distribuée fait perdre tout l'intérêt de la compilation unique du code
du template : chaque machine du parc recompile les templates dont elle
a besoin...

(Mon expérience sur Solaris, HP-UX et Tru-64)


Avec les compilateurs du constructeur, je suppose. Ni g++ ni les
compilateurs Windows ne se servent d'un « repository ».


HP non plus. Ils ont un mode a la borland/g++ et un mode similaire a
Como (on affecte les instanciations a des objets qu'on recompile au
moment du link, l'assignation est persistante et donc lors des
compilations ulterieures on evite la recompilation sauf lors de
changements importants de structure ou on doit effacer les fichiers
decrivant l'assignation pour arriver a linker) que nous n'utilisions
pas.

Le traitement des templates en C++ est le defaut majeur de ClearCase.

Malgre cela, je regrette de devoir parle au passe de ClearCase, cela
fait deux ans que je suis sur un projet qui utilise un outil interne
base sur RCS et qui est en train de passer sur CVS et non sur
ClearCase pour des raisons politiques plus que techniques (meme pas
financieres, on a les licences ClearCase...:-()

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org


Avatar
kanze
Christophe de VIENNE wrote in message
news:<newscache$uz3xxh$n9o$...
wrote:
Le GNU make actuel lancerait plusieurs tâches en parallel, mais
tous sur la même machine. Il ne doit pas être trop difficile à
précéder chaque tâche par un préfixe qui le fait exécuter sur une
autre machine.


Et le préfixe le + simple c'est 'distcc', qui envoit le fichier une
fois passé par le préprocesseur vers une des machines du pool.


Mais quel est alors l'intérêt ? C'est souvent la lecture des
fichiers d'en-têtes qui prend le plus de temps. Et la sortie du
préprocesseur, ça fait des fichiers d'une certaine taille, qu'on
balance en plus sur le reseau.


La lecture ou bien l'interprétation des fichiers d'entêtes ?


C'était un fait accepté dans le temps que ce qui coûtait le plus cher
dans la compilation, c'était la tokenisation. C'est probablement moins
vrai aujourd'hui, c'était même faux dans le temps dès qu'il y avait une
bonne optimisation. Mais il reste que la tokenisation prend du temps.

Ta solution impose en pratique la double lecture de tout : une fois sur
la machine lançante, et une fois sur la machine qui fait la compilation
proprement dite. Dans l'absence d'optimisation, j'ai mes doutes sur ce
qu'on gagne réelement. Et pour une vraie optimisation, il faut que le
compilateur puisse voir tout le programme ; il ne s'effectue donc que
lors de l'édition de liens.

Le préprocessing en lui-même est assez rapide je crois.


Par rapport à quoi ? Il impose la lecture de tous les fichiers.

Je n'ai pas fait des mésures depuis longtemps, mais dans le temps, plus
de la moitié du temps de compilation s'écrouler dans la lecture des
fichiers. Sans optimisation, évidemment (mais les optimisations de
l'époque n'allaient pas bien loin).

De plus sur un réseau local à 100Mb passer des fichiers de quelques
centaines de ko c'est presque négligeable comme temps (moins d'une
seconde en général) alors que la compilation d'un .o en c++ peut
prendre plusieurs dizaines de secondes.


Tout le monde n'a pas de réseau local à 100Mo. Mais même à 100Mo, tout
dépend du charge du réseau. Si le charge est faible, tout se passe
bien. Lorsque le charge augument, en revanche, tu commences à avoir des
collisions, et ça se dégrade très vite.

Beaucoup dépend de la topologie du réseau. J'ai travaillé dans des
boîtes où les admin s'y connaissaient, le réseau était bien découper en
sous-réseaux assez petits, avec peu de traffic entre eux, et même avec
10MBaud, on n'a jamais eu de problème. Et j'ai travaillé dans d'autres
(plus fréquentes) où on se posait pas de questions, on mettait tout le
monde sur un seul backbone. Et où, dans la pratique, il fallait faire un
max en local, parce que le réseau était si lent.

Je ne crois pas qu'il y a une réponse définitive. Chaque cas est un peu
unique. Ce qui marche bien dans un cas pourrait ne rien apporter dans un
autre.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34




Avatar
Rémy
a écrit dans le message de
news:
"Rémy" wrote in message
news:<c8dcf5$k4c$...


(Mon expérience sur Solaris, HP-UX et Tru-64)


Avec les compilateurs du constructeur, je suppose. Ni g++ ni les
compilateurs Windows ne se servent d'un « repository ».



Oui, avec les compilateurs du constructeur.

Attention, ces expériences datent de deux ans environ...

Si je me souviens bien, le compilateur HP "compile" les templates au moment
de l'édition de liens, d'où des compilations assez rapides mais des links
très longs. Plus un "bug" qui lui empêchait d'interpréter les templates dans
on objet qui ne s'appellait pas ".o"...

Le compilateur de Sun utilise "par défaut" un repository (qui par ailleurs
pose des problèmes car il n'est pas très bien géré en cas de changement de
paramètres de compilations). Impossible de compiler deux fois le même
fichier source avec des options différentes pour obtenir deux objets sans
vider le repository à la main entre les deux.

Rémy


Avatar
James Kanze
"Rémy" writes:

|> Le compilateur de Sun utilise "par défaut" un repository (qui par
|> ailleurs pose des problèmes car il n'est pas très bien
|> géré en cas de changement de paramètres de compilations).
|> Impossible de compiler deux fois le même fichier source avec des
|> options différentes pour obtenir deux objets sans vider le
|> repository à la main entre les deux.

Je crois que ça dépend un peu des versions ; parfois j'ai
l'impression qu'il crée le répositoire dans le répertoire où
il met l'objet, parfois dans le répertoire courant d'où il a
été invoqué. De toute façon, avec Sun CC 5.1, je réussi
à compiler à la fois en 32 et en 64 bits, debug et optimisé,
sans avoir à vider le répertoire à chaque fois. Mais ça n'a
pas toujours été le cas, et je ne suis pas sûr qu'il détecte
tous les variantes correctement.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
1 2