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

Michael Niedermayer michaelni at gmx.at
Sun May 27 23:26:27 CEST 2007


Hi

On Sun, May 27, 2007 at 11:11:45PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, May 27, 2007 at 10:47:55PM +0200, Attila Kinali wrote:
> > On Sun, 27 May 2007 18:19:48 +0200
> > Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > 
> > > Hello,
> > > 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.
> > > So what do you think about attached patch? Can someone do more concise
> > > benchmarks?
> > 
> > Here some benchmarks:
> [...]
> > I also sinlge-run tested a few other samples similar to benchmark 1 and 3
> > (ie animes with divx3, divx4, xvid, h.264) codecs that didn't show any
> > siginificant speed difference (<1%)
> > 
> > Interesting are benchmark 2 and 5, which both are faster with
> > the patch. 
> 
> hmm, theres something odd ...
> where is this code using any memcpy at all?
> doesnt mga vo always use mem2agpcpy() ?
> it seems the patch disabled this and uses plain memcpy() for it
> 
> and MIN_LEN is 2k and mem2agpcpy is just done per line which is
> less then 2k so it practically falls back to rep movsb
> 
> this is in impressive series of bugs ...
> 
> if my hypothesis is correct then reimar will have some work to do ;)

hypothesis seems wrong MIN_LEN seems 64
maybe HAVE_MMX1 should rather be called HAVE_ONLY_MMX1

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/89ade46c/attachment.pgp>


More information about the MPlayer-dev-eng mailing list