From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125920 invoked by alias); 13 Jun 2018 12:31:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 125842 invoked by uid 89); 13 Jun 2018 12:31:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=market X-HELO: mail-ot0-f196.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K2xaoW/wGeNA2FkqH5FgJMcOrSCxCnQh2+WvV6pryJA=; b=DlBjVIvbw2lZGO/su2CxWiScwOidHH2x5M/jZjDh9SqiUuIXR9NCqub/JEDbYi7SON v0k+pDFTxQgKh0vqGl7jxPTVq66SxWm4fIax86hwyoUPexwY5DRN7WKtZ/EhD49cvI3p 8UF/ZRlStq8zj0+V4sbGvAQaOgsEJfsFXjN4bVPbdBA2/0T7rIXj0Omkd0nUgd4O3VHC YAli5V2fYaPueBJKmoCUsBiYu7Oxd5SQGhl1kMuDYj2pLLDQbDGyvwMXa2XaYBltrYL9 goNKR7kYqMCtFTObdVBEx5ULpMCkxiVLBYT7if0nbc6FUWnqg/N6P8KitgTuaRCh7jhO l9XQ== X-Gm-Message-State: APt69E1ufAc1eqXnnWuWAqIxO+VV04dykH6R+t43TuDUlzuieTxSNReo QWS7U5mI4RY+2Bw3vizZeUPWS5oSkAqTwvLR9Qk= X-Google-Smtp-Source: ADUXVKLqPDVxpF39XeFOgv/euyB4+pInZLbUHctZwEZsTdPIhutt0fskgOk/Qs6/DRFYDEvPOUiRNX4GsayOXZlfwCE= X-Received: by 2002:a9d:2a25:: with SMTP id t34-v6mr2740099ota.204.1528893081227; Wed, 13 Jun 2018 05:31:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180612221939.19545-1-hjl.tools@gmail.com> From: "H.J. Lu" Date: Wed, 13 Jun 2018 12:31:00 -0000 Message-ID: Subject: Re: [PATCH 00/20] RFC: Add the CPU run-time library for C To: Adhemerval Zanella Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-06/txt/msg00306.txt.bz2 On Wed, Jun 13, 2018 at 5:03 AM, Adhemerval Zanella wrote: > > > On 13/06/2018 07:13, H.J. Lu wrote: >> On Tue, Jun 12, 2018 at 11:50 PM, Florian Weimer 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.