Un développeur fait tenir un univers de fractales dans 4096 octets

**phc2908** · 26/05/2012, 09h53

Ce genre "d'exploit" me rappelle mon époque Atari ST (ou Amiga pour leurs nombreux fans) où on avait des développeurs assembleur monstrueux qui repoussaient en permanence les limites des machines.

Je me souviens de démos 4K aussi qui en mettaient plein la vue proportionnellement aux capacités des machines de l'époque bien sûr parce qu'en terme de processeur on était TRES loin des GHz actuels et je ne parle pas des disquettes 720K et de mes 512K de mémoire de mon 1er 520 ST.

J'avais une fois écrit un programme qui calculait et affichait une fractale basique, il fallait plusieurs minutes de calcul... quand dans une démo, le même résultat en plus joli mettait à peine 4s. Toute la différence entre l'application basique d'un algorithme et une version super optimisée.

Que de souvenirs bien lointains ^^

**Paul TOTH** · 26/05/2012, 16h52

et vous avez connu les "Deulignes" de Hebdogiciel ?

**sybil** · 26/05/2012, 17h23

genial ce truc!

**psykokarl** · 28/05/2012, 13h08

Envoyé par raimbow

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

Le prix du ou des dev n'a que peu d'importance dans le cadre d'une économie d'échelle.

Les points contre ton arguments sont:
* divises le salaire de ton dev par le nombre machines sur lesquelles seront installés le soft
* ajoutes le nombre de personne qui ne dépenseront pas 30€ pour une nouvelle barrette mémoire de RAM (dans l'hypothèse ou ça lui demande pas de tout changer voir de racheter une config).
* ajoutes le nombre de machine auquel il n'est pas possible d'ajouter de la RAM
* prendre en compte l'économie d'énergie des machines + la clim, l'impact sur le vieillissement des équipements dans le cas ou le client est interne
* la réputation d'un produit sur lequel on peut capitaliser.

Je vois que deux arguments valables:
* Le gain de temps parce que le premier arrivé premier servit. Il est plus rentable de sortir d'être le premier et sortir une daube que d'être dans les dernier et sortir un bon produit.
* Le deuxième est d'économiser sur le salaire du dev pour payer un commercial. Une daube très connue et bien packagé se vendra moins bien qu'un bon produit avec une promo austère.

En fait c'est avant tout une question de choix modèle économique...

**grafikm_fr** · 28/05/2012, 23h20

Envoyé par psykokarl

* Le gain de temps parce que le premier arrivé premier servit. Il est plus rentable de sortir d'être le premier et sortir une daube que d'être dans les dernier et sortir un bon produit.

Oui, en gros c'est ça: c'est le Time to Market qui dicte toute la structure de développement. Si tu n'arrives pas la premier sur le marché, il y a plus ou presque plus de marché. Résultat prévisible: 2000 bugs dans une release, dont 1000 sont des régressions (dans du code de haute importance qui plus est

). C'est beau

**el_slapper** · 29/05/2012, 09h53

Envoyé par grafikm_fr

Oui, en gros c'est ça: c'est le Time to Market qui dicte toute la structure de développement. Si tu n'arrives pas la premier sur le marché, il y a plus ou presque plus de marché. Résultat prévisible: 2000 bugs dans une release, dont 1000 sont des régressions (dans du code de haute importance qui plus est

). C'est beau

C'est beau, et si tu ne le fais pas, tu est mort. Steve Yegge a un peu bloggué sur l'horreur que constitue l'informatique de chez Amazon(ou il a bossé quelques années), mais si ils avaient pris le temps de faire les choses bien, personne ne connaitrait amazon, et un autre aurait pris le marché.

**MiaowZedong** · 29/05/2012, 10h09

Envoyé par el_slapper

C'est beau, et si tu ne le fais pas, tu est mort. Steve Yegge a un peu bloggué sur l'horreur que constitue l'informatique de chez Amazon(ou il a bossé quelques années), mais si ils avaient pris le temps de faire les choses bien, personne ne connaitrait amazon, et un autre aurait pris le marché.

Amazon* est un cas particulier tout de même, puisqu'ils ne vendent pas leur informatique...leurs plateformes logistiques, leurs marketeux et leurs acheteurs sont facilement aussi importants pour leur produit final.

Ce qui est plus choquant, c'est quand le logiciel est vendu buggé à mort, et eventuellement patché...s'il y a assez de clients...et que ceux-ci se plaignent assez fort...et que ça ne coute pas trop cher...

*AWS à part, mais il me semble qu'on se refèrre ici à la base de code d'Amazon.com.

**Freem** · 29/05/2012, 11h24

Moui, enfin, le "time to market" me semble plausible dans l'informatique que je qualifierais "de service". Est-ce le cas dans tous les domaines?

Je veux dire, vues les perfs de w7 et w8, il semble qu'ils aient quand même bossé sur l'optimisation (peut-être à cause de la claque vista?).

De même, je suppose que les logiciels dans les voitures et autres logiciels dont le rôle est de piloter un appareil, voire d'être responsable de chaînes de productions, ont des tests de QA. Et celui qui arrive le 1er à intérêt a arriver stable...
Bon, je sais, il s'agit de logiciel d'un genre particulier...

D'ailleurs, si on regarde un peu, j'ai l'impression (ou est-ce un simple rêve naïf?) que la performance des applis deviens un argument commercial.
Même si pour le moment, c'est limité aux simples navigateurs et OS (MS n'arrête pas d'insister lourdement sur leurs performances, voir le thread sur le démarrage trop rapide pour appuyer sur F8...), peut-être que ça va s'élargir. Peut-être un effet secondaire des tablettes? (Bon, je doute qu'on en revienne aux performances d'avant mais un minimum serait de rigueur la... quand on voit que les windows jusqu'a XP pouvaient tourner sur moins de 64Mo on se dit qu'il y a un souci quand même, non?)

Autre chose, on parle beaucoup du cloud, mais il me semble que sur le cloud, on paye la puissance que l'on consomme. Au mois. Donc si on augmente les temps de dev pour optimiser, sur le moyen terme, ces temps de dev risquent d'être amortis, non?

**MiaowZedong** · 29/05/2012, 13h27

Envoyé par Freem

De même, je suppose que les logiciels dans les voitures et autres logiciels dont le rôle est de piloter un appareil, voire d'être responsable de chaînes de productions, ont des tests de QA. Et celui qui arrive le 1er à intérêt a arriver stable...
Bon, je sais, il s'agit de logiciel d'un genre particulier...

Cas très particulier: si le logiciel "plante" la chaîne de montage et cause des dégats, il y a des dommages-intérêts et eventuellement des dommages punitifs à payer. Ne parlons même pas de ce qui arrive s'il y avait mort d'homme.

Par contre, qu'un logiciel de paie prenne une place indécente en RAM, qu'il fasse trop travailler le CPU et qu'il plante toute les demies-heures, ça n'entraine aucune poursuite légale. Et le client ne déboursera pas plus d'argent pour prendre un autre logiciel, dont il ne peut pas être plus certain que le premier tant qu'il ne l'a pas testé.

**grafikm_fr** · 29/05/2012, 17h02

Envoyé par Freem

De même, je suppose que les logiciels dans les voitures et autres logiciels dont le rôle est de piloter un appareil, voire d'être responsable de chaînes de productions, ont des tests de QA. Et celui qui arrive le 1er à intérêt a arriver stable...

Dans les télécoms en tout cas, ils n'ont pas entendu ton appel

**ManusDei** · 29/05/2012, 20h26

Envoyé par Freem

De même, je suppose que les logiciels dans les voitures et autres logiciels dont le rôle est de piloter un appareil, voire d'être responsable de chaînes de productions, ont des tests de QA. Et celui qui arrive le 1er à intérêt a arriver stable...

Dans les voitures, il y a des discussions en ce moment pour créer une norme comme celle de l'aviation (DO178). Mais pour l'instant, nada....

**LLB** · 01/06/2012, 09h34

Envoyé par valefor

Dois-je penser qu'il utilise les shaders de la CG ?

Si oui, je trouve que la performance est relativisée par le fait que la carte graphique fait beaucoup de choses... On est loin des démo assembleur de l'époque...

Bien sûr.
Un principe dans la demoscene est de chercher à tirer parti au maximum des ressources disponibles, d'utiliser la puissance de la machine autant que possible. Presque toutes les démos modernes utilisent le GPU à fond, qui offre beaucoup plus de puissance que le CPU. Si tu es nostalgique de ce qui se faisait à l'époque, sache qu'il existe encore aujourd'hui beaucoup de démos qui sont faites pour les machines "old-school". Va voir sur pouet.net
Mais surtout, ne crois que, parce que le GPU est super-puissant, il est plus simple de faire des démos aujourd'hui.

Aussi, l'autre point important de la démo est sa taille. 4ko, que l'on utilise la carte graphique ou non, ça reste 4096 octets. Petite expérience : écrit un Hello World en C, compile-le et regarde la taille de ton binaire !

Envoyé par sybil

excellent ce site, j'ai recupere quelque donnees sur cette demo:
pour compresser il a utilisé Shader Minifier: http://www.ctrl-alt-test.fr/?page_id=7 qui est specifique pour minifier du glsl ou hlsl
c'est de l'OpenGL en api C.

Etant l'auteur de Shader Minifier, je me sens obligé d'apporter des précisions.

Comme Closure Compiler et autres, c'est un compilateur qui réécrit le code source de la façon la plus compacte possible. Une différence importante ici : mon programme cherche à obtenir le code qui sera le plus petit possible après compression, c'est-à-dire qu'il renomme les fonctions et variables de sorte à créer de la redondance (s'il y a deux variables locales, dans des fonctions différentes, mais utilisées dans des contextes similaires, j'essaie de leur donner le même nom). Bref, c'est un logiciel vraiment optimisé pour une utilisation dans des démos 4k.

Envoyé par yohannc

Par contre je suis plus impressionné par le fps kkrieger, qui fait moins de 100ko, qui n'est pas si moche, avec un monde "maîtrisé", des textures réalistes, une ia (certe basique ^^), et des modèles définits. Un simple screenshot est déjà plus gros que le jeu en lui même.

Et que penses-tu de ça ?

http://www.developpez.net/forums/d12...lixs-workshop/ (démo en 64k avec des dizaines de textures, modèles 3D, etc.)

**sybil** · 03/06/2012, 09h39

Il faut pas oublier que minimiser son code doit aller de pair a le rendre plus rapide, sinon a quoi bon. ex:

ex.1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    err = allocate_foo();
        if (!err) {
                err = allocate_bar();
                if (!err) {
                        err = allocate_baz();
                        if (!err) {
                                ...
                        } else {
                                deallocate_bar();
                                deallocate_foo();
                        }
                } else
                        deallocate_foo();
        }
        return err;

ex.2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    err = allocate_foo();
        if (err)
                return err;
        err = allocate_bar();
        if (err) {
                deallocate_foo();
                return err;
        }
        err = allocate_baz();
        if (err) {
                deallocate_bar();
                deallocate_foo();
                return err;
        }

ex.3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 err = allocate_foo();
        if (err)
                goto out;
        err = allocate_bar();
        if (err)
                goto out1;
        err = allocate_baz();
        if (err)
                goto out2;
        ...

out2:
        deallocate_bar();
out1:
        deallocate_foo();
out:
        return err;

l'exemple 3 est le plus clair de lecture et le plus rapide a l'execution.

**Paul TOTH** · 03/06/2012, 11h01

Envoyé par sybil

l'exemple 3 est le plus clair de lecture et le plus rapide a l'execution.

je n'en suis pas convaincu...les goto deviennent totalement illisibles quand le label est très éloigné et à vu de nez je dirais que tes trois exemples ont des temps d'exécution similaires...tu évites juste une redondance de code qui n'affecte en rien le temps d'exécution, il est même parfois recommandé de dérouler les boucles pour rendre le code plus rapide (sauf si la boucle tient dans le cache d'instructions du CPU) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  int tab[5];
// plus lent
  for (int i = 0; i < 5; i++)
   tab[i] := i;
// plus rapide
  tab[0] = 0;
  tab[1] = 1;
  tab[2] = 2;
  tab[3] = 3;
  tab[4] = 4;
}

**MiaowZedong** · 03/06/2012, 11h18

Normalement, un bon compilateur optimisant rend inutile l'utilisation du Goto dans les sources pour la performance, le compilateur se chargeant de placer des Goto là où c'est pertinent dans le code machine.

N'oublions pas que le code machine executé n'est pas forcement le même que le code source écrit, et qu'une optimisation pour un language/compilateur peut être inutile, voire contre-productive pour un autre language/compilateur.

À titre d'exemple, dans certains language la recursion est à fuir comme la peste car elle peut entrainer un dépassement mémoire. Dans d'autres, une recursion peut être infinie sans prendre un octet de plus....

**Paul TOTH** · 03/06/2012, 12h30

Envoyé par MiaowZedong

Normalement, un bon compilateur optimisant rend inutile l'utilisation du Goto dans les sources pour la performance, le compilateur se chargeant de placer des Goto là où c'est pertinent dans le code machine.

N'oublions pas que le code machine executé n'est pas forcement le même que le code source écrit, et qu'une optimisation pour un language/compilateur peut être inutile, voire contre-productive pour un autre language/compilateur.

À titre d'exemple, dans certains language la recursion est à fuir comme la peste car elle peut entrainer un dépassement mémoire. Dans d'autres, une recursion peut être infinie sans prendre un octet de plus....

quel langage permet la récursivité infinie ?!

**MiaowZedong** · 03/06/2012, 13h21

Envoyé par Paul TOTH

quel langage permet la récursivité infinie ?!

La plupart des languages fonctionnels; il n'y a pas d'application que je sache, mais c'est théoriquement possible.

E.g.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
(defun (useless foo)
  (useless (- foo 1) )

Bon, ce n'est pas vraiment infini parce que tu finis par avoir un int overflow. PAr contre, le coût en memoire et en place dans le stack est constant si la recursion est proprement gérée.

Par contre, la même chose en C te crée une nouvelle addresse sur le stack à chaque appel, donc stack overflow rapide. Edit: sauf si ton compilateur réécrit la fonction pour que ce soit une boucle (un while(true) par exemple).

**LLB** · 03/06/2012, 13h54

Envoyé par Paul TOTH

quel langage permet la récursivité infinie ?!

La plupart des langages avec un compilateur correct (tail call optimization - l'appel de fonction peut être remplacé par un simple jump dans certains cas). C'est le cas de tous les compilos C et C++ que je connais par exemple. MiaowZedong : sur ce point, il n'y a pas de vraie différence entre les langages fonctionnels et les autres (si ce n'est qu'on s'en sert plus souvent en Lisp qu'en C).

Il faut pas oublier que minimiser son code doit aller de pair a le rendre plus rapide, sinon a quoi bon.

On parlait de démos en 4k ici. Les développeurs cherchent à réduire la taille du code (après compilation et compression), quitte à perdre en performance, quitte à utiliser un algo plus lent. Dans les démos en 64k, c'est très différent : il y a la place de coder les algos optimaux. Ton exemple est très mauvais : il ne donne d'amélioration notable ni en lisibilité, ni en taille de code, ni en performance (il faudrait utiliser un profiler pour le vérifier).
Quant à dérouler une boucle, il vaut mieux laisser le compilateur le faire (sauf éventuellement après profiling, si on a déterminé que c'était important). Le compilateur sait souvent mieux que le développeur si ça vaut le coup ou non.