Envoyé par
mewtow
Sinon, en général, je pense pouvoir m'autoriser à penser qu'il soit possible que les développeurs actuels ne pensent pas à optimiser leur code.
Tu ne devrais pas... La plupart des développeurs regardent les performances de leur code, et cherchent à l'améliorer *quand c'est nécessaire*, sinon il n'y a pas grand chose qui tournerait, même sur des ordinateurs modernes, compte tenu de l'explosion des volumes de données gérés (même par des programmes assez basiques).
Envoyé par
mewtow
C'est une des seules explications que j'aie pour expliquer la
Loi de Wirth, avec l’essor de la programmation orientée objet et des implémentations de langages basées sur de la compilation JIT
A mon avis, ce n'est pas la bonne... une fois de plus, il faudrait chercher du côté des volumes d'information traités, du nombre de programmes tournant concurremment.
La programmation orienté objet c'est aussi une forme d'optimisation: celle des temps de développements et des couts de maintenance évolutive. Et ce n'est pas forcément plus lent que le procédural.
Envoyé par
mewtow
-> La "croyance" que l'optimisation prend tu temps, nuit à la maintenance ou la lisibilité, etc.
C'est pourtant vrai... Optimiser du code demande des tests, du développement supplémentaire, et se traduit souvent par des algorithmes plus compliqués que les 'basiques' qu'on a fait au début (sinon on n'optimiserait pas).
Envoyé par
mewtow
-> La croyance que " early optimisation is evil ", inculquée de force dans les écoles d'informatique,
C'est vrai et faux... L'un des principaux pourvoyeurs de cette croyance est Knuth, qui n'est pas exactement un mauvais programmeur (ni un moderne). Je crois que la façon dont il faut comprendre l'adage est que l'on ne peut optimiser qu'une procédure que quand on en a compris le fonctionnement et les limites. En général, quand on commence à développer, on se fait une idée fausse des difficultés, des blocages, des volumes à traiter, des temps nécessaires. En optimisant trop tôt, on a de grandes chances de s'attaquer au mauvais problème, et de compliquer gratuitement le code sans pour autant l'accélérer.
Envoyé par
mewtow
pousse à utiliser des profilers et autres outils de benchmarking qui font pire que mieux et donnent des chiffres totalement biaisés
C'est jeter le bébé avec l'eau du bain... L'objet d'un profileur, ce n'est
presque jamais de te donner des chiffres justes, sur le nombre de cycles, d'accès au cache, ou chaipaquoi, mais de te donner une vision correcte des endroits de ton code ou le temps est perdu... Un profileur, ca compte des appels, des accès, et des durées à la louche. Les mesures de temps précises, c'est juste le marketing.
En revanche, optimiser sans profileur? tu fais quoi? tu mesures des temps d'exécution avec ton i-phone, et tu mets les nombres d'appels dans des variables locales?
Envoyé par
mewtow
-> L'usage actuel qui est fait des complexités algorithmiques, qui pousse à passer sous le tapis les constantes multiplicatives.
Euh? Un calcul de complexité donne toujours les constantes multiplicatives. Maintenant, elles n'interviennent qu'au second ordre. Le premier objectif de l'analyse de complexité, c'est de savoir comment un algorithme résiste à l'augmentation des volumes de données. Entre un linéaire et un logarithmique, il y aura rarement photo, pareil entre un linéaire et un quadratique.
Envoyé par
mewtow
-> Le fait que les programmeurs lambdas ne savent pas optimiser convenablement. Qui connait le concept de Cache oblivious Algorithm dans l'assemblée ? Qui sait comment optimiser un programme de manière à améliorer sa localité ? Pire : de nos jours, qui sait ce qu'est une mémoire cache ?
Personne sauf toi, bien sur... Sérieusement, ce type d'optimisation 'machine' est généralement laissée au compilateur. Optimiser correctement, quand on est programmeur, la plupart du temps, c'est s'intéresser à l'algorithmique et à la mémoire utilisée. C'est là qu'on gagne les ordres de grandeur, quelle que soit l'architecture...
Maintenant, je pense que la principale raison pour laquelle il y a pas mal de code non optimisé tient au fait que l'optimisation, ça demande pas de l'expérience, du recul et du temps. Dans la vraie vie, ça manque, pas qu'en informatique, d'ailleurs.
Ca demande aussi un bon bagage scientifique (des maths, plutôt qu'une connaissance des architectures machines, si tu veux mon avis...)
Francois
8 |
0 |