Discussion :

[Hinault Romaric]

Comment améliorer le temps de compilation pour C/C++ ?
Apple propose un système de modules pour remplacer les en-têtes


Un des problèmes assez décriés des langages C et C++ est le temps de compilation, qui est un peu plus long.

Cela est surtout dû à l’utilisation des en-entêtes (headers). Les développeurs d’Apple viennent de proposer un document assez intéressant qui introduit un système de modules pour C et C++ afin d’améliorer le temps de compilation.

À titre d’exemple, Apple cite le minuscule code source de « Hello world » en C : quatre lignes de code seulement. Pourtant, le fichier d’en-tête nécessaire pour sa compilation est 173 fois plus grand que l’application elle-même.

Cela est encore plus grave avec C++, où les en-têtes standards nécessaires pour compiler le petit « Hello world » sont 14 300 fois supérieures au code du programme même. Ce sont beaucoup d’informations que le compilateur doit manipuler pour exécuter le programme le plus simple du monde.

L’équipe du compilateur LLVM d’Apple a élaboré une proposition sérieuse reposant sur des modules. Un module est présenté comme un ensemble décrivant une bibliothèque : une interface de la bibliothèque (API) ; une mise en place de la bibliothèque.

Ce sera un changement assez important dans ces langages en cas d’adoption de cette proposition, car les en-têtes seront remplacées par des modules. Mais le gain en temps de compilation est également assez important.



Source : La proposition d'Apple en PDF


Et vous ?

Qu'en pensez-vous ?

[Lutarez]

Qu'en pensez-vous ?

Je vois pas trop la "nouveauté" ici dans la mesure où leur document n'a pas l'air (très) différent du draft de C++11 concernant les modules : http://www.open-std.org/jtc1/sc22/wg...2006/n2073.pdf.

[Tryph]

Qu'en pensez-vous ?

Je vois pas trop la "nouveauté" ici dans la mesure où leur document n'a pas l'air (très) différent du draft de C++11 concernant les modules : http://www.open-std.org/jtc1/sc22/wg...2006/n2073.pdf.

*envie de troller...*
*résiste...*
*...resiste encore...*
*...ne tient plus...*

bah c'est une "nouveauté Apple" quoi

*honteux mais soulagé*



-->[]

[octal]

Ce qui est étrange, je trouve, que cela rend surtout hommage à un bonhome qui était bien en avance par rapport à son temp: Niklaus Wirth
On passe tant d'année dans les améliorations du C++, et on fini par atterir sur la notion de module qu'il avait lui même proposé pour accélerer le temp de compilation et rajouter de la modularité au langage: il avait proposer cela dans Modula2 en amélioration du langage Pascal iso, puis avait poussé cela plus loin dans Oberon avec la gestion des Private/Public que l'on retrouve des années plus tard dans la programmation orientée objet.
Un bonhome qui mérite vraiment tous les honneurs

[atha2]

Je ne suis pas sûr de comprendre en quoi les modules vont améliorer le temps de compilation. Ça va probablement simplifier la mise en place de la chaine de compilation, rendre ça un peu plus propre et permettre de meilleurs outils de débuggage/profiling.

Dans le PDF il présente la complexité de la compilation actuelle de la façon suivante :

M headers with N source files
• M x N build cost

Il faudra qu'on m'explique en quoi il faut multiplier M et N. Si on fait comme devrait le faire n'importe quel développeur (IFNDEF, DEFINE...), la complexité devrait plutôt être de M + N.

Bon c'est vrai que je n'ai pas fait de C/C++ depuis un bout de temps donc si quelqu'un peut m’expliquer ce que j'ai louper, je suis tout ouïe.

Sinon il est évident que l'apport des modules (en standard ou à la Apple) ne peut être que bénéfique au C++.

[wirenth]

C'est un des points que j'aimerais le plus voir modifié dans le futur standard, pour aller vers ce que propose le D.
Mais comme mentionné plus haut, c'est quelque chose qui est déjà à l'étude par un groupe de travail du comité. Je ne comprends pas bien le pdf d'Apple, ils l'ont déjà implémenté dans LLVM ou bien ? Si oui ça peut grandement accélérer l'implémentation dans d'autres compilateurs en attendant la futur norme (dans 2 ans au moins).

[Uther]

L’équipe du compilateur LLVM d’Apple

LLVM n'appartient pas à Apple.

Il s'agit de l'équipe Apple travaillant sur LLVM.

[Klaim]

D'abord, cela a deja ete discute la: http://www.developpez.net/forums/d12...p/#post6999274

Je ne suis pas sûr de comprendre en quoi les modules vont améliorer le temps de compilation. Ça va probablement simplifier la mise en place de la chaine de compilation, rendre ça un peu plus propre et permettre de meilleurs outils de débuggage/profiling.

En gros, cela permettras au compilateur de se faire une base de donnee de tout ce qui existe comme module sous la main, puis quand un fichier source utilise un module, il suffit au compilateur d'extraire les symboles utilises et de les retrouver dans sa base de donne pour include le code (potentiellement pre-compile) dans le fichier objet genere par le fichier source.

Actuellement, le compilateur DOIT concatener entierement tout le code source de tous les headers inclus pour pouvoir compiler ET il doit tout compiler, soit chaque header au moins une fois par cpp utilise, meme si c'est exactement le meme code a chaque fois.

Il faudra qu'on m'explique en quoi il faut multiplier M et N. Si on fait comme devrait le faire n'importe quel développeur (IFNDEF, DEFINE...), la complexité devrait plutôt être de M + N.

Effectivement tu n'as peut etre pas clairemetn le modele de compilation en tete.

Admettons que j'utilise la bibliotheque standard, j'inclus iostream et par la suite ca m'inclus 10 fichiers utilises par le header iostream.
Ca veut dire que chaque fois que j'inclus iostream dans un source, ces 10 fichiers sont reinclus dans mon source (parceque "grace" aux macros, il se peut que ca ne genere pas le meme code qu'avec un autre fichier source) et ce autant de fois qu'il y a de fichiers source.

Les header guards, ils ne servent qu'a une chose : si tu inclus un header A qui inclus B et que tu inclus un header C qui inclus lui meme B, alors tu as , apres inclusion deux fois le contenu de B et comme il est interdit en C++ de faire deux definitions (pas declaration, definition) d'un meme objet/type/etc, ca ne peut pas compiler. Ton header guard, ca permet de ne pas inclure plusieurs fois le meme code dans le meme fichier source.

Ici le role des modules serait entre autre que les dis headers ne soient compiles qu'une bonne fois pour toute pour TOUS les fichiers sources memes des autres applications.

Je ne comprends pas bien le pdf d'Apple, ils l'ont déjà implémenté dans LLVM ou bien ? Si oui ça peut grandement accélérer l'implémentation dans d'autres compilateurs en attendant la futur norme (dans 2 ans au moins).

Comme dis dans le lien au debut de ce post, en gros ya une implementation dans clang mais pour l'activer faut utiliser des mots cles speciaux apparement, mais ca reste dans la branche normale du code oui. C'est develope par quelqu'un chez apple oui. Par contre il ya aussi une proposition "idealiste" faite par quelqu'un d'autre dans le standard. Voir la video dans le liens pour plus de details.

[Squisqui]

Dans le PDF il présente la complexité de la compilation actuelle de la façon suivante :
Il faudra qu'on m'explique en quoi il faut multiplier M et N. Si on fait comme devrait le faire n'importe quel développeur (IFNDEF, DEFINE...), la complexité devrait plutôt être de M + N.

M * N est plus proche de la réalité, même si ça reste tout à fait empirique.
Pour faire simple, tu dois inclure le même header dans chaque fichier source qui en a besoin, qui sera ensuite compilé une multitude de fois.

[moldavi]

Par hasard, n'est-ce pas la même chose que les en-tête précompilés de Visual Studio ?

PS : je n'ai pas encore lu le pdf.

[Klaim]

Par hasard, n'est-ce pas la même chose que les en-tête précompilés de Visual Studio ?

PS : je n'ai pas encore lu le pdf.

Oui et non (voir le liens que j'ai indique au dessus).

Pour faire court, les entetes precompiles sont une liste precompilee de headers mis ensemble donc si tu en changes un tous doivent etre recompiles. C'est utile seulement si tes fichiers d'entete inclus dans ce fichiers sont tres stables et utiles partout.

La il sagit plutot de mettre en cache tous les symboles de tous les modules dispo, puis de precompiler les parties utilises. Si tu changes un module, seul ce module est compile.

On va dire que le principe de fond est similaire, mais l'impact est beaucoup plus general (theoriquement) avec les modules (et ne necessite pas d'intervension du programmeur C++ final).

M * N est plus proche de la réalité, même si ça reste tout à fait empirique.

Il faut comprendre que ca part d'une constatation: plus on a une base de code grande en C++, plus la proportion de headers depasse 2 ou 3 fois la proportion de fichiers unite (cpp), donc on arrive vite ( pour une appli raisonablement complexe) a une augmentation exponentielle du temps de compilation de l'appli.
Je me suis deja retrouve une fois avec une appli ou un ensemble de cpp prenaient environ 10 minutes chacun a compiler, essentiellement parcequ'ils incluaient tous les memes headers. Dans le cas theorique des modules, les 10 minutes auraient passes une fois et seul le code du cpp modifie aurait change par la suite (parcequ'on ne changeait pas le contenu des dis headers - au risque de perdre une heure de recompile).

[saad.hessane]

[...] Admettons que j'utilise la bibliotheque standard, j'inclus iostream et par la suite ca m'inclus 10 fichiers utilises par le header iostream.
Ca veut dire que chaque fois que j'inclus iostream dans un source, ces 10 fichiers sont reinclus dans mon source (parceque "grace" aux macros, il se peut que ca ne genere pas le meme code qu'avec un autre fichier source) et ce autant de fois qu'il y a de fichiers source.

Les header guards, ils ne servent qu'a une chose : si tu inclus un header A qui inclus B et que tu inclus un header C qui inclus lui meme B, alors tu as , apres inclusion deux fois le contenu de B et comme il est interdit en C++ de faire deux definitions (pas declaration, definition) d'un meme objet/type/etc, ca ne peut pas compiler. Ton header guard, ca permet de ne pas inclure plusieurs fois le meme code dans le meme fichier source.

Ton explication n'est pas fausse, mais ça n'est pas ce qui explique à mon sens la complexité MxN.
Pour l'expliquer prenons un exemple : "source1.cpp", "source2.cpp" ... "sourceN.cpp" incluent "header1.h", "header2.h" ... "headerM.h" .
Pour compiler le programme (ou la lib), les fichiers sources sont compilés indépendamment, pour créer un (ou plusieurs) fichier objet par fichier source. En gros source1.cpp est compilé pour donner source1.o, et source2.cpp est compilé pour donner source2.o...
Les N compilations sont indépendantes. A chaque compilation il y a l'inclusion de M fichier header.
Nous avons donc une complexité de MxN au pire.

Après avoir eu tous les fichiers objets, l'éditeur de lien entre en scène. Mais ça c'est encore une autre histoire...

[danielfr40]

des systèmes de compilation utilisent des cachent dans lesquels les entêtes sont précompilées, c'est le cas chez c++ builder, je pense donc que le gain réel sera faible
peut-être en gnu, je ne crois pas qu'ils aient ce système de cache

[Klaim]

des systèmes de compilation utilisent des cachent dans lesquels les entêtes sont précompilées, c'est le cas chez c++ builder, je pense donc que le gain réel sera faible
peut-être en gnu, je ne crois pas qu'ils aient ce système de cache

Nope, ils ne peuvent pas vraiment a cause des macros. Enfin, ils cachent pendant la compilation mais pas entre les compilations.

[Paul TOTH]

il pourrait en profiter pour remplacer {} par begin end et import pas uses , ça finirait par ressembler à du Pascal

[boutor]

Si j'ai bien compris les commentaires, c'est déjà en place dans C++11.

[Bktero]

Actuellement, le compilateur DOIT concatener entierement tout le code source de tous les headers inclus pour pouvoir compiler ET il doit tout compiler, soit chaque header au moins une fois par cpp utilise, meme si c'est exactement le meme code a chaque fois.

Un header contient généralement des déclarations de symboles (prototypes de fonctions, macros de pré-processeur, variables externes). Ces éléments ne devraient-il pas être beaucoup plus rapides à compiler que du code avec des instructions ? Du coup, le temps de compilation d'un header comparé à la compilation du contenu du code (sous-entendu, instruction de calcul) est-il si important ?

Je parle bien pour un fichier, je comprends que si on répète l'opération 36 fois, c'est sûrement pas mal de fois le travail.

D'ailleurs, parle t-on uniquement du temps de compilation ou aussi du temps de linkage et de pré-processeur ?

Il faudra que je lise le document demain, il est trop tard now ^^

[Klaim]

En theorie oui ca serait que des declarations simple. En pratique les declarations de classe sont plus complexes que les declarations de fonctions. Surtout si les membres sont aussi des classes, alors il faut inclure leur declaration aussi. Et tu n'echapperas pas aux templates dans les bibliotheques (ce qui fait leur genericite) standard ou pas.

Donc c'est un probleme de quantite et de complexite aussi.

[white_tentacle]

La grosse différence c’est que les modules ne dépendent pas de l’environnement extérieur, alors que les en-têtes, si. C’est d’ailleurs pour ça que l’inclusion des en-têtes précompilés de visual doit apparaître en tout premier dans le fichier cpp.

La solution ici présente a l’inconvénient (par rapport aux en-têtes précompilés) de nécessiter des évolutions langage, mais elle est plus propre, plus modulaire. Bref, du tout bon !