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

Le 11/12/2012, par Hinault Romaric, Responsable Actualités
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 ?


 Poster une réponse

Avatar de Lutarez Lutarez
Membre chevronné
le 11/12/2012 16:46
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.
Avatar de Tryph Tryph
Membre chevronné
le 11/12/2012 17:04

Citation:





Envoyé par Lutarez
Voir le message
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é*



-->[]
Avatar de octal octal
Membre expérimenté
le 11/12/2012 17:22
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
Avatar de atha2 atha2
Membre chevronné
le 11/12/2012 17:48
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 :

Citation:




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++.
Avatar de wirenth wirenth
Membre éclairé
le 11/12/2012 18:04
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).
Avatar de Uther Uther
Expert Confirmé Sénior
le 11/12/2012 18:22

Citation:





Envoyé par Hinault Romaric

L’équipe du compilateur LLVM d’Apple

LLVM n'appartient pas à Apple.

Il s'agit de l'équipe Apple travaillant sur LLVM.
Avatar de Klaim Klaim
Expert Confirmé
le 11/12/2012 18:38
D'abord, cela a deja ete discute la: http://www.developpez.net/forums/d12...p/#post6999274


Citation:





Envoyé par 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.

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.


Citation:




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.


Citation:





Envoyé par wirenth

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.
Avatar de Squisqui Squisqui
Membre chevronné
le 11/12/2012 19:55

Citation:





Envoyé par atha2
Voir le message
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.
Avatar de moldavi moldavi
Membre Expert
le 11/12/2012 21:01
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.
Avatar de Klaim Klaim
Expert Confirmé
le 12/12/2012 0:29

Citation:





Envoyé par moldavi
Voir le message
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).


Citation:




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).
 Poster une réponse  Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum d'entraide

Blogs

Hébergement

 
Partenaires

Hébergement Web