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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 13/06/2018 07:13, H.J. Lu wrote:
> 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.

At least for ARM we have cortex-strings [1] with a more permissive licensing.
We usually try to update this repository first with arm related string
optimizations and sync later with other projects (glibc, android, etc.).

It does not have ifunc support, since so far it was not required (since it
also did not had any update for different chips like falkor or thunder), but
I can't see why it can't add support for runtime selection.  

While I see the advantages of adding on glibc to avoid the double effort,
I really think this kind of framework is better served as an external project.
It adds even more complexity (IS_IN (libcpu_rt_c)) on current GLIBC ifunc code
(which is somewhat convoluted) and it is not clear how easy it would be to 
distribute it on a usual way (a distribution would need to create another package
with downloads a different glibc release than system to build and extract the 
library itself).

[1] https://git.linaro.org/toolchain/cortex-strings.git

> 
>> 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.
> 

With the expectation on non formal releases, no ready useful gain in a default
installation (it only makes sense if you download/build a more recent glibc
version than system onde) and the idea of ready availability it really indicates
me to push this an external project.