IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SL & STL C++ Discussion :

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


Sujet :

SL & STL C++

  1. #21
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2009
    Messages : 68
    Points : 56
    Points
    56
    Par défaut
    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.

  2. #22
    Membre confirmé

    Inscrit en
    août 2007
    Messages
    300
    Détails du profil
    Informations forums :
    Inscription : août 2007
    Messages : 300
    Points : 520
    Points
    520
    Par défaut
    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.
    "Maybe C++0x will inspire people to write tutorials emphasizing simple use, rather than just papers showing off cleverness." - Bjarne Stroustrup
    "Modern C++11 is not your daddy’s C++" - Herb Sutter

  3. #23
    Membre régulier Avatar de MenshaKaine
    Inscrit en
    juin 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Âge : 45

    Informations forums :
    Inscription : juin 2009
    Messages : 68
    Points : 79
    Points
    79
    Par défaut
    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.

  4. #24
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 918
    Points : 1 921
    Points
    1 921
    Par défaut
    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

  5. #25
    Membre régulier Avatar de MenshaKaine
    Inscrit en
    juin 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Âge : 45

    Informations forums :
    Inscription : juin 2009
    Messages : 68
    Points : 79
    Points
    79
    Par défaut
    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.

Discussions similaires

  1. Le langage Java est-il adapté pour les jeux vidéo ?
    Par Invité dans le forum Développement 2D, 3D et Jeux
    Réponses: 637
    Dernier message: 05/02/2021, 23h38
  2. Réponses: 44
    Dernier message: 21/01/2009, 11h34
  3. [Joomla!] un CMS est-il adapté pour mon site?
    Par welcominh dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 2
    Dernier message: 11/04/2008, 23h33
  4. Ma configue est-elle suffisante pour Eclipse 3.3 ?
    Par Pierre8r dans le forum Eclipse Java
    Réponses: 5
    Dernier message: 29/07/2007, 20h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo