la possibilité de découvrir à l'exécution ce qui est disponible ou non sur le cpu
Le CPU donne ces informations. Il existe diverses méthodes sur les diverses architectures pour obtenir ces informations. Par exemple, l'architecture x86 a l'instruction générique CPUID (depuis 1993 d'après Wikipedia, donc vous avez la prise en charge d'une majeure partie des CPUs de l'histoire de l'informatique grand public) qui est faite spécifiquement pour cela.
Pour ceux qui veulent voir ce que vous dit cette instructions, sur Linux, vous pouvez installer l'outil de ligne de commande cpuid qui vous fera un beau résumé en texte clair. Bien sûr dans un programme, il n'est nullement besoin de dépendre d'un tel programme en CLI. Puisque c'est une instruction processeur, faites la requête directement depuis votre code.
Dans d'autres cas, l'info pourrait venir d'autres instructions ou d'une interface kernel (apparemment c'est ce qu'on a pour la détection ARM neon), etc. Dans tous les cas, l'info est disponible. Le principe est d'avoir des fonctions de détection qu'on maintient et met à jour lorsqu'une nouvelle détection est ajoutée (ces interfaces étant normalement stables, elles ne sont jamais retirée, une fois une détection ajoutée, c'est normalement "à vie"). En fait ce n'est pas grave de manquer un type de détection. Dans ce cas, le code se repliera juste sur l'implémentation générique jusqu'au jour où quelqu'un qui s'y connaît ou fait quelques recherches ajoute la détection nécessaire. C'est comme ça que fonctionne le logiciel libre communautaire (par ajout incrémental de nouveaux contributeurs). C'est OK même si on aurait pu utiliser une implémentation plus rapide plus tôt.
Pour ce cas là, ça pourrait être au linkage avoir une implémentation pour chacun pour le cas des stack graphiques.
Tu parles de chargement dynamique à l'exécution? Parce que si tu parles de ce qu'on appelle habituellement du linking, c'est à la construction (juste après la compilation), ce n'est pas quelque chose qui se fait à l'exécution. Si tu fais des choix à cette étape là, alors ton binaire n'a plus toutes les capacités possibles et ne fonctionne plus partout.
Au contraire, ce que je dis, c'est qu'à la compilation/linking, tu inclus tout ce que ton compilateur permet (sans te préoccuper de la cible, ou plutôt des multiples cibles qu'aura ton binaire), et c'est à l'exécution que tu fais les choix de quoi exécuter.
Si tu parles de chargement dynamique, du type tu as une bibliothèque avec les implémentations génériques, une bibliothèque avec implémentations SSE2, etc. Puis tu choisis quelle version charger à l'exécution. Oui c'est possible et certains projets font un peu ainsi, mais ce n'est nullement obligatoire. Tu peux simplement tout embarquer dans le même binaire, et tu fais les choix de quelle branche de code exécuter selon la détection des capacités du hardware au moment de l'exécution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Who's that guy ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Software is Way Less Performant Today. Évalué à 4.
Le CPU donne ces informations. Il existe diverses méthodes sur les diverses architectures pour obtenir ces informations. Par exemple, l'architecture x86 a l'instruction générique
CPUID(depuis 1993 d'après Wikipedia, donc vous avez la prise en charge d'une majeure partie des CPUs de l'histoire de l'informatique grand public) qui est faite spécifiquement pour cela.Pour ceux qui veulent voir ce que vous dit cette instructions, sur Linux, vous pouvez installer l'outil de ligne de commande
cpuidqui vous fera un beau résumé en texte clair. Bien sûr dans un programme, il n'est nullement besoin de dépendre d'un tel programme en CLI. Puisque c'est une instruction processeur, faites la requête directement depuis votre code.Dans d'autres cas, l'info pourrait venir d'autres instructions ou d'une interface kernel (apparemment c'est ce qu'on a pour la détection ARM neon), etc. Dans tous les cas, l'info est disponible. Le principe est d'avoir des fonctions de détection qu'on maintient et met à jour lorsqu'une nouvelle détection est ajoutée (ces interfaces étant normalement stables, elles ne sont jamais retirée, une fois une détection ajoutée, c'est normalement "à vie"). En fait ce n'est pas grave de manquer un type de détection. Dans ce cas, le code se repliera juste sur l'implémentation générique jusqu'au jour où quelqu'un qui s'y connaît ou fait quelques recherches ajoute la détection nécessaire. C'est comme ça que fonctionne le logiciel libre communautaire (par ajout incrémental de nouveaux contributeurs). C'est OK même si on aurait pu utiliser une implémentation plus rapide plus tôt.
Tu parles de chargement dynamique à l'exécution? Parce que si tu parles de ce qu'on appelle habituellement du linking, c'est à la construction (juste après la compilation), ce n'est pas quelque chose qui se fait à l'exécution. Si tu fais des choix à cette étape là, alors ton binaire n'a plus toutes les capacités possibles et ne fonctionne plus partout.
Au contraire, ce que je dis, c'est qu'à la compilation/linking, tu inclus tout ce que ton compilateur permet (sans te préoccuper de la cible, ou plutôt des multiples cibles qu'aura ton binaire), et c'est à l'exécution que tu fais les choix de quoi exécuter.
Si tu parles de chargement dynamique, du type tu as une bibliothèque avec les implémentations génériques, une bibliothèque avec implémentations SSE2, etc. Puis tu choisis quelle version charger à l'exécution. Oui c'est possible et certains projets font un peu ainsi, mais ce n'est nullement obligatoire. Tu peux simplement tout embarquer dans le même binaire, et tu fais les choix de quelle branche de code exécuter selon la détection des capacités du hardware au moment de l'exécution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]