From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13477 invoked by alias); 3 Sep 2013 19:54:24 -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 13465 invoked by uid 89); 3 Sep 2013 19:54:24 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Sep 2013 19:54:24 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r83JsCFG031185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Sep 2013 15:54:13 -0400 Received: from [10.3.113.109] (ovpn-113-109.phx2.redhat.com [10.3.113.109]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r83JsBnt000763; Tue, 3 Sep 2013 15:54:11 -0400 Message-ID: <52263E63.2080301@redhat.com> Date: Tue, 03 Sep 2013 19:54:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Ryan S. Arnold" CC: Will Newton , "libc-ports@sourceware.org" , Patch Tracking , =?UTF-8?B?T25kxZllaiBCw61sa2E=?= , Siddhesh Poyarekar Subject: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance. References: <520894D5.7060207@linaro.org> <5220D30B.9080306@redhat.com> <5220F1F0.80501@redhat.com> <52260BD0.6090805@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00028.txt.bz2 On 09/03/2013 03:31 PM, Ryan S. Arnold wrote: > On Tue, Sep 3, 2013 at 11:18 AM, Carlos O'Donell wrote: >> We have one, it's the glibc microbenchmark, and we want to expand it, >> otherwise when ACME comes with their patch for ARM and breaks performance >> for targets that Linaro cares about I have no way to reject the patch >> objectively :-) > > Can you be objective in analyzing performance when two different > people have differing opinions on what performance preconditions > should be coded against? No. > There are some cases that are obvious.. we know that from pipeline > analysis that certain instruction sequences can hinder performance. > That is objective and can be measured by a benchmark, but saying that > a particular change penalizes X sized copies but helps Y sized copies > when there are no published performance preconditions isn't. It's a > difference in opinion of what's important. I agree. The project needs to adopt some set of performance preconditions and document them and defend them. If we can't defend these positions then we will never be able to evaluate any performance patches. We will see-saw between several implementations over the years. 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. > PowerPC has had the luxury of not having their performance > pre-conditions contested. PowerPC string performance is optimized > based upon customer data-set analysis. So PowerPC's preconditions are > pretty concrete... Optimize for aligned data in excess of 128-bytes > (I believe). We should be documenting this somewhere, preferably in a Power-specific test that looks at just this kind of issue. Documenting this statically is the first, in my opinion, stepping stone to having something like dynamic feedback. >> You need to statistically analyze the numbers, assign weights to ranges, >> and come up with some kind of number that evaluates the results based >> on *some* formula. That is the only way we are going to keep moving >> performance forward (against some kind of criteria). > > This sounds like establishing preconditions (what types of data will > be optimized for). I agree. We need it. > Unless technology evolves that you can statistically analyze data in > real time and adjust the implementation based on what you find (an > implementation with a different set of preconditions) to account for > this you're going to end up with a lot of in-fighting over > performance. Why do you assume we'll have a lot of in-fighting over performance? 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. Then we come upon the tunables that should allow some dynamic adjustment of an algorithm based on realtime data. > 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? Cheers, Carlos.