IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Hinault Romaric
18 commentaires

22PARTAGES

6  3 
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 ?
Vous avez lu gratuitement 4 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

18 commentaires
Commenter Signaler un problème
Tryph
Avatar de Tryph
Membre émérite https://www.developpez.com
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é*



-->[]
16  3 
Lutarez
Avatar de Lutarez
Membre chevronné https://www.developpez.com
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.
8  1 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
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.

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.
4  0 
octal
Avatar de octal
En attente de confirmation mail https://www.developpez.com
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
3  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
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).

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).
2  0 
moldavi
Avatar de moldavi
Inactif https://www.developpez.com
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.
1  0 
atha2
Avatar de atha2
Membre éprouvé https://www.developpez.com
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 :

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++.
0  0 
wirenth
Avatar de wirenth
Membre averti https://www.developpez.com
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).
0  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
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.
0  0 
Squisqui
Avatar de Squisqui
En attente de confirmation mail https://www.developpez.com
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.
0  0 
Commenter Signaler un problème