[vlc-devel] The "optimized" memory copies

[Pierre d'Herbemont]

On Aug 19, 2009, at 11:13 PM, Rémi Denis-Courmont wrote:

> Le mercredi 19 août 2009 23:21:59 Pierre d'Herbemont, vous avez  
> écrit :
>> AFAIK, vlc_memset() is just jumping to memset(), the indirection
>> explains the 2%.
>
> I doubt that one or two layers of "indirection" could account for 4  
> extra
> milliseconds per call.

I doubt as well. Yet, vlc_memset should only be a call to memset.

I ran this on my machine:
- The variance is pretty high
- This actually depends on which of memset and vlc_memset you call  
first in the loop:
	[ memset first ]
	memset average VLC: 53.396803ms Variance: 0.445347ms
	memset average OS: 56.579095ms Variance: 2.856423ms
	[ vlc_memset first ]
	memset average VLC: 55.944306ms Variance: 1.269227ms
	memset average OS: 54.462290ms Variance: 1.920085ms
	[memset against memset]
	memset average OS: 53.131503ms Variance: 0.294478ms
	memset average OS: 55.600697ms Variance: 1.476479ms

End word, this test doesn't highlight the fastest between memset and  
vlc_memset fairly on my machine.
However, vlc_memset() is just memset(), so you are right, vlc_memset  
is unneeded.


Same kind of test on my machine with memcpy:
	[memcpy first]
	memcpy average VLC: 106.164902ms Variance: 5.418645ms
	memcpy average OS: 103.954083ms Variance: 2.406485ms
	[memcpy against memcpy]
	memcpy average OS: 101.905495ms Variance: 4.175279ms
	memcpy average OS: 107.900208ms Variance: 3.024279ms

I believe that this is enough to say that on my machine vlc_memcpy is  
slower than memcpy as well.

My setup is a 2.4Ghz Core 2 Duo with Mac OS X 10.5.8.

Pierre.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 3444 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090820/7a47d371/attachment.obj>