qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] memcpy speed (Re: [PATCH v2] netmap backend (revised))


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] memcpy speed (Re: [PATCH v2] netmap backend (revised))
Date: Thu, 24 Jan 2013 09:54:19 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jan 23, 2013 at 06:55:59PM -0800, Luigi Rizzo wrote:
> On Wed, Jan 23, 2013 at 8:03 AM, Luigi Rizzo <address@hidden> wrote:
> 
> > > I'm even doubtful that it's always a win on FreeBSD.  You have a
> > > threshold to fall back to bcopy() and who knows what the "best" value
> > > for various CPUs is.
> >
> > indeed.
> > With the attached program (which however might be affected by the
> > fact that data is not used after copying) it seems that on a recent
> > linux (using gcc 4.6.2) the fastest is __builtin_memcpy()
> >
> >         ./testlock -m __builtin_memcpy -l 64
> >
> > (by a factor of 2 or more) whereas all the other methods have
> > approximately the same speed.
> >
> 
> never mind, pilot error. in my test program i had swapped the
> arguments to __builtin_memcpy(). With the correct ones,
> __builtin_memcpy()  == bcopy == memcpy on both machines,
> and never faster than the pkt_copy().

Are the bcopy()/memcpy() calls given a length that is a multiple of 64 bytes?

IIUC pkt_copy() assumes 64-byte multiple lengths and that optimization
can matches with memcpy(dst, src, (len + 63) & ~63).  Maybe it helps and
at least ensures they are doing equal amounts of byte copying.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]