Il est difficile de généraliser sur les performances en calcul intensif car le champ des machines va d'une unique station de travail plus ou moins survitaminée à la grappe de centaines de machines pas chères. L'espace mémoire n'est pas forcément continu et les processeurs peuvent être en partie virtualisés par GPU. Certaines configurations auront obligatoirement des I/O au niveau du matériel d’interconnexion ce qui fait qu'un programme faisant des maths pures peut avoir les mêmes contingences qu'une base de données.
D'autre part, un exécutable peut se fabriquer sous deux formes principales : édition de liens statique ou dynamique.
Si on lie toutes les bibliothèques avec la routine principale on obtient un gros binaire exécutable autonome. Ça charge lentement mais ça fonctionne ensuite plus vite.
Si l'on recule l'édition de lien au moment du chargement du programme ET si on active l'option "lazy", la routine principale ne nécessitera que l'édition de lien des seules portions de bibliothèque indispensables au démarrage. Par la suite, d'autres portions de cette bibliothèque seront liées au fur et à mesure des besoins. Ça charge plus vite mais ça fonctionne plus lentement.
À noter que ces portions d'exécutables sont dispersées sur le système de fichier et que la latence de chargement "à la demande" varie selon la configuration de la variable d'environnement PATH au niveau des répertoires à explorer. Un appel système donné ne sera donc pas activé avec le même vivacité selon le référencement du répertoire de la librairie qui l'actionne. Typiquement, une lib chargera plus vite si elle est en /usr/lib plutôt qu'en /usr/local/lib.
Dans le cas de musl, on est un peu dans la même démarche qu'a eu BusyBox bien connu du monde de l'embarqué : tout mettre dans le même panier. Dans le duel "glibc" face à "musl", on retrouve la même controverse que celle des micros noyaux face aux noyaux monolithiques.
Je suppose qu'une configuration matérielle donnée sera plus avantagée par une libc donnée plutôt qu'une autre selon qu'elle soit orientée monotâche ou multitâche. Et, dans le cas de matériels poussés à l'extrême, cette différence doit être encore plus sensible qu'avec la bureautique. Sachant aussi qu'un logiciel de calcul peut être tout aussi bien fonctionner en mode monotâche ou multitâche selon qu'il est parallélisé ou non / distribué ou non.
[^] # Re: Performance des compilateurs libres
Posté par Denis Bernard . En réponse au journal Des nouvelles de Fortran. Évalué à 3.
Il est difficile de généraliser sur les performances en calcul intensif car le champ des machines va d'une unique station de travail plus ou moins survitaminée à la grappe de centaines de machines pas chères. L'espace mémoire n'est pas forcément continu et les processeurs peuvent être en partie virtualisés par GPU. Certaines configurations auront obligatoirement des I/O au niveau du matériel d’interconnexion ce qui fait qu'un programme faisant des maths pures peut avoir les mêmes contingences qu'une base de données.
D'autre part, un exécutable peut se fabriquer sous deux formes principales : édition de liens statique ou dynamique.
Si on lie toutes les bibliothèques avec la routine principale on obtient un gros binaire exécutable autonome. Ça charge lentement mais ça fonctionne ensuite plus vite.
Si l'on recule l'édition de lien au moment du chargement du programme ET si on active l'option "lazy", la routine principale ne nécessitera que l'édition de lien des seules portions de bibliothèque indispensables au démarrage. Par la suite, d'autres portions de cette bibliothèque seront liées au fur et à mesure des besoins. Ça charge plus vite mais ça fonctionne plus lentement.
À noter que ces portions d'exécutables sont dispersées sur le système de fichier et que la latence de chargement "à la demande" varie selon la configuration de la variable d'environnement PATH au niveau des répertoires à explorer. Un appel système donné ne sera donc pas activé avec le même vivacité selon le référencement du répertoire de la librairie qui l'actionne. Typiquement, une lib chargera plus vite si elle est en /usr/lib plutôt qu'en /usr/local/lib.
Dans le cas de musl, on est un peu dans la même démarche qu'a eu BusyBox bien connu du monde de l'embarqué : tout mettre dans le même panier. Dans le duel "glibc" face à "musl", on retrouve la même controverse que celle des micros noyaux face aux noyaux monolithiques.
Je suppose qu'une configuration matérielle donnée sera plus avantagée par une libc donnée plutôt qu'une autre selon qu'elle soit orientée monotâche ou multitâche. Et, dans le cas de matériels poussés à l'extrême, cette différence doit être encore plus sensible qu'avec la bureautique. Sachant aussi qu'un logiciel de calcul peut être tout aussi bien fonctionner en mode monotâche ou multitâche selon qu'il est parallélisé ou non / distribué ou non.