RFC: The CPU run-time library for C

[Siddhesh Poyarekar]

On 05/12/18 2:04 AM, Carlos O'Donell wrote:
> H.J. posted an early RFC in June:
> https://www.sourceware.org/ml/libc-alpha/2018-06/msg00259.html
> 
> My summary of consensus in June was:
> 
> - Suggest implementing in a distinct project: Adhemerval, Florian, Carlos.
> 
> - Request simpler design: Florian, Siddhesh.

Well my opinion was really more about glibc's build system and not this 
library; I couldn't see a viable way to have it ship even then and I 
think a lot of y'all had already made that point.

> (1) Why not an external preloadable library?
> 
> This RFC appears unchanged from the original proposal and the outstanding
> comments do not appear to have been discussed in any further detail.
> Particularly the cost/benefit ratio to the project to accept such patches
> versus a simpler mechanism. Likewise why "most" of user needs cannot be met
> by something like the ARM's cortex-strings, which doesn't need deep
> integration with glibc-specific features.

Yeah, that is a much more flexible approach.  Maybe in the medium/long 
term we could consider the idea of making this new project into a 
submodule of glibc to reduce or even avoid duplication of code.

My only concern here is fragmentation; architecture maintainers will 
need to make sure that they're syncing routines regularly.  It happens 
for arm/aarch64 currently because we're still in a state where glibc 
dictates the development to a great extent.  Once this library gets 
traction, that incentive may get lost.

> (2) Current libcpu-rt-c proposal does not meed OS vendor needs.
> 
> The present libcpu-rt-c proposal as-is is not usable by OS vendors;
> replacing the core string routines is equivalent to a library rebase
> and requires revalidation efforts by the distribution and by QE. This
> makes it *almost* as difficult to rebase and update libcpu-rt-c as it is
> to rebase and update glibc (not to mention it requires using DTS in RHEL
> to get a new-enough compiler/binutils). The other consequence is that a
> newer compiler/binutils may need a newer gdb to even be able to debug
> the code in question, and the problem is compounded. No distro that
> I'm aware of has ever delivered something like this.
> 
> OS vendors already have process to backport IFUNC and other
> improvements to stable branches, and we do this in RHEL for Intel,
> IBM, and ARM (just look at our public glibc.spec %changelog) e.g.
> - Improve libm performance AArch64 (#1302086)
> - Improve memcpy performance for POWER9 DD2.1 (#1498925)
> - Add Intel AVX-512 optimized routines (#1298526).
> - Improve performance on Intel Purley (#1335286).
> - Add support for new IBM z14 (s390x) instructions (#1375235)
> 
> If you need key routines backported, please work with your
> distribution contact to have key support backported. RHEL
> point releases happen frequently.

Agreed, this is pretty much what I said at the Plumbers last month with 
my ex-Red Hatter Fedora on.

> Therefore this proposal only adds work to upstream glibc, and
> doesn't provide customers with a supported libcpu-rt-c. At most
> it gives customers a way to improve performance by using
> libraries provided by a 3rd party. That 3rd party could equally
> deploy a custom glibc and tell the customer to use that.

Right.

> (3) Solution is too costly in terms of maintenance.
> 
> The solution lacks the simplicity of plans like --enable-math-private.
> 
> In this patch set from Florian:
> https://sourceware.org/ml/libc-alpha/2018-09/msg00368.html
> 
> We see a proposal that is much simpler for the math routines.
> In particularly building libm.so such that it is distinct from
> glibc and can be preloaded. This is easier for libm functions
> because they are so distinct from libc, but it's just an example
> of the kind of well isolated solutions which are desirable
> from upstream.

This is fine for math, but maybe not for strings because they might need 
some initialization state to work correctly (e.g. tunables) and also 
because they may get used very early.  It's solvable, but not as easily 
as math.

Siddhesh

PS: <bait>We should some day talk about going the opposite way and 
merging libpthread.so into libc.so</bait>