Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Mac LAK

0PARTAGES

0  0 
[Fork suite à cette discussion : Matrice de booleen ]
Citation Envoyé par Joel F  Voir le message
c'est deja ce que fait std::bitset si je ne m'abuse:

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.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de
https://www.developpez.com
Le 10/03/2010 à 15:30
Citation Envoyé par Mac LAK Voir le message
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
0  0 
Avatar de Joel F
Membre chevronné https://www.developpez.com
Le 10/03/2010 à 16:06
Citation Envoyé par fcharton Voir le message

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.
0  0 
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 10/03/2010 à 16:33
Citation Envoyé par Joel F Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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.
0  0 
Avatar de Joel F
Membre chevronné https://www.developpez.com
Le 10/03/2010 à 19:06
Citation Envoyé par Mac LAK Voir le message

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 Voir le message

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 Voir le message

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 Voir le message

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 Voir le message

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 Voir le message

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 Voir le message

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 Voir le message

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.
0  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 10/03/2010 à 19:13
Citation Envoyé par Mac LAK Voir le message
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 Voir le message

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...
0  0 
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 11/03/2010 à 12:57
Citation Envoyé par Joel F Voir le message
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 Voir le message
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 Voir le message
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.

Citation Envoyé par Joel F Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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.
0  0 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 11/03/2010 à 14:48
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.
0  0 
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 11/03/2010 à 15:50
Citation Envoyé par nikko34 Voir le message
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 Voir le message
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.
0  0 
Avatar de Joel F
Membre chevronné https://www.developpez.com
Le 11/03/2010 à 16:18
Citation Envoyé par Mac LAK Voir le message

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".
0  0 
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 11/03/2010 à 19:26
Citation Envoyé par Joel F Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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.
0  0