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

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

On Wed, Jun 13, 2018 at 5:03 AM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
> 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

The framework for IFUNC and tunables are in glibc.  The optimized functions
are in glibc.  I can extract the relevant parts from glibc to create a separate
git repo.  Then I need to decide if I should fork or keep updating it
from glibc.
It is a duplicated effort for no good values.

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

I have no problem to maintain it as a branch on github and point people
to it when asked.

-- 
H.J.