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

[Luke Gorrie <luke at snabb dot co>]

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?)

In this case my question is really: is the implementation of
memcpy@GLIBC_2.14 significantly faster than the implementation of
memcpy@GLIBC_2.2.5 on any recent CPU architectures? (Special emphasis
on variable size in-cache copies in the 64-1500 byte range and on
Intel CPUs >= Sandy Bridge.)

If the performance is much the same (ballpark 20% difference) then it
seems reasonable that I can keep my symbol table referencing
memcpy@GLIBC_2.2.5 for the foreseeable future in order to be
compatible with older glibc versions.

If performance is significantly different then I have a problem. I
would have to either link with memcpy@GLIBC_2.14 and drop binary
compatibility with older glibc versions or I would need to find a way
to be flexible and link with either memcpy@GLIBC_2.2.5 or
memcpy@GLIBC_2.14 depending on what is available at runtime.

Feedback on any/all of the above points welcome :-)

I would also be very interested in general tips about best practices
for creating binaries that are portable between semi-recent Linux
distributions. I have found very little actionable information in the
LSB documents. (Can't even find their gcc wrapper anywhere.) I seem to
find the most useful information from blogs of independent game
developers so far :).

Cheers,
-Luke