Discussion :

[Gordon Fowler]

Un développeur fait tenir un univers de fractales dans 4096 octets
Se donne-t-on encore suffisamment la peine d'optimiser les codes ?


A force de voir des effets spéciaux à plusieurs millions de dollars, on en oublierait presque que la vraie performance, celle qui suscite l’enthousiasme, réside aussi dans la capacité de faire plus avec moins. Beaucoup moins.

C’est une des leçons que nous rappelle un développeur qui vient de réaliser un véritable exploit en faisant tenir un monde de fractale dans un fichier de… 4096 octets.

Réalisé dans le cadre du concours Assembly 2012 (qu’il a gagné), le résultat est une scène baptisée Hartverdrahtet tout simplement hallucinante (à regarder en HD et en plein écran bien sûr).

Son auteur, Akronyme Analogiker, a passé deux mois à développer et surtout à optimiser le code avec des outils comme le compresseur Shade Minifier.

En visionnant cette démo, un ami a d'ailleurs eu une réflexion intéressante sur cette partie du travail. Pour lui, l'augmentation des capacités du hardware ferait que de plus en plus de développeurs ne se donneraient plus vraiment la peine d'optimiser leurs codes. « Du coup les programmes deviennent proportionnellement plus lents qu'avant ».

Quoiqu’il en soit, ces « 4k » de Hartverdrahtet prouvent que certains s’en préoccupent encore et illustrent à merveille cet adage anglo-saxon : « less is more ».

Source : Page du projet

Et vous ?

Que pensez-vous de cette démo d’un univers de fractales dans un fichier de 4k ?

Les développeurs se donnent-ils encore la peine d'optimiser leur code ?

[GLDavid]

Magnifique travail !
Et un gros +1000 à son pote qui dit que le matériel nous rend fainéant et crade !
Je me souviens d'une démo que j'avais fait où je montrais un de mes programmes Java écrivant des propriétés physico-chimiques dans un fichier. Le programme n'occupe pas plus de 5Mo de mémoire. Une question était: "Quel est l'intérêt de n'occuper que 5Mo alors que tu as plein de mémoire?"

@++

[Exentius]

J'ai eu la même en correction d'examen.
J'ai mis un petit bout de code pour éviter d'instancier dans une collection un objet plutot que d'instancier ce même objet avec ses attributs en null si certaines conditions en théories vérifiées dans le constructeur étaient mauvaises.
Le prof m'a dit "C'est pas la peine de faire ce genre d'optimisations, avec le prix de la mémoire actuellement...."
Et pourtant j'ai de l'estime pour lui sur ce qu'il pense d'Apple et Facebook...

[MiaowZedong]

J'ai eu la même en correction d'examen.
J'ai mis un petit bout de code pour éviter d'instancier dans une collection un objet plutot que d'instancier ce même objet avec ses attributs en null si certaines conditions en théories vérifiées dans le constructeur étaient mauvaises.
Le prof m'a dit "C'est pas la peine de faire ce genre d'optimisations, avec le prix de la mémoire actuellement...."
Et pourtant j'ai de l'estime pour lui sur ce qu'il pense d'Apple et Facebook...

Il a raison: pour une entreprise, aucun intérêt sauf pour quelques cas particuliers.

Par contre, pour l'utilisateur, la question serait plutôt "quel intérêt a avoir des ordinateurs dernier cri si ça rame autant qu'il y a cinq ans?"

[ManusDei]

Une question était: "Quel est l'intérêt de n'occuper que 5Mo alors que tu as plein de mémoire?"

Si tu avais 500Mo disponibles, et que tu as passé X heures à optimiser ton code pour prendre uniquement 5Mo, effectivement, quel intérêt ? (en dehors de l'intérêt académique)

Ensuite si tu prévoyais de faire tourner ça sur un FPGA à terme, là l'intérêt est tout à fait compréhensible

[Invité]

Je serais curieux de connaitre le code de son application. J'ai testé sur mon ordinateur "Hartverdrahtet_Final_HQ_16to9_1920x1080_8xSS.exe", et il y a tout qui a planté

C'est impressionnant quand même

[GLDavid]

Si tu avais 500Mo disponibles, et que tu as passé X heures à optimiser ton code pour prendre uniquement 5Mo, effectivement, quel intérêt ? (en dehors de l'intérêt académique)

Ensuite si tu prévoyais de faire tourner ça sur un FPGA à terme, là l'intérêt est tout à fait compréhensible

Disons que je consomme 5Mo pour un projet à exporter. Maintenant, j'ai plus de 40 projet à exporter. Tu avoueras que ne consommer que 5Mo par projet, c'est quand même bien plus profitable sur un serveur qui doit déjà gérer d'autres applications. Si en plus, l'export dure moins de 10 minutes (interrogations de bases de données, organisations des données, checks, écriture), moins je consomme et mieux je me porte (ouais, ça se voit que je fais un régime ?)

En terme de temps, ce programme a été fait en 1j/homme.

@++

[ManusDei]

...

J'avoue

[sybil]

ça ne fonctionne qu'avec des cartes graphiques "assez" modernes.

[Freem]

Je n'ai pas regardé le programme, mais à ceux qui veulent voir le code, amha, le source est livré avec, aux noms de variables près: il suffit d'un désassembleur

Pour en revenir à la question de l'optimisation, ce que je me souviens de mon BTS, ce sont des profs qui encouragent l'utilisation du type int en C et en C++.
Y compris parfois pour de simples flag.

"Au prix ou est la ram..." qu'ils disaient.
Si on cogite un tant soit peu, un int (dans cet exemple) pose d'autres problèmes que la RAM:
_ place sur le disque dur de l'exe selon les options de compilation
_ combien d'écart en temps processeur comparé à un unsigned char?

Le tout multiplié par n collections de plusieurs milliers d'éléments, je pense que ça se sent.
Et ce, y compris sur un serveur (surtout?) parce que sur un serveur les ressources sont quand même plus critiques.

Ca, c'est pour du C, du code bas niveau. Maintenant, l'optimisation, c'est aussi sur des langages de plus haut niveau, comme les *SQL.
Et lorsqu'il y a des jointures inutiles ou des requêtes non optimisées, ça peut donner des trucs assez impressionnant. De l'ordre d'utiliser 5 minutes pour une requête équivalente qui donne son résultat en moins d'1s.

Négligeable l'optimisation?
Ca dépend la situation, mais on nous enseigne que ça ne sert à rien, "le client peut racheter une bécanne". Je n'en suis pas si sûr, moi. D'autant que la plupart des optimisations que l'on peut faire ne nécessitent pas d'aller dans l'assembleur.
Par exemple en C++ utiliser des références pour les types non natifs ne prends pas forcément beaucoup de temps, mais on gagne à chaque fois au moins 2 appels:
_ constructeur de copie (pour créer un objet temporaire)
_ destruction (de l'objet temporaire)
Et ça n'a aucun impact sur la lisibilité du programme.

Mais bon, longue vie aux constructeurs.
Sérieusement, quand je vois des jeux du genre breakout qui ne peuvent même pas tourner sur un netbook récent (de moins d'un an) alors que des FPS y fonctionnent (même sans carte graphique, même s'ils sont vieux et pas excessivement beaux), je pense qu'on peut se poser des questions.
D'autant qu'a l'ère ou l'on parle de réutiliser le code le plus possible, un code réutilité qui est optimité, ça veut dire qu'on optimise tous les programmes qui en dépendent.

[Invité]

Pour cette démo, pas grand chose à dire si ce n'est que c'est très connu que ce genre de démos est une vraie mine d'or pour obtenir des programmes aussi petits. Ah et au fait : on ne peut pas battre l'ASM en terme de code size, peut importe l’intérêt que ça peut avoir (ah si, l'embarqué...). Pour du code "normal" (hors embarqué), diminuer la code size sert franchement à rien, tellement le gain est marginal.

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. 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 (heureusement que nos CPU sont de vrais brainiac, ça aide pour exécuter du code Java).

Quand au pourquoi de cette non-optimisation par les programmeurs...

-> La croyance en ce soit-disant progrès technologique qui ferait en sorte que nos processeurs deviennent de plus en plus puissants avec le temps alors que les augmentations de performances dues au hardware deviennent de plus en plus marginales sur les PC x86. Le tout colporté par des ignares en architecture des ordinateurs qui croient que la loi de Moore est synonyme d’augmentation de performance et qui ne connaissent pas la Loi d'Amdhal généralisée et son corolaire sur les rendements décroissants), ou la notion de Memory Wall ?

-> La "croyance" que l'optimisation prend tu temps, nuit à la maintenance ou la lisibilité, etc. J'ai l'impression que c'est vrai pour les micro-optimisations obsolètes qui jouaient sur le cout des opérations, mais les optimisations algorithmiques et/ou de la localité (ou autres tout aussi efficaces) qui foutent en l'air la lisibilité ou la maintenabilité ne m'ont pas l'air d'être si nombreuses que cela. Mais je peux me tromper.

-> La croyance que " early optimisation is evil ", inculquée de force dans les écoles d'informatique, qui pousse à utiliser des profilers et autres outils de benchmarking qui font pire que mieux et donnent des chiffres totalement biaisés. Changez de PC et vous aurez des résultats totalement différents en fonction de l'organisation du sous-système de cache, et vos soi-disant optimisations prouvées à grand cout de profilers auront des effets pires que le mal. Et il parait qu'en plus, il y a pas mal de biais dans ces profilers : il y a des trucs dits dessus dans les manuels d'optimisation d'Agner Fog (qui déconseille les profilers)), et vous aurez plus de renseignements là dedans : http://www.parleys.com/#st=5&id=2103&sl=15, dans les références données vers la fin de la vidéo.

-> L'usage actuel qui est fait des complexités algorithmiques, qui pousse à passer sous le tapis les constantes multiplicatives. Sans compter que compter des opérations arithmétiques à l'heure où certaines applications passent 50% du temps d’exécution d'un code est passé dans les caches miss (et encore, c'est pour des applications scientifique, optimisées comme il faut pour la localité), et 15 à 35 % dans les miss prédiction de branchement... Bon, OK, l'effet doit être très faible, j'admets.

-> 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 ?
Je parie qu'une majorité de programmeur ne connait rien au fonctionnement d'un ordinateur moderne et a oublié ses cours d'architecture des ordinateurs qu'on lui a donné dans sa formation de base.
Ça va être joli quand il faudra passer aux processeurs multicœurs !

-> La paresse ? Pourquoi optimiser alors qu'on peut s'en passer ? A ce rythme là, je me demande pourquoi je perds du temps à indenter mon code, vu le nombre fois que mon code sera relu comparé au nombre de fois qu'il sera exécuté !

[laerne]

-> La croyance en ce soit-disant progrès technologique qui ferait en sorte que nos processeurs deviennent de plus en plus puissants avec le temps alors que les augmentations de performances dues au hardware deviennent de plus en plus marginales sur les PC x86. Le tout colporté par des ignares en architecture des ordinateurs qui croient que la loi de Moore est synonyme d’augmentation de performance et qui ne connaissent pas la Loi d'Amdhal généralisée et son corolaire sur les rendements décroissants), ou la notion de Memory Wall ?

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

Bonjour. Je ne suis pas programmeur de formation, mais j'ais suivi une sous-filière... Où l'on a pas expliqué cette histoire de Memory wall ? Ni de Cache oblivious Algorithm ? As-tu/Auriez-vous des références vers ces principes (francais ou english).

Pour l'instant je m'en tiens à coder une "tile array" et à l'adapter pour un binary tree, afin d'éviter les "cache misses".

Merci.

[Invité]

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

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.

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

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

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?

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

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

[alex_vino]

Super résultat
Bravo a cet "artiste".

[raimbow]

Je ne suis pas tellement d'accord avec la conclusion. Les développeurs passent moins de temps à optimiser et se "repose" sur les performances bien plus élevés du hardware MAIS ça permet au final d'être plus productif puisque l'optimisation qui prend du temps ne rajoute pas de fonctionnalité, donc si en peu s'en passer ça dégage du temps pour autre chose comme ajouter plus de fonctionnalités.

Aujourd'hui, pourquoi passer des jours (disons 5 jours * 8h * 30€/h = 1200€) à faire un programme qui consommerais par exemple 20% de mémoire en plus alors qu'une barrette de RAM de 4Go c'est 30€ ?

En plus, l'optimisation rajoute souvent des niveaux de complexités qui peuvent rendre la maintenance sur le long terme plus difficile.

Je suis pour l'optimisation, mais seulement lorsque c'est vraiment nécessaire (cf. la loi de Pareto) et je ne pense pas que c'est forcement de la fainéantise que de ne pas systématiquement optimiser mais plutôt du bon sens.

[Hizin]

Aujourd'hui, pourquoi passer des jours (disons 5 jours * 8h * 30€/h = 1200€) à faire un programme qui consommerais par exemple 20% de mémoire en plus alors qu'une barrette de RAM de 4Go c'est 30€ ?

Peut-être parce que ce programme n'est pas le seul à tourner sur la machine hôte ?
Peut-être parce que SI chacun des logiciels fait ça, il faut avoir 12 Go de RAM alors que 1.5 Go aurait été nécessaire ? (caricature)
Peut-être parce que c'est encore important, pas forcément allez dans le tweaking intégral, mais au moins de faire un minimum attention (j'ai une pensée pour les smartphone là) ?

[raimbow]

Peut-être parce que ce programme n'est pas le seul à tourner sur la machine hôte ?
Peut-être parce que SI chacun des logiciels fait ça, il faut avoir 12 Go de RAM alors que 1.5 Go aurait été nécessaire ? (caricature)
Peut-être parce que c'est encore important, pas forcément allez dans le tweaking intégral, mais au moins de faire un minimum attention (j'ai une pensée pour les smartphone là) ?

12Go RAM ça coûte toujours moins chère que deux jours de développement. Mais oui, c'est pas une raison pour coder comme un porc on est d'accord.

Personnellement j'optimise la plupart du temps en suivant à peu près la loi de Pareto (moins de 20% du code) et seulement une fois le programme terminé quand je peux analyser en situation réel (ou presque) les points qui sont vraiment gourmand. ça me semble être un bon compromis entre perte de temps et gain d'efficacité.

[guidav]

Au-delà du prix de la mémoire, la course avec la concurrence peut compter énormément.
Mieux vaut sortir un système qui marche bien avec 1Go de RAM 6 mois avant son concurrent que le même système, avec les mêmes fonctionnalités, super optimisé et qui tourne sur un 286SX 6 mois après.

Néanmoins, travail magnifique !

[Mat.M]

.

Aujourd'hui, pourquoi passer des jours (disons 5 jours * 8h * 30€/h = 1200€) à faire un programme qui consommerais par exemple 20% de mémoire en plus alors qu'une barrette de RAM de 4Go c'est 30€ ?

En plus, l'optimisation rajoute souvent des niveaux de complexités qui peuvent rendre la maintenance sur le long terme plus difficile.
.

et si tu développes pour de l'embarqué ??
Tu as déjà entendu parler d'un microcontrolleur ?
Un système informatique/technologique c'est pas forcément et pas seulement un PC avec 8 Go de RAM ,le Framework .NET 4 point zéro et VS2010 qui bouffent pas mal de ressources.

[Bousk]

et si tu développes pour de l'embarqué ??
Tu as déjà entendu parler d'un microcontrolleur ?
Un système informatique/technologique c'est pas forcément et pas seulement un PC avec 8 Go de RAM ,le Framework .NET 4 point zéro et VS2010 qui bouffent pas mal de ressources.

Si tu développes pour de l'embarqué tu as d'autres contraintes.
Mais ce n'est pas le développement le plus visé. Le développeur moyen développera pour PC/Linux, et les contraintes de l'embarqué il n'en a cure.
C'est pour ça qu'en embarqué on retrouve principalement (uniquement ?) du C et C++. On verra rarement du Java et une JVM.