Discussion :

[Joel F]

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.

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.

[Mac LAK]

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.

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.

[Joel F]

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.

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.

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

[Mac LAK]

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.

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.

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.

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.

[Joel F]

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.

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

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

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.

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.

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

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" ?

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.

[JolyLoic]

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.

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

[Mac LAK]

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 ?

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.

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

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.

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.

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

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.

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.

[Invité]

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

[Joel F]

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.