Mon petit pack mensuel... - Page 2

> ps...
> tu parles
> l'optimisation n'existe pas
> c'est comme x+=1; x=x+1; et x++; le code généré sera addq #1,dx.. (je pense..)
Eh ben non pour les exemples que tu as donné, le code généré sera effectivement addq #1,dx, mais pour la boucle for c différent puisque les 2 instructions n'ont pas le même rôle :

for (i=n; i; i--) :

 move.w n,d0
 beq quit
loop
 subq.w #1,d0
 ... code de la boucle ...
 tst.w d0
 bne loop

for (i=n; i--; ) :

 move.w n,d0
| subq.w #1,d0
| bcc quit
 (ou bien beq quit si le compilo optimise bien)
loop
 ... code de la boucle ...
 dbf d0,loop

Et le code sera meilleur dans le 2è cas (gain de 8 cycles par boucle + 2/4 octets dans le progs)

si je comprend bien:
for (i=n; i; i--) : <=> for (i=n; --i ?

c'est bisard car le premier pourais etre optimiser par un dbf...

Dans le premier cas, tu ne décrémentes i que si i est non nul; dans ma méthode (for (i=n; i--; )) tu décrémentes toujours i, et à moins que le compilo soit intelligent, il va générer un code moins bon dans le premier cas (pas de dbf)

et c pas :
for (i=n; i; i--) : <=> for (i=n; --i; )
mais :
for (i=n; i; i--) : <=> for (i=n; i--; )

Le premier cas finit à i=1, tandis que le 2è finit à i=0 (c ce qu'on veut)

Arf..je voulais dire au niveau optimisation...

eh non, --i empêche de faire des dbf (il faut faire subq.w #1,d0/bne loop plutôt que dbf d0,loop)

oui donc au niveau opti: for (i=n; i; i--) : <=> for (i=n; --i :=

non, la 1è boucle est encore pire que la 2è

Ouia bon le c ca sux un max

mais non, c tout simple

c sûr qu'à moins d'avoir fait un compilo C ou de regarder les différentes méthodes en comparant le code généré, on peut pas vraiment savoir comment optimiser en C, mais bon la seule grosse optimisation est de pas faire de for (i=0;i<n;i++)

Et avec VC++ 6 ? c'est quoi le must ?

je suis pas un spécialiste de l'optimisation VC++, mais il m'avait semblé qu'il optimisait tout très bien (j'avais vraiment été impressionné quand j'avais vu la qualité du code généré avec un source pas du tout optimisé, style il est capable d'utiliser (a0)+ quand tu lui demandes de faire for (i=0;i<n;i++) printf("%d",tab[i]), et ensuite comme i est plus utilisé il te le transforme en for (i=n;i--; ) )

Mais alors pourquoi Win est il aussi merdiq

pke y'a plein plein de choses

Windows est lent parcequ'il est compilé pour 386+coprocesseur, il n'utilise aucune instruction des processeurs supérieurs.
C'est tout à fait voulu de M$ : ça leur permet de faire tourner leur OS sur un max de machines... donc de monopoliser au max.

Pollux : dis-donc, VC++ serait alors plus performant que GCC ?

c'est ridicule.. qui veux faire tourné XP sur un px de merde

C'est à Billou qu'il faut dire ça.

C'est l'avantage de l'open source.. permet de compiler son os avec les meilleurs optimisations..

Thibaut> c possible, mais y a peut-être aussi des différences entre GCC 68k et GCC x86 (en tout cas ce serait pas étonnant qu'une usine à gaz faite par des pros comme VC++ soit mieux foutue qu'un truc fait par des bénévoles)

Et je sais pas si ils optimisent pour 386 ou pour Pentium : même s'il y a des instructions communes, les temps d'exécution ne sont pas les mêmes, et je pense que WinXP n'est pas optimisé pour 386 (quoique c pas sûr mais bon )

Comment voulez-vous comparer GCC et VS si vous ne regardez pas le même processeur dans les 2 cas ??

Paraît que GCC est plus performant quand il s'agit de générer du code x86.


Tiens, Pollux a répondu avant moi

Pollux : je ne parlais pas d'optimisation, mais de jeu d'instructions.
Il génèrent un code 386+coproc mais optimisent pour les derniers processeurs.

JM> GCC x86 plus performant que le compilo de VS

> Paraît que GCC est plus performant quand il s'agit de générer du code x86
Ca me paraît qd même bizarre puisque les trucs du style [i]for (i=0;i<n;i++) printf("%d",tab) sont des optimisations indépendantes de la plate-forme, puisque les plate-formes à la fois sans mode postincrement et qui ont des multiplications plus rapide que les additions, ça doit pas courir les rues

de tt facon, VS utilise le compilo intel il me semble ... qui est un excellent compilo

Pollux
a écrit : Et par pitié pour GTC ne faites pas i=nbre_perso; i--; parce que GTC n'optimise pas les expressions séparées (because ça ralentirait énormément)

Vive GCC!

Pollux a écrit :
mais en tout cas le seul compilo que je connaisse qui fasse ça est Visual C++ (et puis si tu fais une boucle style for (i=0;i<n;i++) func(tab[i]), il remplace tab[i] par *p++ )

Et puis la plupart des programmeurs qui utilisent for utilisent aussi tab[i] plutôt que *p++, donc ça peut pas être optimisé par le compilo

Avec GCC 3.1 (j'ai testé avec: GCC.EXE (GCC) 3.1.1-tigcc-1):

#define USE_TI89
#include <tigcclib.h>

char tab[100];

void _main(void)
{
int i,n=100;
char *p=tab;
for (i=0;i<n;i++) printf("%d",p[[b][/b]i]);
}

donne:

	clr.w %d3
	lea tab,%a2
	.even
.L6:
	move.b (%a2)+,%d1
	ext.w %d1
	move.w %d1,-(%sp)
	pea .LC0
	jbsr printf
	addq.l #6,%sp
	addq.w #1,%d3
	cmp.w #100,%d3
	jblt .L6

Ce n'est pas l'idéal (i n'est pas éliminé), mais l'optimisation est faite. Mais si on n'utilise pas p, mais directement tab, ce n'est pas le cas.

nEUrOne a écrit :
de tt facon, VS utilise le compilo intel il me semble ... qui est un excellent compilo

Faux. On peut utiliser le compilateur Intel avec Visual Studio, mais le compilateur livré avec Visual Studio n'est pas celui d'Intel (mais VC++, développé par M$ eux-mêmes).