Re: Relative performance of memcpy at GLIBC_2 dot 2 dot 5 and memcpy at GLIBC_2 dot 14

[Mike Frysinger <vapier at gentoo dot org>]

On 03 Feb 2015 11:09, Luke Gorrie wrote:
> On 2 February 2015 at 14:27, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > On Mon, Feb 02, 2015 at 10:00:13AM +0100, Luke Gorrie wrote:
> >> 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?)
> >>
> > Depends on workload, if you do lot of large copies then avx2 improvement
> > is significant. I cannot predict effect in general so test it.
> 
> I would like to better understand the exact implications of binding to
> memcpy@GLIBC_2.2.5 vs memcpy@GLIBC_2.14.
> 
> My impression is that neither symbol is tied to a particular
> implementation, only to a particular behaviour. Specifically, that
> memcpy@GLIBC_2.2.5 copies memory forward in memory (to be
> bug-compatible with old applications that depend on this) whereas
> memcpy@GLIBC_2.14 has undefined direction. However, in glibc 2.20 both
> are actually implemented with modern AVX instructions and
> memcpy@GLIBC_2.2.5 is really an alias to the latest and greatest
> memmove.
> 
> So far so good? (Is this documented anywhere, btw?)

yes, the point of the symbol version change is due to the ABI change.  while the 
function has always been documented as unsafe to use on overlapping memory, that 
didn't stop people from writing bad code that only worked on x86 platforms 
(where the ipmlementation happened to support overlapping memory).  with the 
change to the func on x86 where overlapping memory became a runtime problem, 
many apps broke.  so new symbols were added to keep stupid broken programs 
working.

whether in practice memcpy@GLIBC_2.2.5 and memcpy@GLIBC_2.14 return the same 
implementation depends on a number of factors.  if you read the code, they're 
both IFUNCs which means they return an implementation based on the cpu 
capabilities.  you won't get an AVX version if your cpu doesn't support it.
-mike

Attachment: signature.asc
Description: Digital signature