From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117752 invoked by alias); 13 Jun 2018 12:03:42 -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 117637 invoked by uid 89); 13 Jun 2018 12:03:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=distribute, HX-Received:sk:u6-v6mr, HX-Gm-Message-State:APt69E2, HX-Received:7906 X-HELO: mail-qk0-f194.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Y9PdBgsbJwV3Y9EYrR6UzsZQl6DfFuC/Drg+E8mkac8=; b=XvxdOzmNrtrhdvdgkF42EZRlZ9jtiOUivGutECQRXQ6GgOkhr8o9f5qPwzGETZt+UZ 6BEvYA49o63+uMCi4ZysmSIHdtrONK9UZddBgK+1oqZiaXdDd6s7KeaNk6yESWvdFwoT MbChNb1iYB2lBZ6E6eBasR5wHfk5GsSEeujvgTW0SWLaWYIBwVqwED11O8H9gjKwfV0+ 67IO2hdhLfKdaE7lQCT3mBK+Rm0afsa7qna3HivUn34thcrvZ+cVAa8VWvmg/+MFUrhi xI0FwDXGYls3n2gHmeBd6zU2ty3BF/3Brihpi2Mpn4/DR/umQR2L3X7WZ74gPDtfZqDJ VWTg== X-Gm-Message-State: APt69E2/0531qKxZQ25L6VQO7AgoDgFO6dCEUE7VvItN03Mof2AnJb8l Tf5l2bhhFn3C3IxwcftwKXvbj5WOODw= X-Google-Smtp-Source: ADUXVKK5PT24U5E+HeT68YdDiYAs6hcc9P7yPMzDZFHA0+M6S98LAdFMDHIiutu2v9d9+rSI/gxM1w== X-Received: by 2002:a37:7906:: with SMTP id u6-v6mr773873qkc.195.1528891416619; Wed, 13 Jun 2018 05:03:36 -0700 (PDT) Subject: Re: [PATCH 00/20] RFC: Add the CPU run-time library for C To: libc-alpha@sourceware.org References: <20180612221939.19545-1-hjl.tools@gmail.com> From: Adhemerval Zanella Openpgp: preference=signencrypt Message-ID: Date: Wed, 13 Jun 2018 12:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00305.txt.bz2 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 (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.