Oui tout à fait. Y a plusieurs commentaires un peu étranges qui semblent impliquer qu'on doit faire un choix: soit utiliser de nouvelles instructions (ou autres nouvelles API qui ne sont disponibles que sur certains hardwares) soit rester rétro-compatible avec le vieux matos. C'est un très mauvais, et surtout faux, choix! On peut tout à fait rester compatible avec le vieux matos tout en utilisant les possibilités du nouveau matos quand il est disponible.
On a du code comme ça dans GIMP (en particulier dans babl et GEGL, nos moteurs de conversions de couleur et de traitement d'image par graphe). Ensuite idéalement pour des binaires génériques, on veut que la machine qui compile soit moderne et ait ainsi le plus de prise en charge d'extension possible. Ainsi oui, à la compilation, on doit pouvoir compiler les variantes du code (en plus du code générique) pour SSE*, AVX*, etc. Ensuite on livre les mêmes binaires sur toutes les machines (bon on sépare bien sûr les différentes platformes comme tout le monde, mais je me souviens de projets de gens qui faisaient des fat binary qui peuvent être exécutés sur divers OS ou architectures très différentes! Souvent cela reste surtout du "proof of concept" pour le fun... mais ça reste possible en théorie si on voulait vraiment cela) et le dispatch se fait à l'exécution.
Si c'était pas possible, ce serait assez nul comme situation. On serait obligés d'aller vers le plus petit dénominateur commun ou de retirer la prise en charge de vieilles-pas-si-vieilles machines (une forme d'obsolescence programmée).
Je pense que la bonne pratique est simplement:
Oui, bien sûr qu'il faut faire un code générique et le plus portable possible d'abord; comme ça, ça tourne partout (on ne créé pas un logiciel qui ne marche que sur du matos moderne).
Ensuite bien sûr qu'avoir des implémentations alternatives faisant bon usage d'extensions modernes est une bonne idée. Ces dernières ne remplacent pas l'implémentation générique. Il faut simplement un code qui choisissent quoi exécuter à l'exécution.
Il faut compiler idéalement cela sur un CPU moderne pour avoir toutes les implémentations embarquées dans le binaire.
j'imagine qu'il y a le même genre de choses pour OpenGL (selon la version disponible)
Ce type de logique est effectivement similaire pour plein de choses, pas seulement les instructions CPU. Par exemple dans GIMP, on a des variantes OpenCL de pas mal de filtres pour faire usage des GPUS (bon on l'avait désactivé par défaut à un moment à cause d'instabilités mais on a eu un récent project GSoC qui a retravaillé dessus et on a espoir de pouvoir reproposer OpenCL par défaut). C'est bien entendu aussi un dispatch à l'exécution.
Quand on y pense, même les choses comme X11/Wayland, c'est pareil. Les binaires Linux récents embarquent du code pour les 2 systèmes d'affichage, et quel branche est prise est décidé à l'exécution.
Je n'ai jamais touché du code OpenGL, mais je vois pas pourquoi cela pourrait pas être choisi à l'exécution.
Le problème principal de ces choix d’ingéniérie sont:
De plus gros binaires;
Une complexification du code.
Pour le second point, si le code est bien organisé, dans les faits, je trouve que ce n'est pas un problème. C'est pas comme si on devait mélanger tous ces codes au même endroit (t'auras pas du code SSE2 ou assembleur au milieu de ton algo générique en C). Ainsi si certains développeurs ne sont pas à l'aise avec les jeux d'instructions particuliers, ils n'ont même jamais à voir le code spécifique. Garder le code spécifique ne gêne en rien le code générique. C'est donc un non-problème à mon avis.
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é à 6.
Oui tout à fait. Y a plusieurs commentaires un peu étranges qui semblent impliquer qu'on doit faire un choix: soit utiliser de nouvelles instructions (ou autres nouvelles API qui ne sont disponibles que sur certains hardwares) soit rester rétro-compatible avec le vieux matos. C'est un très mauvais, et surtout faux, choix! On peut tout à fait rester compatible avec le vieux matos tout en utilisant les possibilités du nouveau matos quand il est disponible.
On a du code comme ça dans GIMP (en particulier dans babl et GEGL, nos moteurs de conversions de couleur et de traitement d'image par graphe). Ensuite idéalement pour des binaires génériques, on veut que la machine qui compile soit moderne et ait ainsi le plus de prise en charge d'extension possible. Ainsi oui, à la compilation, on doit pouvoir compiler les variantes du code (en plus du code générique) pour SSE*, AVX*, etc. Ensuite on livre les mêmes binaires sur toutes les machines (bon on sépare bien sûr les différentes platformes comme tout le monde, mais je me souviens de projets de gens qui faisaient des fat binary qui peuvent être exécutés sur divers OS ou architectures très différentes! Souvent cela reste surtout du "proof of concept" pour le fun... mais ça reste possible en théorie si on voulait vraiment cela) et le dispatch se fait à l'exécution.
Si c'était pas possible, ce serait assez nul comme situation. On serait obligés d'aller vers le plus petit dénominateur commun ou de retirer la prise en charge de vieilles-pas-si-vieilles machines (une forme d'obsolescence programmée).
Je pense que la bonne pratique est simplement:
Ce type de logique est effectivement similaire pour plein de choses, pas seulement les instructions CPU. Par exemple dans GIMP, on a des variantes OpenCL de pas mal de filtres pour faire usage des GPUS (bon on l'avait désactivé par défaut à un moment à cause d'instabilités mais on a eu un récent project GSoC qui a retravaillé dessus et on a espoir de pouvoir reproposer OpenCL par défaut). C'est bien entendu aussi un dispatch à l'exécution.
Quand on y pense, même les choses comme X11/Wayland, c'est pareil. Les binaires Linux récents embarquent du code pour les 2 systèmes d'affichage, et quel branche est prise est décidé à l'exécution.
Je n'ai jamais touché du code OpenGL, mais je vois pas pourquoi cela pourrait pas être choisi à l'exécution.
Le problème principal de ces choix d’ingéniérie sont:
Pour le second point, si le code est bien organisé, dans les faits, je trouve que ce n'est pas un problème. C'est pas comme si on devait mélanger tous ces codes au même endroit (t'auras pas du code SSE2 ou assembleur au milieu de ton algo générique en C). Ainsi si certains développeurs ne sont pas à l'aise avec les jeux d'instructions particuliers, ils n'ont même jamais à voir le code spécifique. Garder le code spécifique ne gêne en rien le code générique. C'est donc un non-problème à mon avis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]