[MPlayer-dev-eng] [RFC] disable fastmemcpy on x86-64 by default

[Michael Niedermayer]

Hi

On Sun, May 27, 2007 at 08:25:12PM +0200, Reimar Döffinger wrote:
> Hello,
> On Sun, May 27, 2007 at 07:29:09PM +0200, Michael Niedermayer wrote:
> > On Sun, May 27, 2007 at 06:19:48PM +0200, Reimar D?ffinger wrote:
> > > since SSE is part of the x86-64 architecture, at least glibc makes use
> > > of it for its memcpy and some quick (and imprecise) tests indicate that
> > > it's at least not slower.
> > 
> > TOOLS/fastmemcpybench.c ?
> 
> That does not help really much, since which one wins depends
> extremely on sizes, e.g. (values in () are on 32 bit):
> 
> size 32 bytes:
> system libc 1525.9MB/s (305.2MB/s)
> fastmemcpy 381.5MB/s (339.1MB/s)
> 
> size 1024*768*2:
>  1015.6MB/s (557.5MB/s)
>  1201.6MB/s (1199.9MB/s)
> 
> for even larger sizes the differences don't seem to be statistically
> relevant.
> 
> In personally don't find the difference decidedly enough in favour for
> our fastmemcpy to use it in my own builds but your opinion might
> differ (using system memcpy reduces binary size and instruction cache
> load)...

i dont think that a single memcpy() libc or fast can be optimal, the optimal
choice depends on size to be copied, if src and dst are in the cache and
if dst will be read immedeatly afterwards, on the cache size, and if dst
is in main memory or on some pci/agp card

we already have a function for mem->agp copies so that case doesnt need to be
considered anymore

what about a mp_memcpy() / av_memcpy()
which takes AV_SRC_IN_CACHE, AV_DST_IN_CACHE, AV_WILL_READ_DST, AV_SIZE_CONST
?


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070527/0da738c7/attachment.pgp>