Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 19 sur 19
  1. #1
    Responsable Actualités

    Avatar de Hinault Romaric
    Homme Profil pro Hinault Romaric
    Consultant
    Inscrit en
    janvier 2007
    Messages
    3 742
    Détails du profil
    Informations personnelles :
    Nom : Homme Hinault Romaric
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 3 742
    Points : 50 369
    Points
    50 369

    Par défaut Comment améliorer le temps de compilation pour C/C++ ?

    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 ?
    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog Mes articles
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre Expert

    Homme Profil pro Claude
    Développeur .NET
    Inscrit en
    juin 2007
    Messages
    357
    Détails du profil
    Informations personnelles :
    Nom : Homme Claude
    Âge : 25
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2007
    Messages : 357
    Points : 1 120
    Points
    1 120

    Par défaut

    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.

  3. #3
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2010
    Messages
    378
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2010
    Messages : 378
    Points : 1 531
    Points
    1 531

    Par défaut

    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é*



    -->[]

  4. #4
    Membre expérimenté
    Avatar de octal
    Inscrit en
    septembre 2004
    Messages
    374
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 374
    Points : 596
    Points
    596

    Par défaut

    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
    http://www.neaticons.com png glyphs and icons for website and application developpers.
    http://www.pocketmt.com GLCD Font Creator home site.

  5. #5
    Membre émérite Avatar de atha2
    Homme Profil pro Gabriel VIOT
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    613
    Détails du profil
    Informations personnelles :
    Nom : Homme Gabriel VIOT
    Âge : 27
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2007
    Messages : 613
    Points : 845
    Points
    845

    Par défaut

    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++.

  6. #6
    Membre éclairé
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2011
    Messages
    74
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 74
    Points : 333
    Points
    333

    Par défaut

    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).

  7. #7
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 028
    Points : 5 834
    Points
    5 834

    Par défaut

    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.

  8. #8
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 718
    Points : 3 026
    Points
    3 026

    Par défaut

    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.

  9. #9
    Membre émérite Avatar de Squisqui
    Inscrit en
    décembre 2010
    Messages
    353
    Détails du profil
    Informations forums :
    Inscription : décembre 2010
    Messages : 353
    Points : 991
    Points
    991

    Par défaut

    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.

  10. #10
    Expert Confirmé

    Homme Profil pro david
    Responsable développement
    Inscrit en
    décembre 2003
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Nom : Homme david
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 626
    Points : 2 600
    Points
    2 600

    Par défaut Bonjour

    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.
    Media Foundation video decoder mpeg1/mpeg2, MediaSource Kinect
    http://sourceforge.net/projects/mfnode/

    http://jeux.developpez.com/faq/directx/?page=dshow

  11. #11
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 718
    Points : 3 026
    Points
    3 026

    Par défaut

    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).

  12. #12
    Membre éprouvé Avatar de saad.hessane
    Homme Profil pro Saâd Hessane
    Ingénieur développement logiciels
    Inscrit en
    avril 2008
    Messages
    315
    Détails du profil
    Informations personnelles :
    Nom : Homme Saâd Hessane
    Âge : 25
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2008
    Messages : 315
    Points : 435
    Points
    435

    Par défaut

    Citation Envoyé par Klaim Voir le message
    [...] 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...

  13. #13
    Invité de passage
    Inscrit en
    avril 2007
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 8
    Points : 3
    Points
    3

    Par défaut gain de compilation faible

    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

  14. #14
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 718
    Points : 3 026
    Points
    3 026

    Par défaut

    Citation Envoyé par danielfr40 Voir le message
    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.

  15. #15
    Expert Confirmé Sénior
    Avatar de Paul TOTH
    Homme Profil pro Paul TOTH
    Freelance
    Inscrit en
    novembre 2002
    Messages
    5 477
    Détails du profil
    Informations personnelles :
    Nom : Homme Paul TOTH
    Âge : 45
    Localisation : Réunion

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 5 477
    Points : 14 347
    Points
    14 347

    Par défaut

    il pourrait en profiter pour remplacer {} par begin end et import pas uses , ça finirait par ressembler à du Pascal
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Produits : UPnP, RemoteOffice, FlashPascal
    Embarcadero : Ile de la Réunion, Dephi, C++Builder, RADPHP...TVA à 8,5%

  16. #16
    Invité régulier
    Homme Profil pro Benoit Bardet
    CHercheur
    Inscrit en
    août 2011
    Messages
    11
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoit Bardet
    Localisation : France

    Informations professionnelles :
    Activité : CHercheur
    Secteur : Industrie

    Informations forums :
    Inscription : août 2011
    Messages : 11
    Points : 6
    Points
    6

    Par défaut C++11

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

  17. #17
    Modérateur
    Avatar de Bktero
    Profil pro
    Ingénieur systèmes embarqués
    Inscrit en
    juin 2009
    Messages
    2 635
    Détails du profil
    Informations personnelles :
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2009
    Messages : 2 635
    Points : 6 355
    Points
    6 355

    Par défaut

    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 ^^
    Si Code::Blocks vous dit undefined reference to 'socket@12', cela signifie que vous avez un problème d'édition des liens. Allez dans Projects / Build Options / Linker Settings / Add et renseigner ici les .a qui vont bien. Exemple pour les sockets : C:\Program Files\CodeBlocks\MinGW\lib\libws2_32.a

    Pour les adeptes du langage SMS, allez ici et ramenez la traduction française ^^

    Pour vos problèmes d'embarqué, utilisez le forum dédié !

  18. #18
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 718
    Points : 3 026
    Points
    3 026

    Par défaut

    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.

  19. #19
    Membre Expert
    Avatar de white_tentacle
    Inscrit en
    novembre 2008
    Messages
    1 268
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 1 268
    Points : 1 720
    Points
    1 720

    Par défaut

    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 !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •