Problème d'optimisation - Page 1

Je comprend pas, lorsque je remplace y*30 par (y<<5) - (y<<1) je perd en vitese.

Je compile avec -O3.

Y a-t-il quelque chose que je ne fais pas correctement?

Voilà le code ASM obtenu:

dans la fonction affiche pixel, j'ai y*30 et dans la fonction inversepixel, j'ai la 2° solution.
AffichePixel:      move.w 8(%sp),%d2      move.w 10(%sp),%d0      move.w %d0,%d1      lsl.w #5,%d1      add.w %d0,%d0      sub.w %d0,%d1      move.w %d1,%a0      add.l 4(%sp),%a0      move.w %d2,%d0      asr.w #3,%d0      lea (%a0,%d0.w),%a0      not.w %d2      and.w #-32761,%d2      jbge .L2      subq.w #1,%d2      or.w #-8,%d2      addq.w #1,%d2 .L2: #APP      bset.b %d2,(%a0) #NO_APP      rts      .section     .text.InversePixel,"x"      .even      .globl     InversePixel InversePixel:      move.w 8(%sp),%d2      move.w 10(%sp),%d0      move.w %d0,%d1      lsl.w #5,%d1      move.w %d1,%a0      add.l 4(%sp),%a0      add.w %d0,%d0      sub.w %d0,%a0      move.w %d2,%d0      asr.w #3,%d0      lea (%a0,%d0.w),%a0      and.w #-32761,%d2      jbge .L7      subq.w #1,%d2      or.w #-8,%d2      addq.w #1,%d2

Pour info, ExtGraph utilise un autre code C depuis bien longtemps

Oui en fait l'optimisation est faite automatiquement apparemment, parceque la code de affiche pixel correspond à y<<5-y<<2, alors que dans le source C j'avais y*30.

Par contre c'est quend même bizard que lorsqu'on l'explicite en C il ne soit pas capable de le retrancrire correctement en ASM.

autre question, peut-on préciser les options de compilation pour un fichier donné lors de la compilation d'un projet?

c'est peut être une question d'associativité : au lieu de faire "base + (y<<5) - (y<<1)" tu peux essayer "base + ((y<<5) - (y<<1))" (ça évite de devoir faire deux additions 32 bits ^^)

il est déclaré comment "y" ?

Pollux> c'est la première chose que j'ai essayé, mais c'était encore pire ^^

Sinon y est déclaré en short (short y

Essaie en unsigned short.

nan ça n'améliore pas


mais bon en regardant le code asm, l'optimisation est directement faite sans avoir à l'écrir en C

mouais, ben c'est le genre de choses qui arrivent, surtout avec un compilo comme gcc qui a des tonnes et des tonnes de passes empilées les unes au-dessus des autres...

Bonjour !
Je crois avoir le même problème en essayant de créer ma propre routine d'affichage d'un pixel : elle semble moins rapide que celle de la librairie tigcc...

Ça serait dû au compilateur TIGCC ?

EDIT : désolé de reprendre un vieux sujet mais le titre semble correspondre.

EDIT#2 : Voici mon code...

void pixel_ON(unsigned char x, unsigned char y, unsigned char *vscreen_adress)
{
y += y;
vscreen_adress += (y << 4) - y + (x>>3);
*vscreen_adress |= 0b10000000 >> (x & 0b00000111); }

Ok, désolé d'avoir réveillé un Zombie (mais le moteur de recherche est un peu moisi ou était défaillant ce jour là, j'avais tapé "pixel" et j'avais rien trouvé il me semble.)
... Donc si je comprend bien, je dois de toute façon passer par (et donc apprendre) l'assembleur. J'vais peut-être m'y mettre alors.

non, ce n'est certainement pas la chose la plus importante de faire de l'asm... allumer les pixels un à un à partir de ses coordonnées (x,y), c'est une méthode très inefficace et il y a souvent bien mieux -- un programme C qui écrit dans le buffer de l'écran peut facilement être 10x plus rapide qu'un programme assembleur qui utilise une routine de type pixel_ON

Renegade Master (./18) :
(mais le moteur de recherche est un peu moisi ou était défaillant ce jour là, j'avais tapé "pixel" et j'avais rien trouvé il me semble.)

[google]site:www.yaronet.com pixel fast[/google] (autant passer par google )

Raaah Pen^2 ce bon vieux topic ! On était presque tous au lycée à cette époque, je crois

eh oui #nostalgie# (enfin moi je devais être en première année de DUT, vu que j'ai commencé l'ASM au début de mon premier DUT)
Sinon, le topic dont j'ai donné l'adresse est un topic *récent* : la réponse est déjà un copié-collé d'un topic plus ancien