Date: Fri, 4 May 2012 08:45:48 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Andrew Reilly <areilly@bigpond.net.au> Cc: current@freebsd.org, net@frebsd.org Subject: Re: fast bcopy... Message-ID: <20120504064548.GB12241@onelab2.iet.unipi.it> In-Reply-To: <20120503234356.GD26284@johnny.reilly.home> References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120503234356.GD26284@johnny.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 04, 2012 at 09:44:15AM +1000, Andrew Reilly wrote: > On Wed, May 02, 2012 at 08:25:57PM +0200, Luigi Rizzo wrote: > > as part of my netmap investigations, i was looking at how > > expensive are memory copies, and here are a couple of findings > > (first one is obvious, the second one less so) > > Most C compilers (well, the ones I regularly use) inline small, > constant-length memcpy operations of the sort you're describing > here. I would expect techniques like that to beat any amount of > hand-tuning in a elf-linkage bcopy subroutine. > > Sure, you want a good implementation for your variable-length > copies, and data layout and alignment is tremendously important > these days, so there's no single silver bullet here. The two things i was addressing on my message cannot be solved by a compiler: the memcpy/bcopy has variable length in the places i was looking at, and the compiler cannot infer that it is allowed to extend the copy to full words or cache lines instead of stopping at the exact boundary. I don't even dare anymore to hand-optimize code: too many times i have been beaten by the compiler. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120504064548.GB12241>