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

Le , par Mac LAK, Inactif
[Fork suite à cette discussion : Matrice de booleen ]
Citation Envoyé par Joel F  Voir le message
c'est deja ce que fait std::bitset<N> si je ne m'abuse:
<snip>
sachant que bitset::operator[] fait aussi la tambouille pour extraire le booleen compressé.

Oui, mais c'est de la STL. En fonction de l'implémentation (donc, du compilateur) et des optimisations activées, cela peut être nettement moins bon que le code "en dur". La STL est très souvent la meilleure implémentation générique d'un algo.

Mais étant génériques, par définition, ces objets possèdent du code "inutile" dans certains cas... Ce qui permet de battre en vitesse et/ou en occupation mémoire les containers STL avec des implémentations spécifiques, lorsque les besoins l'exigent.

On perd bien sûr en maintenabilité / évolutivité ce que l'on gagne en performances / consommation mémoire, c'est une évidence, mais tout dépend si l'on a besoin (ou pas !) des performances optimales.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Joel F Joel F - Membre chevronné https://www.developpez.com
le 11/03/2010 à 19:46
Citation Envoyé par Mac LAK  Voir le message
Effectivement, y'a "rien" d'autre, c'est flagrant dès que l'on ouvre <bitset> pour regarder le code, chose que tu n'as pas dû faire on dirait...
Il y a des boucles "for", des tests sur les limites, des indirections, etc. Tout va bien, donc, tu n'es pas du tout dépendant des optimisations automatiques (et donc du compilateur, souvent imposé en embarqué) et tu n'auras pas du tout un mode Debug infernalement plus lent que le mode Release.

Je répéte, TU fais des hypothèses comme quoi ces choses la sont couteuses. Je te dis que dans 98% des cas, et c'ets le cas du PO, ca l'ai. Tu érige TON cas particulier en règle.

Citation Envoyé par Mac LAK  Voir le message
Que veux-tu, chacun ses jeux... Confondre "améliorer" et "optimiser" me fait moi aussi rire, mais qu'y faire ? Comme ne pas comprendre, pour un féru de C++, ce qui est générique et ce qui ne l'est pas, ou ce qu'est un code critique et ce qui ne l'est pas. Pour ma part, quand j'utilise le mot "générique", le mot "génération de code" n'est pas très loin. Du code "en dur", qui n'a quasiment pas besoin du moindre paramètre, je ne vois pas vraiment ce que ça a de générique...

Et ouias, que veux tu, je doit etre trop bête et les gens avec qui je bosse aussi ... Je te conseilelrais donc de jeter un oeil à la page generic-programming.org et/ou à lire le "Element of Programming" et tu verras ce que a peu pres tout le monde entend quant on parle de programmation générique. Mais peut etre que Douglas Gregor et Alex Stepanov sont juste des branquignoles. Et c'est toi qui parle de "en dur" depuis le debut, pas moi :o

Citation Envoyé par Mac LAK  Voir le message
Nous n'avons manifestement pas le même vocabulaire, donc on va s'arrêter là. Tu fais de la recherche ? Super, c'est nécessaire aussi. Moi, je fais tourner des éléments réels, concrets et utilisés quotidiennement, et apparemment, nos deux mondes n'ont pas d'intersection à ce qu'il semble. Toi, tu as peut-être la latitude d'upgrader le matériel ? Ou d'en mettre à volonté ? Moi, c'est très exactement ce qui m'est totalement interdit, tu vois... Je dois faire avec l'existant, coûte que coûte, et crois-moi que c'est le plus souvent calculé au plus juste, notamment sur les produits de série.

Ouais, enfin, faudrais aussi arreter que croire que la recherche en info c'est des barbus dignes des Navigateurs de la Guilde dans Dune :o Ici on fait tourner des véhicules autonomes, des drones et on pond du code pour des gens qui font des missiles. Tu veux une news, zut, on a mis de la STL partout. Je check mon oreillette non personne n'en est mort.

Citation Envoyé par Mac LAK  Voir le message
Le troll, c'est d'éluder soigneusement tout ce qui dérange pour ne partir que sur de la polémique et/ou des attaques personnelles, ou encore de lire ce que l'on a envie de lire et non pas ce qui est écrit, et c'est ce que tu fais allègrement depuis le début.

Evidemment. :smiley à violon:

Citation Envoyé par Mac LAK  Voir le message
Je t'ai par exemple demandé explicitement où j'avais bien pu dire que la STL était "codée avec les pieds", car c'est quand même un peu ce que tu me reproches, et j'attends toujours la réponse... A la place, j'ai eu droit à une attaque personnelle ! Si ce n'est pas du troll, c'est vachement bien imité.

C'est que tu dit implicitement quant tu parles du fait que "ouasi tout ça, on fini toujours par la reecrire en dur de toute façon".

Citation Envoyé par Mac LAK  Voir le message
Non, pas de nucléaire à mon actif, "juste" des systèmes SIL2/SIL4 (et autres normes strictes), du militaire et de l'industriel. Des avions, des trains, des bateaux et des voitures.

J'etais pas loin quoi :smiley a moustache:
Avatar de nikko34 nikko34 - Membre éprouvé https://www.developpez.com
le 11/03/2010 à 21:00
A noter dans le nouveau livre de Bjarne Stroustrup, ya un long chapitre sur l'utilisation du C++ en milieu industriel (un des exemples sur lesquel il a travaillé est si je me souviens bien en rapport avec la motorisation de (gros) bateaux).
Avatar de Alp Alp - Expert éminent sénior https://www.developpez.com
le 12/03/2010 à 2:01
Mac_Lak, reconnais au moins que tu troll pour agrémenter tes arguments. J'ai travailler sur des laps de temps très serrés sur du temps réel plusieurs fois (dont une fois du nucléaire), et je n'ai pas eu à réécrire des composants de bibliothèques. Alors si vraiment la STL ne convenait pas dans ta situation c'est que soit tu avais choisi le mauvais composant pour ta situation (vector pour un tableau de taille fixe par exemple ? là c'est plus du ressort de std::array / []), soit tu as été dans les 0.000001% de développeurs C++ qui n'ont vraiment vraiment vraiment aucun autre choix que d'écrire le code sans aucune chose en plus. Mais là personnellement j'hésite 4 fois avant d'envoyer le code, alors que je peux bien plus facilement garantir la sureté si je n'ai pas développé des trucs crades.

Bref, stop le troll, c'est rigolo 5 minutes. Comme le dis Joel, n'étends pas *TON* cas, qui constitue 0.000001% des développeurs C++ maximum, à tout le monde. A part peut-être dans un soft où t'as une microseconde pour réagir, ce qui a été conseillé par Joel est très bien. Je connais bien des développeurs C++ qui ont fait de l'embarqué et/ou temps réel avec des contraintes de temps de réponse très très très serrée, et qui s'en sortaient, sans réécrire leurs conteneurs ou quoi.
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 12/03/2010 à 15:23
Citation Envoyé par Alp  Voir le message
Mais là personnellement j'hésite 4 fois avant d'envoyer le code, alors que je peux bien plus facilement garantir la sureté si je n'ai pas développé des trucs crades.

Ne confonds pas le code critique (d'un point de vue performance) et le code sûr (en sûreté de fonctionnement), ou encore le code normé. Les normes les plus strictes (SdF) que j'ai pu voir te feraient pleurer, vu que ça commence en interdisant strictement les pointeurs, les passages par référence ou les allocations dynamiques : mal barré pour du C++ RAII, n'est-ce pas ?

Essaie également de ne pas oublier que tous les compilateurs ne sont pas égaux, n'ont pas les mêmes niveaux d'optimisation, ou possèdent des STL incompatibles, buggées ou défectives : et là, le code crade, c'est celui qui utilise la STL, justement.

Quand tu travailles dans un environnement multi-plateformes, tu es bien obligé de tenir compte de ces contraintes d'implémentation et, donc, d'optimisation. Le même code doit par exemple tourner sur un CPU à 400 MHz datant d'un bon moment, ET sur un Core2 2 GHz, et le tout sans exploser le premier bien sûr, merci les périodes de garantie de dix ans et plus. Mais faut faire des produits, des garanties et du récurrent pour comprendre ça, et pas juste des projets one-shot sur lesquels ça n'a effectivement que rarement de l'importance.

Quand tu es sur un code critique (donc forcément coûteux à revalider), et qu'une librairie tierce peut poser des problèmes de perfs ou, pire, être une cause de bugs, t'apprends vite à éjecter ladite librairie de tes portions de code critique. Et cela n'empêche pas de l'utiliser ailleurs pour autant.

Citation Envoyé par Alp  Voir le message
Comme le dis Joel, n'étends pas *TON* cas, qui constitue 0.000001% des développeurs C++ maximum, à tout le monde. A part peut-être dans un soft où t'as une microseconde pour réagir, ce qui a été conseillé par Joel est très bien. Je connais bien des développeurs C++ qui ont fait de l'embarqué et/ou temps réel avec des contraintes de temps de réponse très très très serrée, et qui s'en sortaient, sans réécrire leurs conteneurs ou quoi.

J'aime bien le pourcentage... J'ai eu les mêmes choses rigolotes avec quelqu'un qui prétendait que l'informatique industrielle représentait 1% du marché de l'informatique. Mais bon, passons. Sûr que l'optimisation, personne n'en a besoin, hein ? On peut toujours racheter une machine plus puissante, c'est ça ? Et après, on se demande pourquoi le logiciel a aussi mauvaise réputation dans l'industrie...

Tu as temps réel et temps réel, pour commencer. La plupart des jeux sont "temps réel" pour un humain sans l'être au niveau MACHINE, ce que l'on appelle aussi parfois le "temps réel mou". Moi, je suis en temps réel "dur", donc effectivement, les temps de réaction SONT de l'ordre de la microseconde. Voire en dessous si l'on commence à jouer avec des hybrides CPU/FPGA.

Si, pour toi, faire du RT c'est juste pousser la priorité des threads, utiliser du matos avec plein de buffers pour les lire de façon asynchrone et que tu n'as jamais eu besoin de lire une datasheet, OK, c'est très bien. Pour moi, c'est déjà du temps réel "mou", donc pas du "vrai" temps réel.
Le temps réel dur, c'est lorsque l'on fabrique le matos plein de buffers sur lequel on se repose, justement, et on est même souvent synchrones. C'est du code bas (ou même très bas) niveau.

J'ai également l'impression que personne ici n'a compris que l'immense majorité du code que j'écris est du C++ parfaitement classique, et que seule une petite portion est écrite "en dur". Cette portion critique est la seule à être RT et avec du code en dur, tout le reste est de l'applicatif "normal".

Je pourrais également te rétorquer que si toi tu as le choix de tes compilateurs, plate-formes matérielles et tout et tout pour pouvoir faire ce que tu veux comme tu veux, alors tu fais partie de 0.000001% des dévs. Les autres doivent faire avec ce qu'ils ont à disposition, savoir quand optimiser lourdement sans demander à changer le matos et/ou les outils, et assurer des garanties.

Pour la réponse à "La STL est-elle adaptée pour du code critique en termes de performance ?", la réponse est "non" si c'est du spécifique, car dans ce cas on arrive toujours à faire mieux soit en perfs, soit en footprint, soit les deux. Point.
Avatar de TropMDR TropMDR - Membre éprouvé https://www.developpez.com
le 13/03/2010 à 17:06
Il y a peut être une autre question à poser: tout le temps passé à réinventer la roue n'aurait-il pas pu être investi pour optimiser (allez, améliorer, puisqu'on ne peut soit disant pas parler d'optimisation avant d'atteindre un prétendu optimum indéfinissable...), donc pour améliorer d'autres partie du code ? Se poser des questions plus fondamentales sur le choix de l'algorithme par exemple ?

Parce que passer d'une STL utilisées moulte fois par de nombreux utilisateurs à un code "maison", pour atteindre la même confiance dans le code, il en faut du temps, des tests, etc. Et pendant ce temps, le fameux client, il attend son code.
Avatar de Luc Hermitte Luc Hermitte - Expert éminent https://www.developpez.com
le 14/03/2010 à 3:53
Question bête: S'il y a des implémentations de la SL qui sont de bonne qualité (au hasard, je dirais dinkumware que je vois proposer des trucs pour eC++), pourquoi ne pas investir pour acheter la licence plutôt que de payer des h.m à développer & maintenir l'équivalent ?

Question de quelqu'un qui ne bosse pas sur des plateformes exotiques: Pour ce qui est des mauvais compilos, n'est-il pas possible d'utiliser gcc à la place ? N'est-il pas présent partout maintenant ? Ou alors est-ce lui le mauvais compilo ?
Avatar de ElPedro ElPedro - Membre du Club https://www.developpez.com
le 14/03/2010 à 23:36
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.
Avatar de ac_wingless ac_wingless - Membre confirmé https://www.developpez.com
le 16/03/2010 à 14:29
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.
Avatar de MenshaKaine MenshaKaine - Membre régulier https://www.developpez.com
le 24/03/2010 à 9:39
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.
Avatar de Joel F Joel F - Membre chevronné https://www.developpez.com
le 24/03/2010 à 10:50
Citation Envoyé par MenshaKaine  Voir le message
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
Avatar de MenshaKaine MenshaKaine - Membre régulier https://www.developpez.com
le 25/03/2010 à 8:58
Citation Envoyé par Joel F  Voir le message
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.
Offres d'emploi IT
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C++