Discussion :

[themadmax]

Bonjour,
Je viens de me metre tres recement à l'assembleur, bien que je ne doute pas des capacité de celui-ci, voici mon probleme.
J'ai testé mon code dans Visual Studio 2005, voici mes 2 fonctions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
void ASMbuff8to32(BYTE* in, BYTE* out, int imgSize)
{
	__asm					
	{
		mov ecx, imgSize //Stock la taille de l'image
		mov eax, in		 //pointe sur l'image d'entree
		mov ebx, out	 //pointe sur l'image de sortie
		label:
			mov dl, byte ptr [eax]//recupere le BYTE de l'image d'entree
			mov byte ptr [ebx], dl	//copie le 3 fois dans l'image de sortie
			mov byte ptr [ebx+1], dl	
			mov byte ptr [ebx+2], dl
			add ebx,3		//avance de 3 sur l'image de sortie
			inc eax			//avence d'un sur l'image d'entree
							//decremente le compteur
			loop label		//boucle tant que ecx > 0
	}
}
 
void buff8to32(BYTE* in, BYTE* out, int imgSize)
{
	while ( imgSize >= 0 )
	{
		*out = *in;
		out++;
		*out = *in;
		out++;
		*out = *in;
		out++;
		in++;
		imgSize--;
	}
}

Et lorsque je teste la rapidité d'execution, mon code ASM est plus lent que mon code C ! (Mode Release avec optimisation standard )
En regardant en mode debugage de VS, je remarque de le code ASM généré par ma function C est bien plus long et à l'air d'etre bien mois optimisé!
Je sais que l'integration de code Asm dans un langage C, n'est pas la façon la plus rapide d'execution, mais c'est quand meme bien étrange ?

Si vous avez le moindre soupçon, de savoir d'ou cela peu provenir, merci de bien vouloir eclairer ma lumiere dans ce sombre couloir... je suis completement désassemblé

[Invité(e)]

Bonsoir
Alors, je ne suis pas expert en assembleur, par contre, je sais que sur les processeur de type x86, toutes les instructions ne s'éxécutent pas à la même vitesse.
De plus, les processeurs ont aujourd'hui des jeux d'instructions spéciales comme MMX, sse qui bien utilisées font des programmes plus rapides. Et les compilateur savent utiliser ces instructions à bon escient.

[Scarmatil]

Remplace, ton loop par dec ecx | jnz label, tu gagneras déjà un peu.

De plus, les processeurs ont aujourd'hui des jeux d'instructions spéciales comme MMX, sse qui bien utilisées font des programmes plus rapides. Et les compilateur savent utiliser ces instructions à bon escient.

Je ne suis pas sûr que à bon escient soit le mot... ^^
Enfin de toute façon ici, c'est n'est pas l'idéal pour utiliser des instructions mmx.

[themadmax]

J'ai remplacé l'instruction loop, mais tjrs plus lent!

Voici les temps d'executions en milisecond pour 5000 appels:
C fucntion Time: 1078
ASM function Time: 1234

Sa fait quand meme une bonne differance.
J'ai recopier le code assembleur generé par le compilo pour la function C, et cette nouvelle fonction est encore bien plus lente ! (~6000ms)

Merci qd meme pour vos reponces

[Scarmatil]

J'ai testé ta fonction asm et elle est 3 fois plus rapide que celle en C (5 fois sans le loop), tu dois te tromper dans l'évaluation du temps, tu fais comment ?

[WO]

Une petite question...

Peux-tu resituer le contexte de cette routine ?

Certaines fonctions de copies sont codées complètement différemment selon les objectifs. Dans le cas du graphisme (par exemple), une copie de mémoire à la main est absurde car la charge est déportée dans le blitter et n'est donc même plus mesurable... l'utilisation du MMX ne pouvant même pas rivaliser...
Les compilateurs ne sont pas très performants mais pas complètement idiots non plus : Ils utilisent des fichiers annexes qui permettent de générer un code différent selon le contexte d'activité. Ce que tu ne fais pas forcément à la main et qui n'est pas incriminable à l'ASM mais au codeur (restons logique...) : Si le compilateur génère un code performant et si en copiant celui-ci il ne l'est plus... je trouve ça un peu magique.. non ?

@+WO

[themadmax]

Merci pour vos reponces!

Donc j'utilise GetTickCount pour evaluer le temp, et j'appelle 1000 fois ma focntion.
J'ai aussi essaillé de compiler ASM dans une lib externe, mais le resultat n'est tjrs pas plus rapide.

Pour ce qui est du contexte, cette fonction me sert pour envoyer une image a un compresseur Video, qui utilise VideoForWindows. Et il ne gere que les images 24bit. Je repete donc 3 fois mes pixels 8bits.

Voici la solution complete de mon code : http://themadmax.free.fr/TestAsm.zip
(10ko. MS. Visual Studio 2005)

[WO]

- Pour de nombreuses raisons, la méthode de test est totalement inappropriée mais vraiment !

- Le mode User disposant de très peu de temps pour faire son boulot de manière continue avant d'être interrompu par le noyau kernel, tu mesures beaucoup de choses et, entres autres, peut-être ton code...

- Dans le traitement vidéo que tu veux faire, la réponse est évidement l'ASM et ce trouve être déjà implémentée dans la partie basse de DirectShow (par exemple).

Tu peux cependant utiliser des fonctions du Bitblt, si tu tiens à le faire à la main (tes benchmarks ne t'indiquerons rien dans ces cas là car le travail est déplacé hors du CPU...). Cependant tu gagnerais à faire de l’image 32 bits pour des questions d’alignement et ta copie se ferait au minimum sur des DWords (donc déjà quatre fois plus vite…) et le blitter serait bien content lui aussi de pouvoir travailler sur des données alignées au moins en sortie.

Donc, il me semble qu’il y a beaucoup de problèmes imbriqués…

Tu devrais utiliser RosAsm. Pour dé-assembler ton code (voir le ré-assembler) pour vérifier le code réellement généré par ton compilateur…

@+WO