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 ?
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.
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...
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.
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.
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.
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é.
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.
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.
0 |
0 |
[Fork suite à cette discussion : Matrice de booleen ]