Dans mes souvenir un pauvre hello world en C++ se retrouve tout de suite avec des tonnes d'includes en cascade, dont beaucoup ne sont des bibliothèques standards fournies par le compilo (donc ne devant jamais changer en théorie...).
Pour info, il y a nettement moins de cascade d'inclusions quand on évite les lib fournies par gcc.
Pour C++:
% find /usr/include/c++/6 -type f | wc -l
722
% find /usr/include/c++/v1 -type f | wc -l
119
Nombre de fichiers divisé par 7. Et lire le code est tout aussi intéressant, celui de clang est nettement plus lisible, notamment parce qu'il fait moins d'appels.
Pour le C (bon, ça, c'est bancal, tous les include ne sont pas dans le même dossier je pense):
% find /usr/include/x86_64-linux-gnu -type f | wc -l
310
% find /usr/include/x86_64-linux-musl -type f | wc -l
211
génère un binaire de 2M avec clang++ -static -stdlib=libstdc++ -pthread contre 2.4M avec clang++ -static -stdlib=libc++ -pthread (pour une raison qui m'échappe, lier avec pthread est obligatoire avec libc++...).
Pour info, l'inclusion d'un std::string pour affichage à coup de printf fait passer le binaire libstdc++ à 1.9M et celui de libc++ à 1.3M (très honnêtement, je déteste les stream du C++, je trouve ça illisible, mais je ne m'attendais pas à ça pour autant).
génère avec gcc -static hello.c un binaire de 792K contre 29K pour musl-gcc -static hello.c.
Du coup, si vraiment les performances de compilation sont importantes, peut-être qu'avant de vouloir sortir des outils qui font le café, utiliser des libs performantes peut aider? Bon, pour être honnête, musl n'implémente pas encore, à ma connaissance, la gestion des "locales", et se limite aux standards, cette lib n'essaie pas de fournir de fonctionnalités non standard, contrairement à GCC.
J'ai utilisé pour ces «tests» les paquets fournis par debian stable.
Je n'ai pas mesuré le temps de compilation, pour un hello world ce serait difficile à mesurer de toute façon, mais je serai surpris que les libs de gcc soient les plus rapides.
Bon, faire un strip permets de grappiller quelques octets en C. Pour le C++, le résultat est nettement plus impressionnant et place le binaire de libc++ en 1ère position (1615768 octets pour libc++ contre 1619880 octets pour libstdc++, soit à peu près 1.6M pour les deux).
[^] # Re: Quid des perfs ?
Posté par freem . En réponse au journal `smk`, un make sans Makefile. Évalué à 6.
Pour info, il y a nettement moins de cascade d'inclusions quand on évite les lib fournies par gcc.
Pour C++:
Nombre de fichiers divisé par 7. Et lire le code est tout aussi intéressant, celui de clang est nettement plus lisible, notamment parce qu'il fait moins d'appels.
Pour le C (bon, ça, c'est bancal, tous les include ne sont pas dans le même dossier je pense):
À peu près 30% de fichiers en moins pour musl.
Par contre, la compilation d'un
génère un binaire de 2M avec
clang++ -static -stdlib=libstdc++ -pthreadcontre 2.4M avecclang++ -static -stdlib=libc++ -pthread(pour une raison qui m'échappe, lier avec pthread est obligatoire avec libc++...).Pour info, l'inclusion d'un std::string pour affichage à coup de printf fait passer le binaire libstdc++ à 1.9M et celui de libc++ à 1.3M (très honnêtement, je déteste les stream du C++, je trouve ça illisible, mais je ne m'attendais pas à ça pour autant).
Pour ce qui est C, le code
génère avec
gcc -static hello.cun binaire de 792K contre 29K pourmusl-gcc -static hello.c.Du coup, si vraiment les performances de compilation sont importantes, peut-être qu'avant de vouloir sortir des outils qui font le café, utiliser des libs performantes peut aider? Bon, pour être honnête, musl n'implémente pas encore, à ma connaissance, la gestion des "locales", et se limite aux standards, cette lib n'essaie pas de fournir de fonctionnalités non standard, contrairement à GCC.
J'ai utilisé pour ces «tests» les paquets fournis par debian stable.
Je n'ai pas mesuré le temps de compilation, pour un hello world ce serait difficile à mesurer de toute façon, mais je serai surpris que les libs de gcc soient les plus rapides.
Bon, faire un
strippermets de grappiller quelques octets en C. Pour le C++, le résultat est nettement plus impressionnant et place le binaire de libc++ en 1ère position (1615768 octets pour libc++ contre 1619880 octets pour libstdc++, soit à peu près 1.6M pour les deux).