| > | > Je sais que ma propre implémentation expérimentale (complètement
| > | > différente) [snip]
| > |
| > | En s'y prenant complètement différemment, peut-on arriver à ne pas
| > | trop embourber le parseur, et avoir un temps de compilation
| > | acceptable ?
| >
| > Je ne sais pas. Mais, en spéculant, il faut bien voir que si la
| > pratique actuelle de mettre tout le code dans les entêtes ne changent
| > pas, je ne vois pas de raison d'espérer un temps de compilation peu
| > prohibitive : avec les concepts, le compilateur doit systématiquement
| > vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
|
| Les compilateurs qui implémentent « export », ou bien l'optimisation à
| l'édition de lien, et qui vont continuer de fournir un support
| permettant de précompiler des entêtes pour C++0x,
GCC implémente ce que les gens appellent « entêtes précompilés » (mais
pas « export ») mais je ne suis pas sûr que cela affecte la
vérification de types dans les templates.
L'implémentation d'« export » ou l'instantiation à l'édition de lien
n'élimine pas la nécessité de vérifier les types à chaque
instantiation.
| Il me semble qu'on est alors pas loin des « modules » ; au
| passage, si cela pouvait éradiquer les entêtes précompilées,
| quelle joie !
|
| Si l'utilisation des concepts devenait finalement (je lisais à
| l'instant la propositions de D.Gregor sur gcc-patch) un échec du
| point de vue temps de compilation, cela ne serait-il pas finalement un
| pas vers la bonne direction ?
Quelle bonne direction ?
| > | > Je sais que ma propre implémentation expérimentale (complètement
| > | > différente) [snip]
| > |
| > | En s'y prenant complètement différemment, peut-on arriver à ne pas
| > | trop embourber le parseur, et avoir un temps de compilation
| > | acceptable ?
| >
| > Je ne sais pas. Mais, en spéculant, il faut bien voir que si la
| > pratique actuelle de mettre tout le code dans les entêtes ne changent
| > pas, je ne vois pas de raison d'espérer un temps de compilation peu
| > prohibitive : avec les concepts, le compilateur doit systématiquement
| > vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
|
| Les compilateurs qui implémentent « export », ou bien l'optimisation à
| l'édition de lien, et qui vont continuer de fournir un support
| permettant de précompiler des entêtes pour C++0x,
GCC implémente ce que les gens appellent « entêtes précompilés » (mais
pas « export ») mais je ne suis pas sûr que cela affecte la
vérification de types dans les templates.
L'implémentation d'« export » ou l'instantiation à l'édition de lien
n'élimine pas la nécessité de vérifier les types à chaque
instantiation.
| Il me semble qu'on est alors pas loin des « modules » ; au
| passage, si cela pouvait éradiquer les entêtes précompilées,
| quelle joie !
|
| Si l'utilisation des concepts devenait finalement (je lisais à
| l'instant la propositions de D.Gregor sur gcc-patch) un échec du
| point de vue temps de compilation, cela ne serait-il pas finalement un
| pas vers la bonne direction ?
Quelle bonne direction ?
| > | > Je sais que ma propre implémentation expérimentale (complètement
| > | > différente) [snip]
| > |
| > | En s'y prenant complètement différemment, peut-on arriver à ne pas
| > | trop embourber le parseur, et avoir un temps de compilation
| > | acceptable ?
| >
| > Je ne sais pas. Mais, en spéculant, il faut bien voir que si la
| > pratique actuelle de mettre tout le code dans les entêtes ne changent
| > pas, je ne vois pas de raison d'espérer un temps de compilation peu
| > prohibitive : avec les concepts, le compilateur doit systématiquement
| > vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
|
| Les compilateurs qui implémentent « export », ou bien l'optimisation à
| l'édition de lien, et qui vont continuer de fournir un support
| permettant de précompiler des entêtes pour C++0x,
GCC implémente ce que les gens appellent « entêtes précompilés » (mais
pas « export ») mais je ne suis pas sûr que cela affecte la
vérification de types dans les templates.
L'implémentation d'« export » ou l'instantiation à l'édition de lien
n'élimine pas la nécessité de vérifier les types à chaque
instantiation.
| Il me semble qu'on est alors pas loin des « modules » ; au
| passage, si cela pouvait éradiquer les entêtes précompilées,
| quelle joie !
|
| Si l'utilisation des concepts devenait finalement (je lisais à
| l'instant la propositions de D.Gregor sur gcc-patch) un échec du
| point de vue temps de compilation, cela ne serait-il pas finalement un
| pas vers la bonne direction ?
Quelle bonne direction ?
GCC implémente ce que les gens appellent « entêtes précompilés » (mais
pas « export ») mais je ne suis pas sûr que cela affecte la
vérification de types dans les templates.
GCC implémente ce que les gens appellent « entêtes précompilés » (mais
pas « export ») mais je ne suis pas sûr que cela affecte la
vérification de types dans les templates.
GCC implémente ce que les gens appellent « entêtes précompilés » (mais
pas « export ») mais je ne suis pas sûr que cela affecte la
vérification de types dans les templates.
| D. Gregor disait récemment qu'une part importante (50%) de la
| compilation provenait de la comparaison de types. Je ne suis donc
| définitivement pas sûr que les entêtes précompilées soit utiles dans
| ce contexte.
En effet. Ce qu'il dit correspond à ce que nous (== GCC/g++) savions
depuis des lustres -- en ne considérant que C++98, C++03. Alors
imagine que maintenant on vérifie encore plus de types qu'avant !
Tu as dû lire les réponsent de Mike Stump donnant référence vers 2002
où il a déjà noté cela. Mark Mitchell l'avait noté avant. Lorsque j'ai
travaillé pour Apple (~ 2002) pour améliorer le temps de compilation,
cela faisait partie des choses que j'avais remrquées aussi.
| Peut-être pourraient-elles permettre de faire certains
| prétraitements internes avant la comparaison des types ? Mais ça
| n'en vaut peut être pas la peine.
Mais cela n'exigerait-il pas une analyse sémantique du programme ?
| > L'implémentation d'« export » ou l'instantiation à l'édition de lien
|
| Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| n'implique pas l'instantiation à l'édition de lien.
Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
| Est-ce pourtant le
| cas avec certains compilateurs ? (autres que le futur GCC-4.3/4 avec
| LTO)
|
| > n'élimine pas la nécessité de vérifier les types à chaque
| > instantiation.
|
| Non, mais bon, vu que la réduction du nombre d'instances réduit le
Pourquoi est-ce que le nombre d'instances serait réduit ?
| coût liés à la vérification des types; on peut quand même dire que des
| techniques du genre LTO, IMA seront profitables à une compilation
| rapide de codes utilisant les concepts.
|
|
| > | Il me semble qu'on est alors pas loin des « modules » ; au
| > | passage, si cela pouvait éradiquer les entêtes précompilées,
| > | quelle joie !
| > |
| > | Si l'utilisation des concepts devenait finalement (je lisais à
| > | l'instant la propositions de D.Gregor sur gcc-patch) un échec du
| > | point de vue temps de compilation, cela ne serait-il pas finalement un
| > | pas vers la bonne direction ?
| >
| > Quelle bonne direction ?
|
| une compilation basée sur des modules, limitant ainsi le nombre
| d'instanciation. Du coup je me demandais si C++ n'allait pas
| s'orienter vers un modèle de compilation « plusieurs sources en entrée
| » ?
« plusieurs sources en entrée » est un détail d'implémentation, et
non une orientation du langage je crois.
| D. Gregor disait récemment qu'une part importante (50%) de la
| compilation provenait de la comparaison de types. Je ne suis donc
| définitivement pas sûr que les entêtes précompilées soit utiles dans
| ce contexte.
En effet. Ce qu'il dit correspond à ce que nous (== GCC/g++) savions
depuis des lustres -- en ne considérant que C++98, C++03. Alors
imagine que maintenant on vérifie encore plus de types qu'avant !
Tu as dû lire les réponsent de Mike Stump donnant référence vers 2002
où il a déjà noté cela. Mark Mitchell l'avait noté avant. Lorsque j'ai
travaillé pour Apple (~ 2002) pour améliorer le temps de compilation,
cela faisait partie des choses que j'avais remrquées aussi.
| Peut-être pourraient-elles permettre de faire certains
| prétraitements internes avant la comparaison des types ? Mais ça
| n'en vaut peut être pas la peine.
Mais cela n'exigerait-il pas une analyse sémantique du programme ?
| > L'implémentation d'« export » ou l'instantiation à l'édition de lien
|
| Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| n'implique pas l'instantiation à l'édition de lien.
Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
| Est-ce pourtant le
| cas avec certains compilateurs ? (autres que le futur GCC-4.3/4 avec
| LTO)
|
| > n'élimine pas la nécessité de vérifier les types à chaque
| > instantiation.
|
| Non, mais bon, vu que la réduction du nombre d'instances réduit le
Pourquoi est-ce que le nombre d'instances serait réduit ?
| coût liés à la vérification des types; on peut quand même dire que des
| techniques du genre LTO, IMA seront profitables à une compilation
| rapide de codes utilisant les concepts.
|
|
| > | Il me semble qu'on est alors pas loin des « modules » ; au
| > | passage, si cela pouvait éradiquer les entêtes précompilées,
| > | quelle joie !
| > |
| > | Si l'utilisation des concepts devenait finalement (je lisais à
| > | l'instant la propositions de D.Gregor sur gcc-patch) un échec du
| > | point de vue temps de compilation, cela ne serait-il pas finalement un
| > | pas vers la bonne direction ?
| >
| > Quelle bonne direction ?
|
| une compilation basée sur des modules, limitant ainsi le nombre
| d'instanciation. Du coup je me demandais si C++ n'allait pas
| s'orienter vers un modèle de compilation « plusieurs sources en entrée
| » ?
« plusieurs sources en entrée » est un détail d'implémentation, et
non une orientation du langage je crois.
| D. Gregor disait récemment qu'une part importante (50%) de la
| compilation provenait de la comparaison de types. Je ne suis donc
| définitivement pas sûr que les entêtes précompilées soit utiles dans
| ce contexte.
En effet. Ce qu'il dit correspond à ce que nous (== GCC/g++) savions
depuis des lustres -- en ne considérant que C++98, C++03. Alors
imagine que maintenant on vérifie encore plus de types qu'avant !
Tu as dû lire les réponsent de Mike Stump donnant référence vers 2002
où il a déjà noté cela. Mark Mitchell l'avait noté avant. Lorsque j'ai
travaillé pour Apple (~ 2002) pour améliorer le temps de compilation,
cela faisait partie des choses que j'avais remrquées aussi.
| Peut-être pourraient-elles permettre de faire certains
| prétraitements internes avant la comparaison des types ? Mais ça
| n'en vaut peut être pas la peine.
Mais cela n'exigerait-il pas une analyse sémantique du programme ?
| > L'implémentation d'« export » ou l'instantiation à l'édition de lien
|
| Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| n'implique pas l'instantiation à l'édition de lien.
Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
| Est-ce pourtant le
| cas avec certains compilateurs ? (autres que le futur GCC-4.3/4 avec
| LTO)
|
| > n'élimine pas la nécessité de vérifier les types à chaque
| > instantiation.
|
| Non, mais bon, vu que la réduction du nombre d'instances réduit le
Pourquoi est-ce que le nombre d'instances serait réduit ?
| coût liés à la vérification des types; on peut quand même dire que des
| techniques du genre LTO, IMA seront profitables à une compilation
| rapide de codes utilisant les concepts.
|
|
| > | Il me semble qu'on est alors pas loin des « modules » ; au
| > | passage, si cela pouvait éradiquer les entêtes précompilées,
| > | quelle joie !
| > |
| > | Si l'utilisation des concepts devenait finalement (je lisais à
| > | l'instant la propositions de D.Gregor sur gcc-patch) un échec du
| > | point de vue temps de compilation, cela ne serait-il pas finalement un
| > | pas vers la bonne direction ?
| >
| > Quelle bonne direction ?
|
| une compilation basée sur des modules, limitant ainsi le nombre
| d'instanciation. Du coup je me demandais si C++ n'allait pas
| s'orienter vers un modèle de compilation « plusieurs sources en entrée
| » ?
« plusieurs sources en entrée » est un détail d'implémentation, et
non une orientation du langage je crois.
(Fabien Chêne) writes:
| Gabriel Dos Reis writes:
|
| > | D. Gregor disait récemment qu'une part importante (50%) de la
| > | compilation provenait de la comparaison de types. Je ne suis donc
| > | définitivement pas sûr que les entêtes précompilées soit utiles dans
| > | ce contexte.
| >
| > En effet. Ce qu'il dit correspond à ce que nous (== GCC/g++) savions
| > depuis des lustres -- en ne considérant que C++98, C++03. Alors
| > imagine que maintenant on vérifie encore plus de types qu'avant !
| > Tu as dû lire les réponsent de Mike Stump donnant référence vers 2002
| > où il a déjà noté cela. Mark Mitchell l'avait noté avant. Lorsque j'ai
| > travaillé pour Apple (~ 2002) pour améliorer le temps de compilation,
| > cela faisait partie des choses que j'avais remrquées aussi.
|
| J'avoue que la conversation en question est un peu trop technique pour
| moi, et je n'ai pas réussi à comprendre pourquoi il était difficile de
| prédire l'efficacité du remède « canonical type node ». Vu que tu as
| l'air d'en avoir eu l'expérience avec « le Pivot », cela a-t'il été
| un réel succès ?
Comme je l'ai expliqué, c'est quelque chose que BS et
moi avions discuté et implementé an automne 2004. À l'époque nous
avions mesuré que sur le simple programme « Hello World » classique,
la technique d'unification permettait de construire moins de 90%
d'objets « tree » que GCC (3.4.x).
Nous avions fait circuler des copies du rapport à la réunon de
Redmond (certains personnes impliquées directement dans GCC en avait
connaissance). Nous n'avions pas du tout été surpris que, quelques
mois plus tard, une analyse plus poussée ait été faite par
Nathan. Je suis juste un peu surpris que cela déclenche une
discussion aussi animée deux ans plus tard :-)
| > | > L'implémentation d'« export » ou l'instantiation à l'édition de lien
| > |
| > | Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| > | n'implique pas l'instantiation à l'édition de lien.
| >
| > Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
|
| Je me réfère de mémoire aux papiers décrivant LTO pour GCC, donc ce
| n'est surement pas valable pour des compilateurs qui pourraient avoir
| adopter une stratégie différente.
|
| Concrètement, sans LTO, on a deux fichiers sources a.cpp et
| b.cpp. Tout deux instancient le même template, il y a donc duplication
| de l'instance dans les deux TU -- le linker tachera de n'en retenir
| qu'une seule.
Oui.
Remarque bien que le but original de la LTO, qui veut dire « Link Time
Optimizatin », c'est de faire des optimisations au moment de l'édition
de lien. Ce n'est pas quelque conçu en priorité pour C++ et les
templates. Il y a pas de gens sceptiquees voire contre le
fait qu'on s'en serve pour les templates. Mais, je suis du même avis
que Mark Mitchell que si on a cette infrastructure, c'est bête de ne
pas en profiter pour les templates.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Avec LTO: a.cpp est compilé dans un .o qui va contenir en supplément,
| une forme légèrement modifié du résultat du front-end. b.cpp est
| compilé avec a.o (g++ --lto b.cpp a.o). a.o passe par le front-end
| « spécial LTO ». b.cpp passe par le front-end C++, et a accès aux
| données provenant de a.o. Lorsqu'il voit un template, il va jeter un
| oeil dans la table de recherche indexé par les arguments template,
| trouve ce template instancié, et donc ne le réinstancie pas.
C'est un peu trop simplifié, mais une bonne partie de l'idée est là.
Note bien que maintenant, il va falloir déplacer pratiquement tout le
front-end C++ dans LTO (ou du mois faire partager les fonctionalités).
La raison est que l'instantiation d'un template demande uns analyse
sémantique complète, incluant résolution de surcharges d'opérateurs et
compagnies.
Concrètement, il faudra d'une manière ou d'une autre encoder les
contextes de définitions d'un templates, ainsi que les contextes
d'instantiations pour que lto s'y retrouve.
| On a pas eu besoin de différer l'instanciation à l'édition de lien.
| Correct ?
|
| > | Est-ce pourtant le
| > | cas avec certains compilateurs ? (autres que le futur GCC-4.3/4 avec
| > | LTO)
| > |
| > | > n'élimine pas la nécessité de vérifier les types à chaque
| > | > instantiation.
| > |
| > | Non, mais bon, vu que la réduction du nombre d'instances réduit le
| >
| > Pourquoi est-ce que le nombre d'instances serait réduit ?
|
| Par réduit, j'entendais non dupliquées dans diverses TU .
Le nombres de requêtes d'instantiations ne diminuent pas pour
autant. Il faudra encoder les contextes d'instantiations, et les
combiner, et les comparer plus tard.
| > | une compilation basée sur des modules, limitant ainsi le nombre
| > | d'instanciation. Du coup je me demandais si C++ n'allait pas
| > | s'orienter vers un modèle de compilation « plusieurs sources en entrée
| > | » ?
| >
| > « plusieurs sources en entrée » est un détail d'implémentation, et
| > non une orientation du langage je crois.
|
| Vu que cela affecte la manière d'invoquer le compilateur, et surtout
| les dépendances; je me demande de quelle implémentation, « plusieurs
| sources en entrée », en est un détail ? :-)
En aucun cas, ce n'est une propriété intrinsèque du langage.
fabien.chene@gmail.com (Fabien Chêne) writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > | D. Gregor disait récemment qu'une part importante (50%) de la
| > | compilation provenait de la comparaison de types. Je ne suis donc
| > | définitivement pas sûr que les entêtes précompilées soit utiles dans
| > | ce contexte.
| >
| > En effet. Ce qu'il dit correspond à ce que nous (== GCC/g++) savions
| > depuis des lustres -- en ne considérant que C++98, C++03. Alors
| > imagine que maintenant on vérifie encore plus de types qu'avant !
| > Tu as dû lire les réponsent de Mike Stump donnant référence vers 2002
| > où il a déjà noté cela. Mark Mitchell l'avait noté avant. Lorsque j'ai
| > travaillé pour Apple (~ 2002) pour améliorer le temps de compilation,
| > cela faisait partie des choses que j'avais remrquées aussi.
|
| J'avoue que la conversation en question est un peu trop technique pour
| moi, et je n'ai pas réussi à comprendre pourquoi il était difficile de
| prédire l'efficacité du remède « canonical type node ». Vu que tu as
| l'air d'en avoir eu l'expérience avec « le Pivot », cela a-t'il été
| un réel succès ?
Comme je l'ai expliqué, c'est quelque chose que BS et
moi avions discuté et implementé an automne 2004. À l'époque nous
avions mesuré que sur le simple programme « Hello World » classique,
la technique d'unification permettait de construire moins de 90%
d'objets « tree » que GCC (3.4.x).
Nous avions fait circuler des copies du rapport à la réunon de
Redmond (certains personnes impliquées directement dans GCC en avait
connaissance). Nous n'avions pas du tout été surpris que, quelques
mois plus tard, une analyse plus poussée ait été faite par
Nathan. Je suis juste un peu surpris que cela déclenche une
discussion aussi animée deux ans plus tard :-)
| > | > L'implémentation d'« export » ou l'instantiation à l'édition de lien
| > |
| > | Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| > | n'implique pas l'instantiation à l'édition de lien.
| >
| > Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
|
| Je me réfère de mémoire aux papiers décrivant LTO pour GCC, donc ce
| n'est surement pas valable pour des compilateurs qui pourraient avoir
| adopter une stratégie différente.
|
| Concrètement, sans LTO, on a deux fichiers sources a.cpp et
| b.cpp. Tout deux instancient le même template, il y a donc duplication
| de l'instance dans les deux TU -- le linker tachera de n'en retenir
| qu'une seule.
Oui.
Remarque bien que le but original de la LTO, qui veut dire « Link Time
Optimizatin », c'est de faire des optimisations au moment de l'édition
de lien. Ce n'est pas quelque conçu en priorité pour C++ et les
templates. Il y a pas de gens sceptiquees voire contre le
fait qu'on s'en serve pour les templates. Mais, je suis du même avis
que Mark Mitchell que si on a cette infrastructure, c'est bête de ne
pas en profiter pour les templates.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Avec LTO: a.cpp est compilé dans un .o qui va contenir en supplément,
| une forme légèrement modifié du résultat du front-end. b.cpp est
| compilé avec a.o (g++ --lto b.cpp a.o). a.o passe par le front-end
| « spécial LTO ». b.cpp passe par le front-end C++, et a accès aux
| données provenant de a.o. Lorsqu'il voit un template, il va jeter un
| oeil dans la table de recherche indexé par les arguments template,
| trouve ce template instancié, et donc ne le réinstancie pas.
C'est un peu trop simplifié, mais une bonne partie de l'idée est là.
Note bien que maintenant, il va falloir déplacer pratiquement tout le
front-end C++ dans LTO (ou du mois faire partager les fonctionalités).
La raison est que l'instantiation d'un template demande uns analyse
sémantique complète, incluant résolution de surcharges d'opérateurs et
compagnies.
Concrètement, il faudra d'une manière ou d'une autre encoder les
contextes de définitions d'un templates, ainsi que les contextes
d'instantiations pour que lto s'y retrouve.
| On a pas eu besoin de différer l'instanciation à l'édition de lien.
| Correct ?
|
| > | Est-ce pourtant le
| > | cas avec certains compilateurs ? (autres que le futur GCC-4.3/4 avec
| > | LTO)
| > |
| > | > n'élimine pas la nécessité de vérifier les types à chaque
| > | > instantiation.
| > |
| > | Non, mais bon, vu que la réduction du nombre d'instances réduit le
| >
| > Pourquoi est-ce que le nombre d'instances serait réduit ?
|
| Par réduit, j'entendais non dupliquées dans diverses TU .
Le nombres de requêtes d'instantiations ne diminuent pas pour
autant. Il faudra encoder les contextes d'instantiations, et les
combiner, et les comparer plus tard.
| > | une compilation basée sur des modules, limitant ainsi le nombre
| > | d'instanciation. Du coup je me demandais si C++ n'allait pas
| > | s'orienter vers un modèle de compilation « plusieurs sources en entrée
| > | » ?
| >
| > « plusieurs sources en entrée » est un détail d'implémentation, et
| > non une orientation du langage je crois.
|
| Vu que cela affecte la manière d'invoquer le compilateur, et surtout
| les dépendances; je me demande de quelle implémentation, « plusieurs
| sources en entrée », en est un détail ? :-)
En aucun cas, ce n'est une propriété intrinsèque du langage.
(Fabien Chêne) writes:
| Gabriel Dos Reis writes:
|
| > | D. Gregor disait récemment qu'une part importante (50%) de la
| > | compilation provenait de la comparaison de types. Je ne suis donc
| > | définitivement pas sûr que les entêtes précompilées soit utiles dans
| > | ce contexte.
| >
| > En effet. Ce qu'il dit correspond à ce que nous (== GCC/g++) savions
| > depuis des lustres -- en ne considérant que C++98, C++03. Alors
| > imagine que maintenant on vérifie encore plus de types qu'avant !
| > Tu as dû lire les réponsent de Mike Stump donnant référence vers 2002
| > où il a déjà noté cela. Mark Mitchell l'avait noté avant. Lorsque j'ai
| > travaillé pour Apple (~ 2002) pour améliorer le temps de compilation,
| > cela faisait partie des choses que j'avais remrquées aussi.
|
| J'avoue que la conversation en question est un peu trop technique pour
| moi, et je n'ai pas réussi à comprendre pourquoi il était difficile de
| prédire l'efficacité du remède « canonical type node ». Vu que tu as
| l'air d'en avoir eu l'expérience avec « le Pivot », cela a-t'il été
| un réel succès ?
Comme je l'ai expliqué, c'est quelque chose que BS et
moi avions discuté et implementé an automne 2004. À l'époque nous
avions mesuré que sur le simple programme « Hello World » classique,
la technique d'unification permettait de construire moins de 90%
d'objets « tree » que GCC (3.4.x).
Nous avions fait circuler des copies du rapport à la réunon de
Redmond (certains personnes impliquées directement dans GCC en avait
connaissance). Nous n'avions pas du tout été surpris que, quelques
mois plus tard, une analyse plus poussée ait été faite par
Nathan. Je suis juste un peu surpris que cela déclenche une
discussion aussi animée deux ans plus tard :-)
| > | > L'implémentation d'« export » ou l'instantiation à l'édition de lien
| > |
| > | Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| > | n'implique pas l'instantiation à l'édition de lien.
| >
| > Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
|
| Je me réfère de mémoire aux papiers décrivant LTO pour GCC, donc ce
| n'est surement pas valable pour des compilateurs qui pourraient avoir
| adopter une stratégie différente.
|
| Concrètement, sans LTO, on a deux fichiers sources a.cpp et
| b.cpp. Tout deux instancient le même template, il y a donc duplication
| de l'instance dans les deux TU -- le linker tachera de n'en retenir
| qu'une seule.
Oui.
Remarque bien que le but original de la LTO, qui veut dire « Link Time
Optimizatin », c'est de faire des optimisations au moment de l'édition
de lien. Ce n'est pas quelque conçu en priorité pour C++ et les
templates. Il y a pas de gens sceptiquees voire contre le
fait qu'on s'en serve pour les templates. Mais, je suis du même avis
que Mark Mitchell que si on a cette infrastructure, c'est bête de ne
pas en profiter pour les templates.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Avec LTO: a.cpp est compilé dans un .o qui va contenir en supplément,
| une forme légèrement modifié du résultat du front-end. b.cpp est
| compilé avec a.o (g++ --lto b.cpp a.o). a.o passe par le front-end
| « spécial LTO ». b.cpp passe par le front-end C++, et a accès aux
| données provenant de a.o. Lorsqu'il voit un template, il va jeter un
| oeil dans la table de recherche indexé par les arguments template,
| trouve ce template instancié, et donc ne le réinstancie pas.
C'est un peu trop simplifié, mais une bonne partie de l'idée est là.
Note bien que maintenant, il va falloir déplacer pratiquement tout le
front-end C++ dans LTO (ou du mois faire partager les fonctionalités).
La raison est que l'instantiation d'un template demande uns analyse
sémantique complète, incluant résolution de surcharges d'opérateurs et
compagnies.
Concrètement, il faudra d'une manière ou d'une autre encoder les
contextes de définitions d'un templates, ainsi que les contextes
d'instantiations pour que lto s'y retrouve.
| On a pas eu besoin de différer l'instanciation à l'édition de lien.
| Correct ?
|
| > | Est-ce pourtant le
| > | cas avec certains compilateurs ? (autres que le futur GCC-4.3/4 avec
| > | LTO)
| > |
| > | > n'élimine pas la nécessité de vérifier les types à chaque
| > | > instantiation.
| > |
| > | Non, mais bon, vu que la réduction du nombre d'instances réduit le
| >
| > Pourquoi est-ce que le nombre d'instances serait réduit ?
|
| Par réduit, j'entendais non dupliquées dans diverses TU .
Le nombres de requêtes d'instantiations ne diminuent pas pour
autant. Il faudra encoder les contextes d'instantiations, et les
combiner, et les comparer plus tard.
| > | une compilation basée sur des modules, limitant ainsi le nombre
| > | d'instanciation. Du coup je me demandais si C++ n'allait pas
| > | s'orienter vers un modèle de compilation « plusieurs sources en entrée
| > | » ?
| >
| > « plusieurs sources en entrée » est un détail d'implémentation, et
| > non une orientation du langage je crois.
|
| Vu que cela affecte la manière d'invoquer le compilateur, et surtout
| les dépendances; je me demande de quelle implémentation, « plusieurs
| sources en entrée », en est un détail ? :-)
En aucun cas, ce n'est une propriété intrinsèque du langage.
