Non, ça c'est pour tout code. Une boucle Fortran sera plus rapide que sa version C++ sans restrict.Citation:
Envoyé par metagoto
Version imprimable
Non, ça c'est pour tout code. Une boucle Fortran sera plus rapide que sa version C++ sans restrict.Citation:
Envoyé par metagoto
Effectivement, mais la boucle fortran-like est tout de même réalisée en C++. Le code est vieux, probablement plus vraiment representatif (je n'ai pas essayé d'augmenter les nombre de loops)
Il n'empeche que je le trouve interessant. Sur une machine actuelle, ça montre quand même que l'indirection (abstraction) des iterateurs STL-like est negligeable dans le cadre d'un bench datant des années 90. Après je suis d'accord que dans les faits, ça ne prend pas en compte les vrais usages de la STL.
Je crois me souvenir d'ailleurs d'un papier (ou présentation) de Stepanov qui montrait des benchs en faveur de la STL. C'est probablement quelque part sur son site.
Pour la question de l'optimisation, STL par sa conception propose des moyens aussi pour l'améliorer si l'optimisation déjà existante n'est pas suffisante :)Citation:
Envoyé par fcharton
On sait que l'allocation et deallocation de mémoire constituent un overhead non négligeable surtout si on manipule de gros conteneurs et il y a pas mal de resize et de liberation.
Et la STL se caractérise par un autre point très fort qui est la "Cohesion Forte", ou chaque classe a sa propre responsabilité et il n y a pas de classe passe partout qui fait beaucoup de choses a la fois.
et parmi ces classes qui ciblent une fonctionnalité donnée on trouve les allocators qui est spécialisé juste a l'allocation mémoire.
déjà la version par défaut des allocators sont très optimisés mais on peut faire nos propres allocators adaptés a un contexte donné pour être plus rapide.
et c'est la qu'on découvre qu'une librairie très bien conçu est en général très flexible et s'adapte a nos besoins et pas l'inverse qui est le cas d'autres librairies ou nous sommes obligés de s'adapter avec elles :)
et je pense que le couplage faible et la cohésion forte sont deux principes de bases très puissants qui nous donnent un résultat finale en général très satisfaisant.
Généralement les gens qui se plaignent que le C++ c'est compliqué à maintenir etc. ce sont des gens qui travaillent avec du code plein de pointeurs qui font des spaghetti.
Dans du beau C++, les pointeurs, y'en a pas. Il n'y a pas de spaghetti tout simplement parce qu'il y a quasiment pas d'aliasing, tout est lié à la portée.
Je suis tout à fait d'accord. Ma seule réserve sur la STL porte sur les conteneurs, et le fait qu'ils font énormément de copie. Ca peut être évité (et ca le pourra encore plus avec la move semantics), mais ça permet quand même un peu trop au novice de produire du mauvais code.Citation:
Envoyé par Issam_Lahlali
Pour le reste, ce que je conteste c'est cette idée (qu'on trouve dans pas mal de livres) qu'utiliser la STL, et en particulier ses algorithmes améliore la vitesse d'exécution du code produit, en permettant au compilateur de mieux optimiser.
En général, utiliser la STL ne va pas pénaliser, un bon algorithme STL ira plus vite qu'un mauvais algorithme fait main (et inversement, on pourra toujours trouver de meilleures solutions adaptées à des cas précis), le code STL, pour ce que j'ai pu en lire, est solide, bien écrit, efficace, mais il n'est pas "magique", et il se compile en un code exécutable aussi rapide qu'un code fait main correct.
Francois
tout a fait d'accord d'ailleurs ce que tu viens d'évoquer je le considère faisant parti de la "Micro Optimisation" et en général c'est pas la ou on cherche a optimiser le premier.Citation:
Envoyé par fcharton
gagner qlq micro de secondes pour la logique d'un foreach et perdre des minutes dans un calcul ça ne sert a rien :)
mais avec STL je sais que si j'ai besoin d'optimiser plus j'ai des points d'injections, et heureusement c'est pas une librairie fermé ou je ne peux rien changer au niveau comportement.
..Et perdre 3 quarts d'heure à parser du XML, effectivement, ça ne vaut pas le coup :lol:Citation:
Envoyé par Issam_Lahlali
Et c'est vrai du coup que la notion de move semantic et la minimisation du coût des creations/destructions des temporaires va apporter du sang neuf à la STL et ailleurs. J'espère juste que ce qui a été proposé (donc en fait ce qui découle des rvalue references) ne sera pas finalement mis de coté. Car il y a quand même des problèmes très sérieux quand à l'exception-safety et les garanties des containers.
ce probléme est parmi les bêtes noires pour les débutants :)Citation:
Envoyé par loufoque
et pour cette technique qui fait appel aux scopes c'est effectivement la meilleur solution a faire même si dans des cas on essaye de faire autrement pour des raisons d'optimisation d'utilisation de mémoire , c'est le cas de l'api APR utilisé par apache ou on a une technique de pool ou chaque allocation se fait dans un pool donnée et chaque pool peut avoir un parent et des fils, c'est finalement très proche de la technique de scope , excepté que pour la technique du scope la libération est automatique mais avec cette technique de pool la libération se déclenche manuellement, et dans ce cas on ne souci pas de la libération de chaque pointeur aussi c'est fait lorsqu'on libère le pool.
donc on peut faire en sorte de réutiliser une allocation qui est candidate a la libération on la réinitialisant donc on gagne en temps d'allocation.
tu m'a eu :)Citation:
Envoyé par metagoto
mais concrètement je travaille sur un projet ou je parse des Mo de XML d'une manière très très rapide , et l'astuce est d'éviter de travailler avec le DOM mais j'utilise XMLTextReader une classe de dotnet en plus qui n'est pas aussi optimisé que C++.
mais en parlant du sujet il faut éviter l'optimisation prématuré dans nos choix de conception comme a dit Donald Knuth:
micro-optimizations are worth it while premature optimizations are the root of evil
Il est évident que par rapport à du code écrit attentivement par quelqu'un connaissant bien le langage, on n'ira pas plus vite...Citation:
Envoyé par fcharton
Mais par rapport à du code tout venant, écrit sans précautions particulières, on ira souvent plus vite avec la STL qu'à la main. Sans faire particulièrement attention, on a par exemple un vector à croissance géométrique, un remove_if en O(n) (le genre de chose que je suis incapable d'avoir dans une collection .NET). Ce n'est pas si évident à avoir avec du code casual écrit à la va-vite. Donc, dans un contexte pratique, la STL peut être plus rapide que du code hors STL.
Dans adobe.ASL ils ont un parseur ~SAX qui travaille avec des vues. Les chaines ne sont jamais copiées, à la place il ont un type chaine qui va pointer dans un buffer de caractères.Citation:
Envoyé par Issam_Lahlali
Ca reste du SAX like.
PS: XML ca reste de la premature pessimisation.
C'est la principale force de la STL. Elle garantit des algorithmes corrects.Citation:
Envoyé par JolyLoic
En même temps, elle n'est pas non plus protégée des erreurs de débutants. Comme les conteneurs copient beaucoup, une utilisation simpliste (notamment des string non passés par référence) va beaucoup ralentir le code. Egalement, il faut un peu de culture générale algorithmiques (c'est assez rare par les temps qui courent) pour l'utiliser correctement. Sinon, on produit du code tout aussi lent (par exemple, en abusant des tris, en ne triant pas avec le bon algo, en se trompant de conteneur, ou en cherchant mal).
C'est le paradoxe de la STL, ce n'est pas une librairie de débutant, et elle sert surtout à des gens qui sauraient écrire les différents algos qu'elle contient... Personnellement, même si j'ai adoré Accelerated C++, j'ai des doutes sur une approche d'enseignement du C++ qui présente trop la STL comme la "solution à tous les problèmes". Mal utilisée, je pense qu'elle fait autant de dégats que pas de librairies du tout.
Francois
Je ne pense pas qu'elle soit orientée autodidactes (dans le mauvais sens du terme, celui qui se lance sans rien apprendre, en refusant d'apprendre, uniquement par essai erreur), en effet.
Par contre, pour des débutants bien guidés, elle me semble faire des merveilles. En terme de justesse, on évite plein d'erreurs (bien qu'on puisse faire du code non optimal mais c'est de second ordre, surtout pour des débutants). Et elle permet de faire rapidement, dès la première heure de cours, des programmes qui ont du sens.
Et pour des non débutants, elle permet d'écrire du code correct et raisonnablement rapide même un jour de petite forme.
Et pour info, il y a eu une expérience sur un vrai programme très utilisateur de chaînes où passer les chaînes par valeur a eu un effet positif notable sur les perfs par rapport à un passage par référence, et ce à la grande surprise de l'expérimentateur, pourtant un expert en C++. L'effet a été attribué à moins d'alisaing, qui permettait de meilleures optimisations du compilo.
Les copies et les const&, il n'y a pas que les débutants qui les oublient. Ce sont toutes les personnes à qui on n'a pas dit que ça existait (on retombe sur l'enseignement de la matière).Citation:
Envoyé par fcharton
Et contrairement à ce que tu dis, comme il y a dans la STL les complexité des algorithmes, c'est moins facile de se tromper et de prendre le mauvais, si tant est qu'on ait pris le temps de réfléchir. Sans la STL, on prend un algorithme au hasard, on se plante 100 fois en l'écrivant (débutant inside), et à la fin, on se retrouve avec une complexité défavorable, alors qu'en prenant les outils du langage, on a directement un code qui marche avec une compelxité connue.
Tu exagères, car elle est tout de même éprouvée, alors que le code d'un débutant pour faire la même chose est largement moins stable et buggé.Citation:
Envoyé par fcharton
Bien dit !Citation:
Envoyé par fcharton
Il ne faut surtout pas présenter la STL comme le couteau suisse du C++. Cela a été mon erreur avec des collègues qui ne connaissait pas la STL ( :roll: ) et qui intriguer par mes std:: m'ont demander de leur montrer les bases de la lib. J'ai du depuis les mettre fortement en garde quand je me suis aperçu que les containers, par exemple, utilisés à tord et à travers avaient pousser comme des champignons dans le code (notamment des structures imbriquées du style map<string, set <vector <int> > > :calim2: )
C'est très bien , mais est ce qu'il y a des outils pour faciliter le développement, a l'époque ou j'ai découvert XUL il y quelques années j'étais fasciné par cette techno mais le manque d'outil a fait qu'il était non productif et finalement délaissé.Citation:
Envoyé par Luc Hermitte
PS: il faut faire une pétition sur ce site pour enlever XML du standard,je pense qu'on aura pas mal de signatures :)
Il y a deux aspects différents. En tant que librairie de code prêt à l'emploi, la STL est formidable, parce qu'elle couvre un champ assez large. Elle permet donc d'aller vite (en termes de temps de développement ou d'apprentissage), et d'éviter des mises au point complexes (dans les algos, ce sont souvent les détails qui tuent).Citation:
Envoyé par JolyLoic
En tant que vitesse du code produit (c'est mon point principal), la STL n'est pas une solution magique. Un bon algorithme mal utilisé sera tout aussi lent qu'un mauvais. C'est à mon avis la difficulté réelle. La STL propose des algorithmes de base, et pour bien l'utiliser, il faut une solide culture.
@matthieu : Publier des complexités garanties n'aide qu'un tout petit peu. Pour donner un exemple, dans le domaine du tri, quicksort, heapsort et leurs dérivés sont "officiellement" plus efficaces qu'insert sort, qu'il faut pourtant leur préférer dans les (très nombreux) cas ou un fichier est presque trié. Si les données à trier contiennent beaucoup d'ex aequos, alors la stratégie change encore, et ainsi de suite... Sur le papier, une map cherche aussi vite qu'un vecteur trié, dans la réalité, le vecteur trié va nettement plus vite, tant qu'on n'ajoute pas d'élément...
Pour rattacher ça à la discussion, la STL est une librairie finalement assez élitiste, car elle présuppose que l'utilisateur sait un peu de mathématiques, et là encore, le niveau ne monte pas, par les temps qui courent...
Oui, et de régler très vite des problèmes qu'on ne résout qu'une fois.Citation:
Envoyé par JolyLoic
Pour m'être intéressé à ces questions, c'est extrèmement compliqué... L'idée "référence=bien valeurs=mal" qu'on voit parfois est souvent prise en défaut, il y a aussi des cas (nombreux) ou les pénalisations liées aux copies de structures sont négligeables par les accélérations qu'elles permettent en simplifiant les algorithmes.Citation:
Envoyé par JolyLoic
Tôt ou tard, si on veut du code rapide, il faut faire des mesures, avec un profileur, et on est presque toujours surpris par les résultats qu'on obtient.
Francois
Là, on voit clairement un problème de conception où les développeurs ont développé avant de réfléchir !Citation:
Envoyé par befalimpertinent
tout a fait d'accord, dans les projets réels on se retrouve avec un code énorme ou trouver les goulots d'étranglement reste impossible sans profiler.Citation:
Envoyé par fcharton
et finalement même si on utilise STL , s'il y a juste une erreur de choix de conteneur par exemple ça peut être fatal pour l'optimisation.
l'avantage de STL c'est qu'elle donne les moyens pour avoir un code optimisé,si on sait s'en servir c'est très bien , on peut avoir une clarté et une rapidité du code donc joindre l'utile a l'agréable :)
et les joindre Clarté et rapidité c'est très délicat comme exercice, en général un code optimisé comporte des pointeurs et des pointeurs de pointeurs et autre complexité et ça devient rapidement un casse tête.
mais si effectivement on ne connait pas bien ses mécanismes et surtout on a ce prejugement que STL a la clé magique pour optimiser , ça sera une catastrophe.
et puisque actuellement c'est plus les débutants qui code , s'il n y pas un encadrement et surtout un audit régulier du code , on aura ni clarté ni rapidité avec STL :)
finalement STL nous donnent les moyens d'être clair et rapide a condition bien sur de connaitre ces mécanismes.
Quand je pense que nombreux sont les développeurs qui ne savent même pas ce qu'un débuggeur est. Alors un profileur :|Citation:
Envoyé par fcharton