Optimisation vitesse - Page 2

Au fait Kevin, regarde le titre du topic

Bas on n'auras pas finit de le dire, pour les fonctions de ce genre je suis pour aussi car même une petite optimisation vitesse et à prendre.

sBibi :
"En tout cas, pour ExtGraph, je suis contre cette "optimisation": ça rajoute 4 octets et ça consomme un registre de plus, donc ce n'est pas une optimisation."
bah moi je suis pour... c bete hein?

Mais ce n'est pas toi qui décides.
Pour le moment, c'est XDanger (qui est lui aussi contre cette "optimisation", cf. message n°19), et à l'intégration dans TIGCCLIB, Sebastian et moi (et Zeljko s'il a le temps), nous aurons aussi notre mot à dire.

Sebastian et Zeljko je sais pas, mais toi tu n'as jamais rien compris aux impératifs de la programation graphique

la se trouve toute la subtilite kevin

Kevin> je ne fais cette optimisation que si j'ai un registre libre. Donc ça prend 4 octets en plus, oui.

Et ben, moi, je trouve ça idiot de gaspiller 4 octets pour une différence de même pas un cycle.

Dans une boucle répétée h fois, x2 si nvg.
Pour un sprite hxw j'en parle même pas.

Ah oui, pour les routines nvg, le gain est légèrement plus important.
Et puis je ne vous ai pas donné le code entier de la boucle, donc il n'y a pas 40 cycles en tout dans la boucle, mais plus ; et la boucle se répète 16 fois (c'est à prendre en compte dans les calculs).

Donc c'est justifié.

Non, c'est du +4 octets et -0 cycles, donc c'est une pessimisation pure!

Bon, je sens qu'on va laisser XDanger décider, vu que c'est lui le mainteneur de ExtGraph. Mais a priori, il m'a l'air plutôt contre (cf. ./20).

Mais ce n'est pas la question, de savoir si on mettra ça dans ExtGraph.

Je voulais savoir pourquoi l'une des deux versions est plus rapide que l'autre alors qu'elle comportent le même nombre de cycles, c'est tout.
Il faudra que je relise le chapitre 4 du bouquin d'Abrash, j'étais passé très rapidment dessus, vu qu'il se référait au µP intels.

bah il dit des trucs generaux, mais aussi d'autres trucs tres specifiques, et il parle pas du tout du 68k hein donc pour cet exemple la ca te servira peut etre pas bcp...

et y peut y avoir pleins de raisons, t'en a eu deja pas mal d'evoquees au dessus

Bon, je poste ici, parce que c'est le seul post récent sur yn24.php, et j'en ai marre d'avoir jamais rien à poster.
Je voulais pas venir ici les mains vides, alors j'ai apporté avec moi une pensée à méditer : "La raison pour laquelle les hommes mentent vient certainement de la propension des femmes à poser tant de questions." (oui, c'est de la merde, ça n'a rien de très intéressant, mais j'ai un peu la flemme là)
Sur ce, bonne nuit.

Moumou> Completement a coté de la plaque

Oui. (Mais c'était voulu, soit dit en passant)

Comme je l'ai dit, sur les Sprite8/16/32, cette petite optimisation vitesse qui augmente la taille n'a qu'un intérêt limité, quelque soit le mode de dessin. En revanche, en gray et/ou pour les X8, elle est peut-être/probablement justifiée.

si Xlib l'utilise c'est que c'est justifié
remaruqé, reprennez directement les fonctions d'XLib c'est plus rapide

c'est pour poster des conneries dans un topic sérieux tu dégages

lol

Les fonctions de XLib sont trop grosses, trop inflexibles (h fixé), trop peu nombreuses (pas de Sprite8), ...

Raté.

ouai super malin je te donne la reponse a ton topic et tu me kikes merci! (super mentalité..)

bon pour ce qui est du 8x8 je le repete encore une fois:
1 fonction 8x8 ca prend de la place
2 c'est plus lent que du 16x8

apres le gas il a 50 sprites 8x8 ca fait 400 octet de perdu en XSmall si il enregistre comme un barbar en XSmall dans son prog (il peut le transformer en ram)
donc je perd 400 octets, mais j'utilise la meme fonction que 16x16 donc a la fin je perd sizeof(fonction8x8)-400 oc ce qui est >> 0 dans XLib donc tout benef, gain en place et gain en rapidité.
sur ce je vais rien apporté a ce topic puisqu'on ma kiker, et j'aime pas les gas qui disent des conneries alors qu'ils ont prog que 2 / 3 routines graphique!

Bon, ça ne sert à rien de kicker en fait...

Je pourrais répondre à ton post en contredisant chaque point, mais je ne le fais pas parce que tu sais très bien que ton post était totalement de mauvaise foi et que tes arguments ne tiennent pas debout, tu n'es absolument pas objectif.

mais bien sur
mais oui!!!
prouve le contraire a mon poste..
deja 8x8 plus lent que 16x8 ca tu le sais..
apres pour la place , on peut le stoquer en 8x8 et le transformer en 16x8 alors bon faut pas raconter des conneries non plus...

Oui, le 8x8 est légèrement plus lent que le 16x8.

Je pourrais répondre à ton post en contredisant chaque point

>> la preuve que ton poste est infondé!

C'est ça:

trust :
apres le gas il a 50 sprites 8x8 ca fait 400 octet de perdu en XSmall si il enregistre comme un barbar en XSmall dans son prog (il peut le transformer en ram) donc je perd 400 octets, mais j'utilise la meme fonction que 16x16 donc a la fin je perd sizeof(fonction8x8)-400 oc ce qui est >> 0 dans XLib donc tout benef, gain en place et gain en rapidité.

qui est de mauvaise foi. Déjà, la routine de Sprite8 ne fait pas 400 octets si on ne code pas comme un porc. Et puis pour le 16×8, ExtGraph le fait mieux parce qu'elle te permet d'utiliser la même routine qu'en 16×16.