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

[Carlos O'Donell <carlos at redhat dot com>]

On 06/12/2018 06:19 PM, 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.
>

How do you envision downstream distributions using this option?

Who does the building?

Who deploys it?

Who supports it? For how long?

You list one use so far.

Use Case 1:

- User installs RHEL7 on production Skylake systems.
- User complains to Intel about poor peformance of RHEL 7 on Skylake.
- H.J. builds libcpu-rt.so on Fedora 28 and delivers to customer.
- Customer deploys unsupported build of libcpu-rt.so on
  production systems to get performance gain.

My worry here is that no customer will want to deploy unsupported
(I don't expect you to be signing up to support customers directly)
binaries on production systems.

So in this case you need to convince distributions to do the following:

* Build and ship libcpu-rt.so on a modern version of the distribution.
* Change established practice in distributions to allow newer distribution
  packages of libcpu-rt.so to be installed in an older distribution
  (often difficult because of RPM feature dependencies, scriptlet dependencies,
  and other such dependencies).

  or

  Enhance the distribution to ship newer alternative toolchains to allow
  libcpu-rt.so to be built from alternative newer glibc sources, and then
  support that result for customers to LD_PRELOAD.

It's entirely possible that the newer alternative toolchain is a viable
option for things like RHEL which have Developer Toolset (as Florian mentions),
but as far as I know it's the only distribution doing this in a fully supportable
way.

However, for Debian they would have to look at letting an unstable package build
of libcpu-rt.so be a supported install in stable. Which would be something new.

Either way this is similar in some sense to Florian's separate-libm work to allow
libm to be built distinctly from glibc. Note that I say "similar" because it's
not the same, but tackles a similar problem of replacing parts of glibc with
newer parts which can be preloaded for applications to use without riks of
significant ABI/API deviation. The string functions, and the math functions, both
have very well defined interfaces and are candidates for just this work.

This kind of approach has actually worked well for a number of internal projects
we've worked on in the past, and has become my #1 go-to strategy for this kind
of stuff... but... and here is the "but", we never asked upstream to do it because
it's all support burden with no reward.

In closing, I think you need to prototype this in a distinct project, see how
your customers use it, and then come back with a proposal derived from real
world use cases.

Cheers,
Carlos.