Discussion :

[progfou]

(Re-)bonjour !
J'ai essayé de faire un memcpy (plus rapide) que le standard, seulement, il arrive qu'il ne se comporte pas correctement...
Il est censé, lorsque les adresses sont alignées sur 32-bits, copier 32 bits d'un coup.

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
__inline
void * mymemcpy(void * dst, void const * src, size_t len)
{
    int	*lpDst = (int *)dst;
	int IntDst = reinterpret_cast<int>(dst);
	int const *lpSrc = (int const *)src;
	uintptr_t IntSrc = reinterpret_cast<uintptr_t>(src);
 
	if (!(IntSrc & 0xFFFFFFFC) && !(IntDst & 0xFFFFFFFC))
	{
		while (len >=4)
		{
			*lpDst++ = *lpSrc++;
			len -= 4;
		}
	}
 
	char *pcDst = (char *)lpDst;
	char const *pcSrc = (char const *)lpSrc;
 
	while (len--)
	{
		*pcDst++ = *pcSrc++;
	}
 
	return (dst);
}

Je ne comprends pas ce qu'il se passe, j'ai l'impression que, parfois, il ne copie que des 0.

[PierroElMito]

je veux pas te décevoir, mais ça me parait pas possible de faire un memcpy plus rapide que le standard (sauf si ton compilo génére du code d'un autre age).

[progfou]

Je vais donc préciser que la plateforme est de type ARM, et que j'ai n'ai pas moyen de connaître le code généré.
Mais, a priori, quand ce memcpy fonctionne, il est déjà plus rapide (x2).

[Ulmo]

Ton len est 4 fois trop grnad dans la boucle principale.

[progfou]

Exact
Et en plus, dans l'appel, j'avais fait mon boulet( un copier/coller de trop).

[PierroElMito]

Ton test d'alignement me parait un peu space aussi...

Code :

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

1
2
 
if (!(IntSrc & 0xFFFFFFFC) && !(IntDst & 0xFFFFFFFC))

ce serait pas mieux avec ça:

Code :

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

1
2
 
if (((IntSrc & 0x03)==0) && ((IntDst & 0x03)==0))

d'ailleurs, je pense pas que ce soit utile de tester l'alignement dans ton cas.

[Ulmo]

Je vais donc préciser que la plateforme est de type ARM, et que j'ai n'ai pas moyen de connaître le code généré.
Mais, a priori, quand ce memcpy fonctionne, il est déjà plus rapide (x2).

D'où sors tu ce chiffre ?
Je viens de jeter un coup d'oeil au memmove de VS2005. Il est extremement complet : utilisation de SSE2 (qu'est-ce donc ?) si c'est possible, alignement sur un DWORD (copier 32 bits par 32bits, t'inquiète ils y ont pensé), décalages si les alignements src/dest sont différents, utilisation d'instructions "rep movs", ...

Après les résultats de comparaison vont grandement dépendre de la taille des données à copier. Sur de petits blocs, les différents tests vont prendre une part visible du temps de copie. Pour des copies plus importantes, je doute fort que tu puisses faire mieux.

[PierroElMito]

C'est de l'ARM, donc pas de SSE2 ni de rep movs. Par contre, j'aimerais bien savoir aussi d'ou sort le x2? Et le code que t'as généré, est-ce que tu avais activé toutes les optims (en release)?

[progfou]

Le x2, c'est la mesure sur mon code, c'est une moyenne, et c'est tout ce qui m'intéresse.
Et puis, en lisant tout, tu aurais vu, Ulmo ce que PierroElMito a bien vu, que c'est un ARM.
Tu me parles de memmove, je parle de memcpy...
Evite, si possible, de me prendre pour un idiot.

Bref, le code généré, c'est avec optimisations.