From: "H.J. Lu" <hjl.tools@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH 00/20] RFC: Add the CPU run-time library for C
Date: Wed, 13 Jun 2018 12:31:00 -0000 [thread overview]
Message-ID: <CAMe9rOqf5Na4zBW4kbprcOBRdjhnOydps9n5W7K196ORPC0j9g@mail.gmail.com> (raw)
In-Reply-To: <ca039829-f08d-60c4-29ea-b52a5f7e2642@linaro.org>
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.
next prev parent reply other threads:[~2018-06-13 12:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 22:19 H.J. Lu
2018-06-12 22:19 ` [PATCH 07/20] libcpu-rt-c/x86-64: Add memrchr H.J. Lu
2018-06-12 22:19 ` [PATCH 08/20] libcpu-rt-c/x86-64: Add memset and wmemset H.J. Lu
2018-06-12 22:19 ` [PATCH 04/20] libcpu-rt-c/x86-64: Add memchr H.J. Lu
2018-06-12 22:19 ` [PATCH 02/20] libcpu-rt-c/x86: Add cacheinfo H.J. Lu
2018-06-12 22:19 ` [PATCH 03/20] libcpu-rt-c/x86: Add cpu-rt-tunables.c H.J. Lu
2018-06-12 22:20 ` [PATCH 12/20] libcpu-rt-c/x86-64: Add strcmp H.J. Lu
2018-06-12 22:20 ` [PATCH 20/20] libcpu-rt-c/x86-64: Add strrchr H.J. Lu
2018-06-12 22:20 ` [PATCH 06/20] libcpu-rt-c/x86-64: Add memcpy, memmove and mempcpy H.J. Lu
2018-06-12 22:20 ` [PATCH 01/20] Initial empty CPU run-time library for C: libcpu-rt-c H.J. Lu
2018-06-12 23:21 ` Joseph Myers
2018-06-13 11:21 ` H.J. Lu
2018-06-12 22:20 ` [PATCH 11/20] libcpu-rt-c/x86-64: Add strchr H.J. Lu
2018-06-12 22:20 ` [PATCH 16/20] libcpu-rt-c/x86-64: Add strnlen H.J. Lu
2018-06-12 22:20 ` [PATCH 15/20] libcpu-rt-c/x86-64: Add strcat H.J. Lu
2018-06-12 22:20 ` [PATCH 17/20] libcpu-rt-c/x86-64: Add strncat H.J. Lu
2018-06-12 22:20 ` [PATCH 14/20] libcpu-rt-c/x86-64: Add strlen H.J. Lu
2018-06-12 22:20 ` [PATCH 10/20] libcpu-rt-c: Don't use IFUNC memcmp in init_cpu_features H.J. Lu
2018-06-12 22:20 ` [PATCH 19/20] libcpu-rt-c/x86-64: Add strncpy H.J. Lu
2018-06-12 22:20 ` [PATCH 18/20] libcpu-rt-c/x86-64: Add strncmp H.J. Lu
2018-06-12 22:20 ` [PATCH 13/20] libcpu-rt-c/x86-64: Add strcpy H.J. Lu
2018-06-12 22:20 ` [PATCH 05/20] libcpu-rt-c/x86-64: Add memcmp H.J. Lu
2018-06-12 22:20 ` [PATCH 09/20] libcpu-rt-c/i386: " H.J. Lu
2018-06-13 6:50 ` [PATCH 00/20] RFC: Add the CPU run-time library for C Florian Weimer
2018-06-13 10:14 ` H.J. Lu
2018-06-13 12:03 ` Adhemerval Zanella
2018-06-13 12:31 ` H.J. Lu [this message]
2018-06-13 13:25 ` Florian Weimer
2018-06-13 13:41 ` H.J. Lu
2018-06-13 14:20 ` Siddhesh Poyarekar
2018-06-18 13:42 ` Florian Weimer
2018-06-19 8:20 ` Siddhesh Poyarekar
2018-06-18 17:09 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMe9rOqf5Na4zBW4kbprcOBRdjhnOydps9n5W7K196ORPC0j9g@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).