A SUPPRIMER
cs_saylar
Messages postés
102
Date d'inscription
vendredi 21 avril 2006
Statut
Membre
Dernière intervention
10 février 2008
-
24 juin 2006 à 15:11
vecchio56 Messages postés 6535 Date d'inscription lundi 16 décembre 2002 Statut Membre Dernière intervention 22 août 2010 - 27 juin 2006 à 15:13
vecchio56 Messages postés 6535 Date d'inscription lundi 16 décembre 2002 Statut Membre Dernière intervention 22 août 2010 - 27 juin 2006 à 15:13
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/38280-a-supprimer
https://codes-sources.commentcamarche.net/source/38280-a-supprimer
27 juin 2006 à 15:13
26 juin 2006 à 22:34
A chaque application sa spécialité, dans 99.99999999% des cas on en a rien à foutre de gagner une ns .
"Avant les tableaux que tu donnes (qui passent pas, mais ça c'est pas ta faute), tu dis que c'est l'algorithme qui compte. Je ne suis pas d'accord. Plus exactement, ça dépend.
Pour un étudiant qui a un projet à faire, effectivement, le principe est plus intéressant que le résultat.
Mais à l'inverse, je doute que les gens qui développent OpenGL (ou d'autres librairies du genre) s'amusent à faire du code particulièrement élégant. Là au contraire, si on peut gagner 1ms, c'est déjà énorme."
Ton raisonnement est faux .
On fait d'abord un bon algo puis on optimise . tu optimise pour gagner 1ns par pixel mais si ton algo utilise 1s pour traiter chaque pixel çà ne sert à rien donc l'algo compte beaucoup plus que l'optimisation .
Quand à ton prof je veux bien qu'il t'es dit çà mais sur developpez.com il y a aussi eut un thread là dessus . C'était assez intéressant de voir une centaine de post parler d'un sujet vain . De toute façon je ne vois même pas pourquoi on peut douter que les deux écriture génère du code différent mais bon c'est comme çà .
Pour le coup du loop/dec-jxx, les tableau semblent dire le contraire mais bon je n'irai pas tester .
26 juin 2006 à 20:42
Alors, tout d'abord je vais te contredire en ce qui concerne developpez.com puisque je vais pas sur ce site. Et même mieux, je peux t'apprendre que c'est mon prof de compil' qui m'avait fait cette remarque. Donc, ça m'étonnerait bien que tu t'en rappelles !
D'autre part, si tu ne vois pas d'intérêt à gagner des nanosecondes, sache que moi non plus. J'aime le faire, c'est tout. Y'a des gens qui aiment le chocolat, et d'autres qui aiment gagner des nanosecondes. C'est pas la peine de se taper dessus pour savoir si y'a un intérêt à ça !
Avant les tableaux que tu donnes (qui passent pas, mais ça c'est pas ta faute), tu dis que c'est l'algorithme qui compte. Je ne suis pas d'accord. Plus exactement, ça dépend.
Pour un étudiant qui a un projet à faire, effectivement, le principe est plus intéressant que le résultat.
Mais à l'inverse, je doute que les gens qui développent OpenGL (ou d'autres librairies du genre) s'amusent à faire du code particulièrement élégant. Là au contraire, si on peut gagner 1ms, c'est déjà énorme.
(Oui oui, je sais : là on gagne des nanosecondes... Sauf que 1 nanoseconde de moins pour traiter 1 pixel, ça fait presque 2ms de gagnées pour une image en 1600x1200. Sur les 16ms dont on dispose pour calculer une image (en 60Hz), je trouve que gagner 1/8 de temps c'est pas si mal ! Et il y a sûrement plus de gens que ce que l'on peut croire qui utilisent cette résolution. Il suffit de faire des LANs pour le voir...)
Par flemme, je ne ferai pas de test concernant les gains de dec/jxx sur loop, même si je suis convaincu qu'on gagne plus de des nanosecondes...
Par contre et pour finir, j'ai moi-même désassemblé plein de petits bouts de code pour voir ce qui se passait (de toute façon, je crois que y'a que comme ça que je saurai la vérité à ce sujet), et la conclusion est la suivante (je la fait suffisament précise pour ne pas être ambigu mais aussi et surtout pour qu'elle puisse être dispensée, afin de lever ce voile qui pèse encore sur de nombreux programmeurs ;-) ) :
Dans les langages C et C++, les opérateurs unaires d'incrémentation/décrémentation préfixés et postfixés sont équivalents pour les types de base. Le code assembleur x86 généré utilise inc/dec pour les opérandes d'arithmétique entière. Les opérandes en virgule flottante sont quant à eux gérés par l'instruction fld1 suivie de faddp/fsubp.
(Test effectué avec gcc 4.0.2)
Voilà. Sur ce, je souhaite une bonne continuation à tout le monde.
26 juin 2006 à 17:50
Sinon, on m'a fait remarquer qu'il serait bien de pouvoir choisir en tre la hauteur et la largeur. Bien sur, c'est possible, mais sachant qu'il faudrait doubler le code pour obtenir cette fonction, alors qu'il sufit d'ouvrir paint pour modifier ce qu'on veut, je préfère laisser comme ça. Sinon, merci quand même.
Enfin, merci à SAKINGDOM pour m'avoir reperé ce que je croit maintenant être le dernier bug :
"for(i=0; i>[...]; i+=1)"
Michel
26 juin 2006 à 16:32
Oui je me rappèle, c'était sur developpez.com et il a bien dû y avoir 200 post sur ce thread . Mais je vois pas pourquoi le compilo transformerer:
--i en dec i
et
i-- en sub i,1
Et d'ailleurs rien ne nous dit que as(l'assembleur de gcc) n'optimise pas sub i,1 en dec i .
Et enfin rien ne nous dit que le proc n'optimise pas sub i,1 en dec i .
Donc çà me parait stupide d'en débattre . Et puis pour gagner 1 ns sur 1 millier d'itération, merci le gain .
Pour en revenir au coup de la boucle . Cela ne change rien car on ne fait jamais assez d'itération pour voir la différence(s'il y en a une notable) .
Je ne fait pas parti des gens qui essaye de gratter 1 ns sur une boucle de 10000 itérations car ce n'est pas intéressant, c'est l'algorithme qui compte(et j'en sais quelque chose en la matière) .
Pour informations:
Loop:
Clocks 286 386 486
label: jump 8+m 11+m 6
no jump 4 ? 2
Dec:
Operands 808x 286 386 486
reg8 3 2 2 1
mem 15+EA 7 6 3
reg16/32 3 2 2 1
Jcxx:
Operands 808x 286 386 486
label: jump 18 8+m 9+m 8
no jump 6 4 5 5
Fais le calcul par toi-même....
26 juin 2006 à 12:35
Et à ce titre, quelqu'un m'a dit un jour qu'il était plus rapide de faire un --i qu'un i-- (pareil pour un ++) parce que comme ça le compilo optimise avec un dec (respectivement un inc), qui prend moins de temps qu'un sub (respectivement add). Pour être honnête, j'ai eu la flemme de vérifier... Si quelqu'un se sent l'âme de le faire et de donner le résultat, je lui en serai fort gré. (Le fait que dec/inc est plus rapide que add/sub est déjà certain, ce qu'il faut vérifier, c'est si le compilo optimise !)
D'autre part, Pamaury, sache que l'instruction loop est déconseillée. En effet, elle prend 15 cycles processeur pour s'éxécuter, alors qu'un couple dec-jxx qui fait à peu près la même chose utilise seulement 2 cycles... Durées à confirmer dès que j'aurai remis la main sur ma doc ASM x86... Mais c'est de cet ordre, c'est certain.
(Petite pub pour ma "doc" : très bon bouquin pas cher, je le conseille franchement comme aide-mémoire des mnémoniques, allant des instructions de base aux extensions SIMD (registres XMM), en passant bien évidemment par le FPU... http://images-eu.amazon.com/images/P/2744015644.08.LZZZZZZZ.jpg).
25 juin 2006 à 13:55
25 juin 2006 à 02:02
25 juin 2006 à 01:53
25 juin 2006 à 01:46
SOURCE:
#include <stdio.h>
#include <windows.h>
int _test;
void Test()
{
_test++;
_test--;
_test+=2;
}
const int LOOP=2000000000;
int main()
{
LARGE_INTEGER time,time2;
LARGE_INTEGER freq;
QueryPerformanceFrequency(&freq);
QueryPerformanceCounter(&time);
for(long i=LOOP;i>=0;i--)
Test();
QueryPerformanceCounter(&time2);
printf("Test 1:%LLu\n",time2.QuadPart-time.QuadPart);
double delta=(double)(unsigned long long)(time2.QuadPart-time.QuadPart);
delta/=freq.QuadPart;
printf("Test 1:%f\n",delta);
QueryPerformanceCounter(&time);
for(long i=0;i<=LOOP;i++)
Test();
QueryPerformanceCounter(&time2);
printf("Test 2:%LLu\n",time2.QuadPart-time.QuadPart);
delta=(double)(unsigned long long)(time2.QuadPart-time.QuadPart);
delta/=freq.QuadPart;
printf("Test 2:%f\n",delta);
return 0;
}
TEST:(j'en ia lancé 5 à la suite)
Test 1:83807189
Test 1:23.412805
Test 2:81950909
Test 2:22.894225
Test 1:83708130
Test 1:23.385131
Test 2:82046849
Test 2:22.921027
Test 1:83601696
Test 1:23.355397
Test 2:82030898
Test 2:22.916571
Test 1:83414954
Test 1:23.303228
Test 2:82208794
Test 2:22.966269
Test 1:83570267
Test 1:23.346617
Test 2:82137592
Test 2:22.946378
Comme on le voit donc sur mon ordinateur, boucler vers la valuer est plus rapide que boucler vers 0 .
La différence reste quand même faible avec environ 350ms de différence sur 2 milliard d'itération et sur un test de 23 secondes .
Pour répondre à SAKingdom, en 250 itérations la différence entre le deux doit être inférieur au dixième de milliseconde car 250 itérations ce n'est rien . Le processeur en fait plusieurs millions par secondes sans problème .
24 juin 2006 à 23:22
24 juin 2006 à 20:16
il y a un sinon de trop ici : à l'addresse ->sinon<-
aussi dans les commentaire pour le code assembler, j'ai inversé l'initialisation des 2 variable. C'est en fait:
xor ecx, ecx ; ici on initialise j à 0
mov eax, 150 ; ici on initialise i à 150
ensuite un peu plus bas c'est:
add eax, 1 ; i++
Voila j'espere que j'ai pas fait d'autre erreures stupide dans les explications.
24 juin 2006 à 20:09
jns d'occupe de savoir si la valeur est non signé. Si elle n'est pas signé, elle "jump" à l'addresse sinon. Sitot que la valeur devien négative, elle devien signé (j'imagine que c'est comme ça quelle procède, je ne connais pas bien sont fonctionnement) donc elle n'éffectue pas le "jump" et passe l'instruction suivante. C'est l'équivalent de dire if(i < 0) en C.
24 juin 2006 à 20:06
jns d'occupe de savoir si la valeur est non signé. Si elle n'est pas signé, elle "jump" à l'addresse. Sitot que la valeur devien négative, elle devien signé (j'imagine que c'est comme ça quelle procède, je ne connais pas bien sont fonctionnement). Sinon elle passe. C'est l'équivalent de dire if(i < 0) en C.
24 juin 2006 à 19:58
int __cdecl main()
{
int i = 150;
int j = 0;
for(i = 150; i>=0; i--)
j += i;
printf("%d", j); //Pour forcer le compilateur à tenir compte du j sinon il conclue qu'il n'est pas utilisé
return 0;
}
Voici le codage en assembler de la boucle:
xor ecx, ecx ; ici on initialise i à 0
mov eax, 150 ; ici on initialise j à 150
$LL3@main:
add ecx, eax ; j+=i
sub eax, 1 ; i--
jns SHORT $LL3@main
Voici maintenant l'autre fonction:
int __cdecl main()
{
int i = 0;
int j = 0;
for(i = 0; i<150; i++)
j += i;
printf("%d", j);
return 0;
}
La boucle en assembler:
xor ecx, ecx ; on initialise i et j à 0
xor eax, eax
$LL3@main:
add ecx, eax ; j+=i
add eax, 1 ; j++
cmp eax, 150 ; <- _ICI_ comparaison
jl SHORT $LL3@main
Pas beaucoup de différence mais cette comparaison au bout de 250 valeur évalué peut couter cher en performence. Parce que l'on additionne, il faut évaluer tout le temps le registre pour savoir si il a atteind la valeur désiré. En soustrayent, jne ou jns s'occupe de savoir si la valeur a atteind 0 donc pas besoin de comparaison.
24 juin 2006 à 19:46
Pour moi ce conseil parait donc superflue mais je suis ouvert à toute démonstration du contraire .
24 juin 2006 à 16:41
24 juin 2006 à 16:29
Voici du code assembleur généré par Visual C++, pour justifier et infirmer quelques affirmations ...
int hauteur = 12;
0040101E mov dword ptr [hauteur],0Ch
int i, a = 0;
00401025 mov dword ptr [a],0
for (i=hauteur-1; i>= 0; i--)
0040102C mov eax,dword ptr [hauteur]
0040102F sub eax,1
00401032 mov dword ptr [i],eax
00401035 jmp WinMain+40h (401040h)
00401037 mov eax,dword ptr [i]
0040103A sub eax,1
0040103D mov dword ptr [i],eax
00401040 cmp dword ptr [i],0
00401044 jl WinMain+51h (401051h)
a++;
00401046 mov eax,dword ptr [a]
00401049 add eax,1
0040104C mov dword ptr [a],eax
0040104F jmp WinMain+37h (401037h)
for (i=hauteur-1; i--;)
00401051 mov eax,dword ptr [hauteur]
00401054 sub eax,1
00401057 mov dword ptr [i],eax
0040105A mov eax,dword ptr [i]
0040105D mov dword ptr [ebp-0E8h],eax
00401063 mov ecx,dword ptr [i]
00401066 sub ecx,1
00401069 mov dword ptr [i],ecx
0040106C cmp dword ptr [ebp-0E8h],0
00401073 je WinMain+80h (401080h)
a++;
00401075 mov eax,dword ptr [a]
00401078 add eax,1
0040107B mov dword ptr [a],eax
0040107E jmp WinMain+5Ah (40105Ah)
return 0;
24 juin 2006 à 16:16
for (i=hauteur-1; i--;)
24 juin 2006 à 16:02
for(i=0; i<hauteur; i+=1)
devrais être
for (i=hauteur-1; i>= 0; i--)
ton i cependant devra être un int signé pour éviter tout boucle infinie.
meme chose ici:
for(j=0; j<3; j+=1)
vers
for(j=2; j>=0; j--)
et j devra être signé aussi pour les mêmes raisons que i.
C'est peut-être pas nécessaire de changer la boucle ici cependant car elle n'est pas très grosse.
Autre chose, ici:
for(i = 0; i > (((largeur * 3) + 3) / 4) * 4; i += 1)
{
buffer[i] = 0;
}
Si i est initialisé à 0, il ne sera jamais plus grand que la condition donc la boucle ne se produira jamais. Je doit avouer qu'ici, je ne comprend pas.
24 juin 2006 à 15:11