This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intel's new rte_memcpy()


On 31 January 2015 at 19:48, OndÅej BÃlka <neleai@seznam.cz> wrote:
>
> On Fri, Jan 30, 2015 at 09:03:50AM -0800, H.J. Lu wrote:
> > On Fri, Jan 30, 2015 at 5:52 AM, Luke Gorrie <luke@snabb.co> wrote:
> > > Should networking application developers adopt Intel's custom
> > > implementation if (like me) they are absolutely dependent on good and
> > > consistent performance of memcpy on all recent hardware (>= Sandy
> > > Bridge) and Linux distributions? (and then -- what to do about
> > > memmove?)
> >
> Definitely not.


Thank you for the detailed feedback!

Questions... :-)

Is there a simple way that I can reproduce these benchmarks? (I am
curious in general and I would also like to run this on the two-socket
Xeon E5 machines that I test with.)

I would like to create relatively portable binaries that don't depend
on recent glibc releases. For this purpose I am tempted to reference
an older memcpy in my symbol table with this trick:

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

Is that a reasonable idea? Is it likely to have a significant
performance cost on some platforms? (in practice will this make memcpy
act like memmove?)

Cheers!
-Luke


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]