Re: [PATCH 00/20] RFC: Add the CPU run-time library for C

["H.J. Lu" <hjl.tools@gmail.com>]

On Tue, Jun 12, 2018 at 11:50 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/13/2018 12:19 AM, H.J. Lu wrote:
>>
>> The current glibc has memory and string functions highly optimized for
>> the current processors on the market.  But it takes years for released
>> glibc to be installed on end-users machines.  In 2018, many machines
>> with the latest Intel processors are still running glibc 2.17, which
>> was released in February, 2013.
>>
>> This patch set introduces the CPU run-time library for C, libcpu-rt-c.
>> libcpu-rt-c contains a subset of the C library with the optimized
>> functions.  The resulting libcpu-rt-c.so is binary compatible with
>> older versions of libc.so so that libcpu-rt-c.so can be used with
>> LD_PRELOAD or linked directly with applications.  For some workloads,
>> LD_PRELOAD=libcpu-rt-c.so has shown to improve performance by as much
>> as 20% on Skylake machine.
>
>
> What do you gain from adding this to glibc?

It uses what we have in glibc.   There is no need for separate implementations.

> Old systems will not have sufficiently new compilers and linkers, and they
> will not be able to directly build glibc and this new library.

libcpu-rt-c can be built on any systems with required GCC and binutils.
The resulting libcpu-rt-c.so is binary compatible with ALL versions of
x86-64 glibcs.

> It seems that this library does not define its own ABI, so it does not have
> to be tied to the glibc release schedule, but putting it into the source
> tree implies such alignment.

I don't expect there will be formal releases of libcpu-rt-c.  On the other
hand, libcpu-rt-c is ready to use at any time. Initially, it has to be built
as the part of glibc.  Depending on its feedbacks, it may be changed
to just build libcpu-rt-c without building the rest of glibc.

> I don't doubt that this can be useful (but I doubt it will completely stop
> string function backports), but building and shipping this library as part
> of glibc seems detrimental to its goals.

I don't expect it will be shipped as the part of glibc.  But when people
ask for better string/memory functions on Skylake running RHEL 7, I
can point them to libcpu-rt-c or I can build one for them on Fedora 28.

-- 
H.J.