Discussion :

[ElPedro]

Bonjour,

question originale :
La STL est-elle adaptée pour du code critique en termes de performance ?

En ce qui concerne l'argument selon lequel les différents compilateurs fournissent des versions différentes, je pense que ce n'est pas un bon argument : STLport est justement faite pour corriger cela.


Sinon du point de vu général :
A/
Si les performances sont déjà suffisantes, pourquoi pas?
B/
Il est souvent facile d'écrire des conteneurs plus performants que la STL en terme de performance (c'est d'ailleurs assez déroutant). Pour cela, il ne faut cependant de ne pas reposer sur les hypothèses de fonctionnement qui sont justement à la source de ses défauts. Par exemple, il est préférable d'utiliser swap() au lieu de constructeurs par recopie etc... Cependant, même si c'est facile, cela peut prendre du temps d'écrire cette solution.

Une solution meilleure encore est d'utiliser des librairies dont on sait qu'elles sont plus performantes que la STL avec une interface quasiment identique, et proposant plusieurs kernels justement pour s'adapter au besoin. Il suffit de tester la librairie dlib (et ses conteneurs) dispo sur sourceforge pour s'en convaincre.

J'ajoute que l'introduction de la move-semantic du C++11 est une manière -de mon point de vue- de chercher à corriger ce problème de la STL. C'est comme ajouter un pansement sur une blessure qu'on aurait pu éviter.

Ensuite, pour les performances, il ne faut pas négliger :
1/ les algorithmes
2/ les instructions spécifiques du processeur (sse par exemple, memcmp, ... ). Voire exécuter un shader sur GPU.
3/ l'assembleur

Cordialement,
ElPedro

EDIT : Je viens de lire le thread original. Pour des performances celui qui veut faire du traitement d'image, sera plus performant en vitesse d'exécution s'il passe par une texture + shaders sur GPU! En faisant une acquisition directe sur la carte graphique (certain drivers l'autorisent), il économisera aussi la RAM de la texture - et en perdra au niveau des librairies de contrôle du GPU qui seront chargées.

[ac_wingless]

Je travaille dans l'embarqué depuis maintenant plus de 25 ans, ce qui me classe sans aucun doute comme dinosaure pour beaucoup. Je code bien moins ces dernières années, mais en tant que dinosaure ayant grandi sous perfusion d'assembleur, on (je) me colle souvent les parties critiques des projets.
Eh bien dans mon expérience récente, c'est très rarement le code lui-même qui est déterminant sur les parties critiques. Nous avons maintenant bien plus souvent des problèmes de largeur de cache, des hoquets dus à des gestions de ressources "lentes" (<1 MHz), des problèmes de fiabilité dans les parties non logicielles (matériel + firmware), des latences non parfaitement déterministes, etc.
Ceci n'a pas toujours été le cas. Il y a une vingtaine d'années, c'était bel et bien le code et sa qualité d'optimisation qui déterminaient les performances. Il n'y avait pas de STL, et l'approche classique consistait à passer en assembleur des parties limitées. Aujourd'hui, et paradoxalement, nous ne produisons d'assembleur que pour des zones "lentes" (microcontroleurs), et encore de moins en moins: uniquement quand nous n'avons pas accès à des environnements de développement productifs en langage évolué. Quant à optimiser la STL, j'ai vraiment du mal à voir comment cela aurait pu nous aider concrètement sur nos problèmes de performances des 2-3 dernières années.

Je reconnais que ce n'est pas forcément représentatif du développement qui doit tourner entièrement à l'intérieur d'un PC: nous, nous avons la liberté d'ajouter des parties électroniques là où ça nous arrange (GPU, FPGA, bus spécifiques), donc il subsiste peu de code critique effectué sur processeur généraliste.
Néanmoins, le résultat est là: nous produisons beaucoup de code C++, nous sommes pratiquement toujours dans des systèmes à performances critiques, et nous n'allons plus bidouiller les implémentations STL. Sauf bug d'implémentation, ou grosse faute architecturale, les gains de performances que cela pourrait apporter semblent devenu vraiment peu tangibles.

Il faut tout de même mentionner qu'un problème récurrent associé dans les esprits au C++ en général et à la STL en particulier (à tord selon moi), est la non-prédictibilité de l'exécution dans les 3 domaines classiques: allocation sur le tas, appels virtuels, et exceptions. Certains projets industriels évacuent trivialement ces points en les interdisant purement et simplement, ce qui est souvent assimilé à un blocage indirect de la STL. Fort heureusement, ces problèmes sont maintenant parfaitement bien identifiés par la communauté C++ industrielle, et de nombreuses sociétés (pas seulement la notre), ont mis au point des mécanismes de mitigation. En particulier, la STL autorise le paramétrage des allocateurs (avec certaines limitations qui seront supprimées par C++11), et les appels virtuels ou les exceptions lui sont orthogonaux, donc la STL est compatible avec par exemple les diverses solutions d'exécution virtuelle à temps constant.
Donc même si l'on se place dans les cas les plus délicats de l'embarqué, pour peu qu'on n'aie pas affaire à un maitre d'œuvre ânonnant bêtement à la lettre son coding standard machin chose, on peut utiliser la STL sans souci particulier.

[MenshaKaine]

bonjour votre discutions m'intéresse beaucoup.

En effet, dans le monde industriel beaucoup de personne sont anti STL et d'autre ne jure que par ça.

de mon expérience personnel:
1- Il y a très peu de cador en C++ sur le marché capable de faire du code optimisé donc se lancer dans des arguments du type je dois faire mes composants pour être sur des performances ... ca crée du code souvent moisi ! Derriere la STL, il y a quand l'expérience de plein de développeurs ...

2- Ceux que j'ai vu ré-implémenté les conteneurs standard sont souvent ceux qui n'y comprennent pas grand chose. c'est une boite obscure pour eux. Au lieu de s'informer ou d'essayer, ils refont ... et souvent justifie ce travail sur les préjugé contre la STL.

3- Il est vrai que quand j'ai eu des problèmes de performance sur des projets, c'est souvent que j'avais mal choisi mes conteneurs ou mes algorithmes.

sinon pour l'instant je n'ai utilisé que les allocateurs standards. j'ai compris que certaine personne en avait utilisé d'autres. je me demandais, quelles problématiques ont poussé à changer les allocateurs !?

cordialement.

[Joel F]

sinon pour l'instant je n'ai utilisé que les allocateurs standards. j'ai compris que certaine personne en avait utilisé d'autres. je me demandais, quelles problématiques ont poussé à changer les allocateurs !?

En vrac dans mes projets:
* gestion d'allocation mémoire aligné pour le SIMD
* allocation dans une pool externe
* pas mal d'allocateurs de convenience (genre fixed_size_allocator<T,N>, shifted_address_allocator) etc...
* allocation "SMP friendly" pour éviter false sharing etc

[MenshaKaine]

En vrac dans mes projets:
* gestion d'allocation mémoire aligné pour le SIMD
* allocation dans une pool externe
* pas mal d'allocateurs de convenience (genre fixed_size_allocator<T,N>, shifted_address_allocator) etc...
* allocation "SMP firendly" pour éviter false sharing etc

merci pour ta réponse.