optimisation de boucle - Page 1

-

c'est largement optimisable

-

bah c simple, tu prend ton bloc dans la 3eme boucle, et tu le copie colle 30*30*30 fois, comme ca apres t'as pls aucune boucle

hem... dsl

-

Bah tu ne peux pas faire mieux en optimisation en taille.

JackosKing > Tu vois encore un peu et ton post aurait pu être utile.

Orion_ > Essaye ça :

objdata2 = objdata1;

for(k = 0; k < 30; k += 5)
 {
 for(j = 0; j < 30; j += 5)
  {
  for(i = 0; i < 30; i += 5)
   {
   objdata2->x = i - 15;
   objdata2->y = j - 15;
   objdata2->z = k - 15;
   objdata2++;
   }
  }
 }

Je pense que tu devrais gagner un petit peu.

[edit] Ça me fait gagner environ 20 octets sur le test que j'ai fait.

bein il voulait savoir si ct optimisable je lui ai repondu
puis:
for(i = 0; i < 30; i += 5)
objdata2->x = i - 15;
c'est pas vraiment top...

et avec des while?

genre:

objdata2 = objdata1 + 6 * 6 * 6;

k = 30;
while ((k -= 5))
 {
 j = 30;
 while ((j -= 5))
  {
  i = 30;
  while ((i -= 5))
   {
   objdata2->x = i - 15;
   objdata2->y = j - 15;
   objdata2->z = k - 15;
   objdata2--;
   }
  }
 }

-

JackosKing > Si t'as qqchose à proposer, pourquoi tu le met pas directement ? Et si t'as rien, pourquoi tu poste ?

sBibi > GCC ne fait pas ça tout seul ? (au fait faudrait déplacer le objdata2--; avant les affectations du coup) [edit] cf IRC -> ok

Orion_ > A la fin des boucles nvertex a toujours la même valeur, pas besoin de l'incrémenter pour la connaitre

Vertyos> aucune idee

c surment parce que je suis fatigué...:
nvertex1=0;
{
register short k,j,i;
for(k=-15;k<15;k+=5)
for(j=-15;j<15;j+=5)
for(i=-15;i<15;i+=5)
{
objdata1[nvertex1 ].x=i;
objdata1[nvertex1 ].y=j;
objdata1[nvertex1++].z=k;
checkloadbar();
}
}
je comprend pas l'interet de l'offset constant -15...

pas sur que ca fasse gagner bcp en taille ca.. ms bon

bein 3 sub

Tu peux essayer:

  for(k=0;k<30;k+=5)
  {
    for(j=0;j<30;j+=5)
    {
      for(i=0;i<30;i+=5)
      {
        toto *objdata=objdata1+(nvertex1++);
        objdata->x=i-15;
        objdata->y=j-15;
        objdata->z=k-15;
        checkloadbar();
      }
    }
  }

ou:

  for(k=0;k<30;k+=5)
  {
    for(j=0;j<30;j+=5)
    {
      for(i=0;i<30;i+=5)
      {
        objdata1->x=i-15;
        objdata1->y=j-15;
        (objdata1++)->z=k-15;
        nvertex1++;
        checkloadbar();
      }
    }
  }

Mais je ne sais pas si c'est un gain. Il vaut mieux travailler en assembleur pour optimiser au maximum.

-

subi + dbra beurk

-

Il y a des jours où je me demande s'il ne faudrait pas créer un mot-clé asm_or_c qui donne les deux variantes, asm et C de la même fonction. Après, ce serait au compilo de décider si la fonction C ou asm est la plus efficace Evidemment le pb serait qu'une nouvelle version du compilo risquerait d'apporter des incompatibilités, parce que le code C n'était pas testé depuis longtemps et le compilo se met à utiliser le code C au lieu du code asm.

Bon je dis pas ça pour critiquer le code d'Orion, hein, la version actuelle de GTC génère un code un peu moins efficace que ça, mais un compilo futur pourrait générer du code meilleur

Sinon, dans ma todo list, je pourrrais rajouter un convertisseur asm -> code intermédiaire pour que le compilo optimise l'asm qd c'est possible (on pourrait faire plein de trucs avec, du genre recompiler la ROM ).

Pkoi je fais tjs des posts croisés?

	movea.l	objdata1(pc),a4	; (pas de lea, objdata1 contient un pointeur)
	moveq	#0,d4		; nvertex1
	moveq	#29,d5		; k
	moveq.l	#29-15,d2
Next1k:
	moveq	#29,d6		; j
	moveq.l	#29-15,d1
Next1j:
	moveq	#29,d7		; i
	moveq.l	#29-15,d0
Next1i:
	subq.w	#1,d0		; i-15
	subq.w	#1,d1		; j-15
	subq.w	#1,d2		; k-15
	move.w	d0,(a4)+	; objdata1[nvertex].x=i-15
	move.w	d1,(a4)+	; objdata1[nvertex].y=j-15
	move.w	d2,(a4)+	; objdata1[nvertex].z=k-15
	addq.w	#1,d4		; nvertex++
	bsr	checkloadbar
	dbra	d7,Next1i
	dbra	d6,Next1j
	dbra	d5,Next1k

Ça devrait prendre 6 octets en moins je crois.

-

Mais ça ne correspond pas à ton code C, je crois, puisqu'il me semble que tu ne fais que 6 itérations en C, pas 30, non ?

-

-

En effet.
Bon, j'attends l'optimisation de Pollux, il arrive toujours à faire des trucs impressionnants

Non, comme je l'ai dit la version actuelle de GTC génère du code moins bon que ton asm de départ. Je parlais de versions futures (en fait ce genre de choses est très courant, je ne compte pas le nombre de progs asm très mal écrits [code moins bon que celui généré par un compilo] - et ma remarque ne visait pas ton code en particulier, qui est presque optimal)
Sinon pour une démo de 4 ko tu peux aussi essayer de compresser et de faire un auto-extractible Je ne sais pas si le taux de compression sera fantastique vu la faible taille, mais ça éviterait des malloc et ça t'éviterait des drawline et ce genre de choses pour tes logos (bon vieux memcpy ), peut-être jusqu'à compenser le ko pris par le décompresseur.

-

Et sinon il sert à quoi le nvertex?

(et, entre autres bénéfices de l'optimisation par le compilo, ce genre de choses qui est activé en mode "debug" est automatiquement désactivé en mode "normal" puisque le compilo peut déterminer si nvertex est utilisé après ou pas)