From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6911 invoked by alias); 3 Sep 2013 23:29:26 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 6899 invoked by uid 89); 3 Sep 2013 23:29:26 -0000 Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Sep 2013 23:29:26 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: popelka.ms.mff.cuni.cz Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id DE712500CC; Wed, 4 Sep 2013 01:29:18 +0200 (CEST) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id B1ABF5F822; Wed, 4 Sep 2013 01:29:18 +0200 (CEST) Date: Tue, 03 Sep 2013 23:29:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: "Ryan S. Arnold" Cc: Carlos O'Donell , Will Newton , "libc-ports@sourceware.org" , Patch Tracking , Siddhesh Poyarekar Subject: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance. Message-ID: <20130903232918.GB7148@domone.kolej.mff.cuni.cz> References: <520894D5.7060207@linaro.org> <5220D30B.9080306@redhat.com> <5220F1F0.80501@redhat.com> <52260BD0.6090805@redhat.com> <52263E63.2080301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00031.txt.bz2 On Tue, Sep 03, 2013 at 03:56:29PM -0500, Ryan S. Arnold wrote: > On Tue, Sep 3, 2013 at 2:54 PM, Carlos O'Donell wrote: > > The current set of performance preconditions are baked into the experience > > of the core developers reviewing patches. I want the experts out of the > > loop. > > > > This is the clutch. > > Developers working for the CPU manufacturers are privy to a lot of > unpublished timing, penalty/hazard information, as well as proprietary > pipeline analysis tools. > One problem of those on x64 is how much are these informations complete. At least based on reading AMD optimization manuals around half of advices is inaccurate so I need to check if they hold anyway. > > At present we've split the performance intensive (or so we believe) > > routines on a per-machine basis. The arguments are then going to be > > had only on a per-machine basis, and even then for each hardware > > variant can have an IFUNC resolver select the right routine at > > runtime. > > Right, selecting the right variant with IFUNC has certainly helped > platforms that didn't use optimized libraries. This is the low > hanging fruit. So now our concern is the proliferation of micro-tuned > variants and a lack of qualified eyes to objectively review the > patches. > Not there yet, at least for AMD, where its often using ifunc to select slowest implementation. When you look at x64 benchmarks relation between asymptoticaly best and selected implementation is quite random. > > Then we come upon the tunables that should allow some dynamic adjustment > > of an algorithm based on realtime data. > > Yes, you can do this with tunables if the developer knows something > about the data (more about that later). > > >> I've run into situations where I recommended that a customer code > >> their own string function implementation because they continually > >> encountered unaligned-data when copying-by-value in C++ functions and > >> PowerPC's string function implementations penalized unaligned copies > >> in preference for aligned copies. > > > > Provide both in glibc and expose a tunable? > > So do we (the glibc community) no longer consider the proliferation of > tunables to be a mortal sin? Or was that only with regard to > configuration options? Regardless, it still burdens the Linux > distributions and developers who have to provide QA. > > If tunables are available, then trial-and-error would help where a > user doesn't know the particulars of his application's data usage. > Here auto-tuning as described in other mail would give better result. Unless there data usage would not fit any of our variants in which case a custom routine would be needed. > Using tunables is potentially problematic as well. Often testing a > condition in highly optimized code is enough to obviate the > performance benefit you're attempting to provide. Checking for feature > availability might consume enough cycles to make it senseless to use > the facility itself. I believe this is what happened in the early > days trying to use VMX in string routines. > > Additionally, while dynamically linked applications won't suffer from > using IFUNC resolved functions (because of mandatory PLT usage), glibc > internal usage of IFUNC resolved functions very likely will if/when > forced to go through the PLT, especially on systems like PowerPC where > indirect branching is more expensive than direct branching. When > Adhemerval's PowerPC IFUNC patches go in I'll probably argue for > keeping a 'generic' optimized version for internal libc usage. We'll > see how it all works together. > Those that are concerned about getting each bit of performance would recompile everything with --march=target anyway. It would be nice to select internal version based on --march. > So using tunables alone isn't necessarily a win unless it's coupled > with IFUNC. But using IFUNC also isn't a guaranteed win in all cases. > > For external usage, Using IFUNC in combination with a tunable should > be beneficial. For instance, on systems that don't have a concrete > cacheline size (e.g., the A2 processor), at process initialization we > query the system cacheline size, populate a static with the size, and > then the string routines will query that size at runtime. It'd be > nice to do that query at initialization and then pre-select an > implementation based on cacheline size so we don't have to test for > the cacheline size each time through the string function. > > This of course increases the cost of maintaining the string routines > by having myriad of combinations. > > These are all the trade-offs we weigh. > > Ryan