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

[Fork suite à cette discussion : Matrice de booleen ]

Citation:

---

Envoyé par Joel F

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.

Citation:

---

Envoyé par Mac LAK

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.

---

bitset::operator[] ne fait rien d'aure qu'un masquage de bit chez genre tout le monde ... Et encore une fois, moi avant de faire un truc chiant à la main, je le fait avec l'outil sur étagère et je bench et j'avise. Pas l'inverse.

Citation:

---

Envoyé par Mac LAK

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.

---

On perd surtout du temps. On n'est plus en 1650, les compilos et les machine sont évoilués et à part pour de l'embarqué exotique, ne pas utilisez la STL pour des trucs si simples que bitset c'est vraiment aimer perdre son temps.

Citation:

---

Envoyé par Joel F

bitset::operator[] ne fait rien d'aure qu'un masquage de bit chez genre tout le monde ... Et encore une fois, moi avant de faire un truc chiant à la main, je le fait avec l'outil sur étagère et je bench et j'avise. Pas l'inverse.

---

Question d'expérience... J'ai souvent plus perdu de temps à vouloir "tester" la STL qu'à faire le code optimisé dès le départ, du moins quand je sais à l'avance que c'est un point critique du code.

Le problème du bench, c'est que pour pouvoir le faire, il faut avoir deux éléments à comparer, donc avoir écrit les deux. A force, tu sais à l'avance qu'un code optimisé battra systématiquement le code STL, donc la seule question à se poser est "est-ce du code situé dans un chemin critique ?". Si oui, spécifique direct. Si non, STL. On gagne du temps, ainsi.

Citation:

---

Envoyé par Joel F

On perd surtout du temps. On n'est plus en 1650, les compilos et les machine sont évoilués et à part pour de l'embarqué exotique, ne pas utilisez la STL pour des trucs si simples que bitset c'est vraiment aimer perdre son temps.

---

Le matériel a certes (en partie) évolué... Du coup, les clients lui en demandent encore plus. Au final, j'ai exactement les mêmes contraintes avec un Core2 Duo embarqué qu'avec, il y a dix ans, un µC 16 bits. La seule chose qui a vraiment changé, c'est que le nombre de lignes de code du projet a été multiplié par mille. Sur le débarqué, c'est un peu la même chose, les clients en ont un peu marre des applications qui finissent par être "exclusives" tellement elles bouffent de ressources : on doit donc également veiller à ne pas utiliser n'importe quoi n'importe où.

Jusqu'à présent, à chaque fois que j'ai vu/mis de la STL dans un code critique, j'ai dû le casser peu de temps après pour raisons d'optimisation. Sans parler des différences d'implémentations entre les diverses STL que je suis amené à utiliser : on a par exemple définitivement banni le "std::set" de nos codes, car son comportement n'est pas le même sur plusieurs plate-formes. Les compilateurs embarqués ne sont pas toujours très respectueux des normes et des standards.

Encore une fois, question d'expérience... Je réserve la STL aux éléments non-critiques (perfs peu importantes, donc, ou initialisation) ou aux tests de faisabilité (code "jetable", donc pas question d'y perdre trop de temps). Si l'on commence à flirter avec le temps réel, ou à être en plein dedans, tu finis par savoir à l'avance - avant même de coder ! - que certaines pratiques sont "mauvaises", ou plutôt, non-optimales. Il ne te reste qu'à savoir si cela a de l'importance ou pas.

Citation:

---

Envoyé par Mac LAK

Question d'expérience... J'ai souvent plus perdu de temps à vouloir "tester" la STL qu'à faire le code optimisé dès le départ, du moins quand je sais à l'avance que c'est un point critique du code.

Le problème du bench, c'est que pour pouvoir le faire, il faut avoir deux éléments à comparer, donc avoir écrit les deux. A force, tu sais à l'avance qu'un code optimisé battra systématiquement le code STL, donc la seule question à se poser est "est-ce du code situé dans un chemin critique ?". Si oui, spécifique direct. Si non, STL. On gagne du temps, ainsi.

---

Pour moi c'est de la premature optimsiation.

Citation:

---

Envoyé par Mac LAK

Le matériel a certes (en partie) évolué... Du coup, les clients lui en demandent encore plus. Au final, j'ai exactement les mêmes contraintes avec un Core2 Duo embarqué qu'avec, il y a dix ans, un µC 16 bits. La seule chose qui a vraiment changé, c'est que le nombre de lignes de code du projet a été multiplié par mille. Sur le débarqué, c'est un peu la même chose, les clients en ont un peu marre des applications qui finissent par être "exclusives" tellement elles bouffent de ressources : on doit donc également veiller à ne pas utiliser n'importe quoi n'importe où.

---

Je fais de l'embarqué et j'ai de la STL dans mes codes, j'ai jamais tué personnes. LE vrai probleme de la STL c'est la qualité de ses stratégies d'allocations mémoires. Une fois que tu te donnes le jeu d'allocator adapté à ta cible, ca passe sans peine.

Citation:

---

Envoyé par Mac LAK

Encore une fois, question d'expérience... Je réserve la STL aux éléments non-critiques (perfs peu importantes, donc, ou initialisation) ou aux tests de faisabilité (code "jetable", donc pas question d'y perdre trop de temps). Si l'on commence à flirter avec le temps réel, ou à être en plein dedans, tu finis par savoir à l'avance - avant même de coder ! - que certaines pratiques sont "mauvaises", ou plutôt, non-optimales. Il ne te reste qu'à savoir si cela a de l'importance ou pas.

---

Je dis pas d'en mettre partout. Juste que, proner le pas de STL dans des cas génériques, c'est fort de café. Dans le cas présent, je vois pas pourquoi j'irais conseiller au PO de réécrire ses macros de masquages moches ou tout le monde se trompe au moins 10 fois alors que l'existant est correct.

PS: pour les prochains posts, pas la peine d'écrire "experience" en italique. J'en ai aussi ;)

Citation:

---

Envoyé par Mac LAK

Sur le débarqué, c'est un peu la même chose, les clients en ont un peu marre des applications qui finissent par être "exclusives" tellement elles bouffent de ressources : on doit donc également veiller à ne pas utiliser n'importe quoi n'importe où.

---

Sur des programmes poste de travail "classiques", le principal point critique, c'est qu'on a généralement une suite bureautique dernier cri sur des postes d'il y a 4 ou 5 ans... En situation normale (traitement de texte, plus tableur, plus mails ouverts), on consomme déjà presque tout la mémoire disponible...

Alors ça page, et là...

Mon expérience, c'est que sur un poste classique de "chargé d'étude" (dans mon secteur, ils sont un peu mieux lotis que la moyenne), une appli métier qui consomme 50 Mo passe confortablement, une appli qui en consomme 100 passe généralement, au delà de 200, on prend de gros risques (parce que notre appli métier, généralement, ne vit pas seule). Pour un utilitaire, faut diviser par 10. Et cette taille mémoire disponible n'a guère évolué sur les 5 dernières années (la faute aux frameworks gourmands et managés)...

La prendre en compte au début du développement, ce n'est pas de l'optimisation prématurée, il faudra le faire de toutes façons.

Francois

Citation:

---

Envoyé par fcharton

La prendre en compte au début du développement, ce n'est pas de l'optimisation prématurée, il faudra le faire de toutes façons.

---

Je pense que c'est une problèmatique différente. Et oui c'est à prendre en compte. Mais dire que la STL non car "c'ets pas rapide", dans le vide, c'est inopportun.

Citation:

---

Envoyé par Joel F

Pour moi c'est de la premature optimsiation.

---

Je voudrais bien, dans ce cas, que tu m'expliques comment tu vas bencher ton truc sans élément de comparaison... Donc, sans faire de double développement.

Pour moi, c'est plutôt le fait de devoir casser quelque chose pour l'optimiser qui est un manque flagrant de prévoyance ou d'étude. Si c'est de l'optimisation prématurée, alors la matrice de bool de l'OP était largement suffisante et il était inutile de faire quoi que ce soit d'autre.

Ensuite, il l'aurait peut-être cassée pour utiliser un bitset... Si ça ne suffit pas, on fait quoi ? On re-casse encore une fois pour passer à la méthode optimale ? ;)

L'optimisation est prématurée quand tu ne sais PAS si ce sera réellement optimisé ou pas, ou si la partie de code est probablement vouée à être remaniée plusieurs fois. Quand tu SAIS qu'une certaine implémentation est optimale, ce n'est plus de l'optimisation prématurée car cela ne coûte pas plus cher à développer de façon optimale que de façon générique. Crois-tu vraiment que j'ai mis beaucoup de temps à écrire ces deux macros C ? Cela a été quasiment plus long d'ouvrir l'aide de std::bitset, en pratique !

En fait, inutile de chercher à optimiser quoi que ce soit si l'on va par là... Au final, on fait quoi ?
Si par miracle ça marche, on a une usine à gaz lente et coûteuse en maintenance / ressources qui va coûter de nouvelles machines aux clients.
Si ça ne marche pas (notamment parce que tu n'as pas la possibilité d'upgrader le matériel), ça va finir en refonte quasi-intégrale du produit.
Pas sûr que ce soit rentable, tout ça... Ou que tu arrives à "attraper" un client plusieurs fois d'affilée.

Citation:

---

Envoyé par Joel F

Je fais de l'embarqué et j'ai de la STL dans mes codes, j'ai jamais tué personnes. LE vrai probleme de la STL c'est la qualité de ses stratégies d'allocations mémoires. Une fois que tu te donnes le jeu d'allocator adapté à ta cible, ca passe sans peine.

---

Il y a embarqué et embarqué. Moi, je bosse en temps réel exclusivement, donc une microseconde est "long", et les volumes de données échangés sont énormes.

Pour moi, le vrai problème de la STL, c'est que ça n'a de "standard" que le nom. Il y a trop de différences dans les implémentations pour que ce soit réellement fiable sur du code critique. C'est très bien dans beaucoup de cas, mais rarement lorsque l'on commence à se poser des questions sur l'occupation mémoire ou les performances maximales.

Citation:

---

Envoyé par Joel F

Je dis pas d'en mettre partout. Juste que, proner le pas de STL dans des cas génériques, c'est fort de café. Dans le cas présent, je vois pas pourquoi j'irais conseiller au PO de réécrire ses macros de masquages moches ou tout le monde se trompe au moins 10 fois alors que l'existant est correct.

---

Parce que ce n'est PAS un cas générique, c'est un cas extrêmement précis et limité. Il n'a pas demandé "comment faire des matrices génériques de booléens", il a demandé pourquoi sa matrice de booléens bouffait autant de mémoire... Pour finir par préciser qu'il s'intéressait au coût des opérations, et que cela s'applique à un flux vidéo (chose en général assez goinfre en temps CPU et ressources), et ceci pour chaque pixel. Le container va donc être accédé plusieurs MILLIONS de fois par seconde, voire dizaine de millions si c'est en haute résolution. Le moindre gain sera donc significatif : gagner 10 ns par accès, c'est gagner plus de 50 ms/s au final.

C'est donc tout SAUF du "générique", justement, c'est même très exactement ce que j'appelle du code spécifique critique.

Citation:

---

Envoyé par Joel F

PS: pour les prochains posts, pas la peine d'écrire "experience" en italique. J'en ai aussi ;)

---

Moi aussi, sauf que la mienne est massivement centrée sur l'optimisation, justement... Et quand je vois le niveau de casse engendré par une "flemme" des dévs, je peux te dire que l'on apprends très vite quelles sont les solutions "correctes", à force de voir ce que l'on pète dans le code et par quoi on le remplace.

Citation:

---

Envoyé par Mac LAK

Je voudrais bien, dans ce cas, que tu m'expliques comment tu vas bencher ton truc sans élément de comparaison... Donc, sans faire de double développement.

---

Moi en général, je code une version 1, et je vois ce que ca donne. Si c'ets bon, c'ets fait. Sinon, je regarde finement ou sont les pb et j'améliore. Et pour en revenir à la STL,je le répéte la seule chose embetante c'ets les allocateurs; oeprator[] sur tout les RandomAccessContainer mettent le meme temps qu'un [] sur un tableau quelconque. Croire le contraire c'est vivre en 1650.

Citation:

---

Envoyé par Mac LAK

Pour moi, c'est plutôt le fait de devoir casser quelque chose pour l'optimiser qui est un manque flagrant de prévoyance ou d'étude. Si c'est de l'optimisation prématurée, alors la matrice de bool de l'OP était largement suffisante et il était inutile de faire quoi que ce soit d'autre.

---

Si t'es capable en lisant une spec et un code de trouver toujours la meilleure implantation, bravo, t'es un kador, merci de nous honorer de ta présence. En général, hein, les gens, ils tatonnent ...

Citation:

---

Envoyé par Mac LAK

Ensuite, il l'aurait peut-être cassée pour utiliser un bitset... Si ça ne suffit pas, on fait quoi ? On re-casse encore une fois pour passer à la méthode optimale ? ;)

---

Oui

Citation:

---

Envoyé par Mac LAK

L'optimisation est prématurée quand tu ne sais PAS si ce sera réellement optimisé ou pas, ou si la partie de code est probablement vouée à être remaniée plusieurs fois. Quand tu SAIS qu'une certaine implémentation est optimale, ce n'est plus de l'optimisation prématurée car cela ne coûte pas plus cher à développer de façon optimale que de façon générique. Crois-tu vraiment que j'ai mis beaucoup de temps à écrire ces deux macros C ? Cela a été quasiment plus long d'ouvrir l'aide de std::bitset, en pratique !

---

Tu sais toi a priori si bitset n'utilsie pas sur une archi X sosu l'oS Z un truc quantique de l'esapce ou un intrinsic peu connu ? Moi non, donc je prends la solution étagère et j'avise.

Citation:

---

Envoyé par Mac LAK

En fait, inutile de chercher à optimiser quoi que ce soit si l'on va par là... Au final, on fait quoi ?
Si par miracle ça marche, on a une usine à gaz lente et coûteuse en maintenance / ressources qui va coûter de nouvelles machines aux clients.
Si ça ne marche pas (notamment parce que tu n'as pas la possibilité d'upgrader le matériel), ça va finir en refonte quasi-intégrale du produit.
Pas sûr que ce soit rentable, tout ça... Ou que tu arrives à "attraper" un client plusieurs fois d'affilée.

---

blablabla, sors de ton monde un peu. Y a pas que les client dans la vie :o
Désolé de faire partie des dev. qui travaillent dans un environnement de R&D.

Citation:

---

Envoyé par Mac LAK

Parce que ce n'est PAS un cas générique, c'est un cas extrêmement précis et limité. Il n'a pas demandé "comment faire des matrices génériques de booléens", il a demandé pourquoi sa matrice de booléens bouffait autant de mémoire... Pour finir par préciser qu'il s'intéressait au coût des opérations, et que cela s'applique à un flux vidéo (chose en général assez goinfre en temps CPU et ressources), et ceci pour chaque pixel. Le container va donc être accédé plusieurs MILLIONS de fois par seconde, voire dizaine de millions si c'est en haute résolution. Le moindre gain sera donc significatif : gagner 10 ns par accès, c'est gagner plus de 50 ms/s au final.

C'est donc tout SAUF du "générique", justement, c'est même très exactement ce que j'appelle du code spécifique critique.

---

Tu extrapoles sans base. Le PO aurait spécifier ces contraintes, oui ont serait partie sur du fait main (et encore, faut arreter de penser que la STL est coder avec les pieds et que les compilos sont merdiques. Ils sont meilleurs que toi dans 90% du temps).

Citation:

---

Envoyé par Mac LAK

Il y a embarqué et embarqué. Moi, je bosse en temps réel exclusivement, donc une microseconde est "long", et les volumes de données échangés sont énormes.

---

Autant mes commentaires sur "génériques" était peut etre malvenue mais le stien ne sont guères mieux. Toi, on s'en moquait en l'occurence, l'important c'etait de fournir une réponse correcte et non ubuesque au PO. Alors, si effectivement std::bitset s'etait avéré trop long, il nous l'aurait dit ... Tu serais pas du genre à ecrire de l'assembleur inline parce que "c'ets plus rapide" ?

Citation:

---

Envoyé par Mac LAK

Moi aussi, sauf que la mienne est massivement centrée sur l'optimisation, justement... Et quand je vois le niveau de casse engendré par une "flemme" des dévs, je peux te dire que l'on apprends très vite quelles sont les solutions "correctes", à force de voir ce que l'on pète dans le code et par quoi on le remplace.

---

Ouais alors, les arguments ad hominem, va falloir voir à les garder pour d'autres. Prendre les gens de haut en pensant être meilleur qu'eux, ca améne souvent des déconvenus. T'es pas le seul à faire de l'optimisation hein. Alors, soit on a une discussion saine soit moi aussi je sort mon e-penis et on mesure qui a la plus longue.

Citation:

---

Envoyé par Mac LAK

Je voudrais bien, dans ce cas, que tu m'expliques comment tu vas bencher ton truc sans élément de comparaison... Donc, sans faire de double développement.

---

En comparant entre ce qu'on obtient, et la spec. Si c'est suffisamment rapide, pas la peine d'accélérer, et pas la peine de comparer avec autre chose. C'est si ce n'est pas suffisamment rapide qu'il faut s'interroger.

Citation:

---

Envoyé par Mac LAK

Moi, je bosse en temps réel exclusivement, donc une microseconde est "long", et les volumes de données échangés sont énormes.

---

Moi, je connais quelqu'un qui bosse en temps réel exclusivement, il fait des calculs pour la météo nationale. Si le résultat arrive trop tard, sa prédiction n'a plus aucune valeur. Par contre, la microseconde, c'est minuscule pour lui...

Citation:

---

Envoyé par Joel F

Si t'es capable en lisant une spec et un code de trouver toujours la meilleure implantation, bravo, t'es un kador, merci de nous honorer de ta présence. En général, hein, les gens, ils tatonnent ...

---

Tu finis quand même par avoir quelques bases : quand tu gères une carte électronique, tu connais sa BP totale, les opérations à faire dessus, les précisions requises. Si tu sommes tout ça sur toutes les cartes gérées, tu vois ce qu'il y a comme soucis potentiels, et surtout si c'est compatible avec la puissance matérielle disponible.
Et ça, c'est au niveau spec uniquement (voire carrément en réponse à appel d'offre). Au niveau implémentation, c'est en général relativement simple : si le code est appelé depuis la boucle RT, on pousse l'optimisation au maximum, ça permettra toujours de pouvoir rajouter des fonctionnalités plus tard sans être obligé d'upgrader le matériel.

Après, c'est comme tout le monde : l'algo, lui, on le chercher et/ou on tatonne pour le trouver, et on optimise par raffinage. Mais pour implémenter des éléments "simples" lorsque tu SAIS que tu es dans une partie critique, il n'y a pas besoin d'être extra-lucide. Tu n'aurais pas l'idée de faire une attente active dans un thread de haute priorité, n'est-ce pas ? Donc, pourquoi ne comprends-tu pas que c'est exactement la même chose dans un code critique, surtout par rapport à un élément simple ?

Citation:

---

Envoyé par Joel F

Tu sais toi a priori si bitset n'utilsie pas sur une archi X sosu l'oS Z un truc quantique de l'esapce ou un intrinsic peu connu ? Moi non, donc je prends la solution étagère et j'avise.

---

Le chamanisme n'existe pas : tout ce que fait ton container STL, tu peux le refaire en éliminant l'intégralité du code "inutile" (tests superflus notamment). Et tu gagnes donc en perfs, c'est aussi simple que ça. On gagne aussi l'avantage de s'affranchir des différences d'implémentation entre les diverses STL, au passage. Là encore, cela dépend du fait d'être (ou pas) dans un chemin critique.

Citation:

---

Envoyé par Joel F

blablabla, sors de ton monde un peu. Y a pas que les client dans la vie :o
Désolé de faire partie des dev. qui travaillent dans un environnement de R&D.

---

J'ai bossé aussi en R&D, sur l'amélioration continue des produits... Devines quoi ? Je passais le plus clair de mon temps à optimiser du code... :mrgreen:
Tu as toujours un "client", ne serait-ce que celui qui te paie. Il y a quand même beaucoup plus de dévs qui ont partie liée avec des clients que de dévs en labos, il faut en rester conscient.

Citation:

---

Envoyé par Joel F

Tu extrapoles sans base. Le PO aurait spécifier ces contraintes, oui ont serait partie sur du fait main (et encore, faut arreter de penser que la STL est coder avec les pieds et que les compilos sont merdiques. Ils sont meilleurs que toi dans 90% du temps).

---

Il les a spécifiées, dans ce post.


Ensuite, le p'tit coup de gueule : où ai-je dit que la STL est "codée avec les pieds" ?? Tu nous fais une réaction épidermique parce que j'ai osé mettre en doute la Sainte STL, ou quoi ? J'ai dit (message #1) "La STL est très souvent la meilleure implémentation générique d'un algo", et j'ai bien insisté sur le mot générique pourtant. J'ai également dit que je l'utilisais dans le code non-critique ou les faisabilités, et ce que cela impliquait d'utiliser un code spécifique à la place. Plus clair, ça va être difficile.

Si je veux faire un vecteur générique (taille 0..N) d'un type quelconque "X", je ne vais certainement pas le redévelopper de A à Z, même en code critique, car effectivement il est très peu probable que j'arrive à faire mieux que std::vector.

Par contre, si je veux implémenter un vecteur de 32 booléens, vecteur dont la taille ne varie pas et le type ne change pas, donc du spécifique plein pot, un bête unsigned int et ses deux macros seront bien plus efficaces à tout point de vue, ne serait-ce que par l'économie des éléments annexes de la classe et des quelques tests de bornes inutiles.

Donc, merci de ne pas déformer mes propos, j'en ai un peu marre des gens qui trollent sur mes propos parce qu'ils n'arrivent pas à lire correctement des phrases pourtant dénuées d'ambiguïté. Fin du coup de gueule.

Citation:

---

Envoyé par Joel F

Tu serais pas du genre à ecrire de l'assembleur inline parce que "c'ets plus rapide" ?

---

Quand c'est requis uniquement. Gagner deux ou trois quantums de temps par seconde pour un truc appelé des millions de fois par seconde, moi, je n'appelle pas vraiment ça de l'optimisation inutile.

Citation:

---

Envoyé par Joel F

T'es pas le seul à faire de l'optimisation hein. Alors, soit on a une discussion saine soit moi aussi je sort mon e-penis et on mesure qui a la plus longue.

---

Je pense que c'est un problème de vocabulaire, et que l'on ne doit pas avoir la même définition du mot "optimisation"... Pour toi, une optimisation, cela semble juste être une amélioration de l'existant. Moi, c'est au sens littéral, celui du dictionnaire : c'est arriver à l'optimum. Pas juste "faire mieux". Or, c'est à force d'avoir cassé/reconstruit/benché que tu finis par savoir à l'avance qu'une solution est optimale ou pas pour un problème donné.

Citation:

---

Envoyé par JolyLoic

En comparant entre ce qu'on obtient, et la spec. Si c'est suffisamment rapide, pas la peine d'accélérer, et pas la peine de comparer avec autre chose. C'est si ce n'est pas suffisamment rapide qu'il faut s'interroger.

---

Le problème de la spec en question, c'est qu'elle est sujette à évolutions et modifications... Sortir un produit qui rentre "tout juste" dans les clous, c'est le risque de devoir tout casser à la prochaine évolution, et c'est bien trop coûteux.

Or, le produit est censé vivre une dizaine d'années au minimum, sans remplacer / upgrader le matériel MAIS en suivant les "modes" technologiques malgré tout. Il faut donc systématiquement "serrer" au maximum les timings sur les parties critiques. Les parties non-critiques, par définition, n'ont pas de réelles contraintes temporelles et on pourra toujours dire à l'utilisateur d'attendre une ou deux secondes de plus.

Citation:

---

Envoyé par Joel F

Moi, je connais quelqu'un qui bosse en temps réel exclusivement, il fait des calculs pour la météo nationale. Si le résultat arrive trop tard, sa prédiction n'a plus aucune valeur. Par contre, la microseconde, c'est minuscule pour lui...

---

Parce que l'on ne travaille pas dans le même temps réel ! ;) Certes, dans la définition générale, on peut qualifier de "temps réel" quelque chose qui pourrait mettre des heures à sortir le résultat, du moment que c'est dans les clous de l'unité de temps de mesure.

Dans mon cas, c'est que chaque milliseconde, des milliers d'entrées/sorties doivent être acquises/commandées. Rien que cette fonction (partie RT + partie réseau et contrôle/commande) carbonise 25 à 50% du temps CPU, en fonction du nombre de cartes. Et le reste doit tourner malgré tout (fonctions spécifiques, traitements annexes, etc.) par tranches finalement très fines, car cette interruption est bien entendu prioritaire sur tout le reste.

Bon, peut être je me trompe mais je vois mal en quoi la STL te serais utile quand tu gères des tableaux fixes de bits ou la récupération d'entrée et la mise à jour de sorties.

Du coup, on a l'impression que tu nous dit que la STL c'est mal dans ton cas parce que int a = 3+2 est plus optimisé. C'est surtout que la STL ne sert pas à ça. Non? enfin dis moi parce que j'ai mal compris un truc alors.

Citation:

---

Envoyé par nikko34

Bon, peut être je me trompe mais je vois mal en quoi la STL te serais utile quand tu gères des tableaux fixes de bits ou la récupération d'entrée et la mise à jour de sorties.

---

La STL en elle-même ? A rien. Par contre, ça ne change pas le fait que j'ai besoin de vecteurs, de bitfields, de listes, de piles, de FIFO, etc.
Les concepts de container en eux-mêmes conservent bien entendu toute leur utilité, ce n'est qu'un pur problème d'implémentation, pas de principe général ou d'algo.

C'est peut-être sur ce point qu'il peut y avoir confusion : ce n'est pas (par exemple) le concept de vecteur que je critique. C'est le fait de penser qu'un vecteur ne peut (doit ?) être implémenté QUE via la STL, notamment lorsque la notion de performance entre en jeu.

Citation:

---

Envoyé par nikko34

Du coup, on a l'impression que tu nous dit que la STL c'est mal dans ton cas parce que int a = 3+2 est plus optimisé. C'est surtout que la STL ne sert pas à ça. Non? enfin dis moi parce que j'ai mal compris un truc alors.

---

C'est bien ça.

Quand on ne sait PAS ce que l'on va avoir à gérer, ni quel nombre on en aura, on est typiquement dans un cas générique, où la STL est à conseiller à 100% car elle sera plus que vraisemblablement optimale. Je mets volontairement de côté le cas des STL non-compatibles, c'est un tout autre problème.
Bien entendu, le cas "bon, on en met 100 pour l'instant" via un #define qui peut être sujet à variation EST un cas générique aussi, c'est évident. Par contre, un cas "on en met 256 parce que c'est le nombre de possibilités codées par un octet" n'est pas un cas générique, car il y a peu de chances que la taille d'un octet change... Surtout si c'est une contrainte provenant d'une carte électronique ou d'un protocole ! ;)

Lorsque toutes les bornes, types, etc. sont totalement connus à l'avance, invariables et immuables, la STL n'est PAS optimale. Les algos "en dur" sont non seulement triviaux à écrire dans un tel cas, mais en plus ils sont plus performants et/ou plus économes en mémoire. La contrepartie est que SI il y a une évolution à faire dans ce code, elle sera plus complexe à réaliser qu'avec un container STL : il faut donc savoir si une des deux conditions "est-ce du code critique ?" ou "est-ce une contrainte immuable ?" est vraie. Si oui, direction code spécifique "en dur". Sinon, direction algos génériques / STL.


Après, il n'est pas interdit non plus de faire du code "en dur" sous forme d'une classe C++ statique, d'un template sans paramètres, ou autre choix d'implémentation qui ne fasse pas tâche dans le code C++ "pur RAII" qui est à côté. L'important, c'est d'être certain que le code sera correctement produit sans fioritures (VMT, indirections ou tests inutiles, inlining raté, etc.), et il se trouve simplement que les macros "C" (malgré leurs nombreux défauts) sont UN des moyens de garantir l'inlining quoi qu'il arrive.

Citation:

---

Envoyé par Mac LAK

Par contre, si je veux implémenter un vecteur de 32 booléens, vecteur dont la taille ne varie pas et le type ne change pas, donc du spécifique plein pot, un bête unsigned int et ses deux macros seront bien plus efficaces à tout point de vue, ne serait-ce que par l'économie des éléments annexes de la classe et des quelques tests de bornes inutiles.

---

sauf que bitset ne fait rien d'autre que d'implanter ça sasn tests ni rien, mais bon passons ...

Je considère que, en moyenne, tu perds moins de temps à ecrire ces choses via la STL que à la main. Si t'es payer à perdre ton temps, tant mieux pour toi. Je passe aussi sur ton laius sur l'optimum qui fait doucement rigoler. Tout comme pas comprendre ce que veux dire générique.

Vu que tu continues à faire ton Brice de Nice, je vais aller lire d'autres threads et ca m'évitera de troller plus que toi et de me prendre un ban. Dans dix secondes, j'ai l'impression que si je te dis j'ai fait des applis pour le nucléaire, tu va me sortir "ouais moi aussi".

Citation:

---

Envoyé par Joel F

sauf que bitset ne fait rien d'autre que d'implanter ça sasn tests ni rien, mais bon passons ...

---

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.

Citation:

---

Envoyé par Joel F

Je passe aussi sur ton laius sur l'optimum qui fait doucement rigoler. Tout comme pas comprendre ce que veux dire générique.

---

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...

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.

Citation:

---

Envoyé par Joel F

Vu que tu continues à faire ton Brice de Nice, je vais aller lire d'autres threads et ca m'évitera de troller plus que toi et de me prendre un ban.

---

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.

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é.

Citation:

---

Envoyé par Joel F

Dans dix secondes, j'ai l'impression que si je te dis j'ai fait des applis pour le nucléaire, tu va me sortir "ouais moi aussi".

---

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.

Citation:

---

Envoyé par Mac LAK

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

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

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

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

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

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:

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).

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.

Citation:

---

Envoyé par Alp

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

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... :roll:

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.

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.

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 ?

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:aie:). 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:ccool:.
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.

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.

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.

Citation:

---

Envoyé par MenshaKaine

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

Citation:

---

Envoyé par Joel F

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.