From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21699 invoked by alias); 9 Apr 2013 15:59:19 -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 21690 invoked by uid 89); 9 Apr 2013 15:59:19 -0000 X-Spam-SWARE-Status: No, score=-9.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 09 Apr 2013 15:59:19 +0000 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 r39Fx6Tq016034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Apr 2013 11:59:07 -0400 Received: from [10.3.113.93] (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r39Fx5m5031405; Tue, 9 Apr 2013 11:59:05 -0400 Message-ID: <51643AC9.2050004@redhat.com> Date: Tue, 09 Apr 2013 15:59:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Earnshaw CC: "Joseph S. Myers" , "Shih-Yuan Lee (FourDollars)" , "patches@eglibc.org" , "libc-ports@sourceware.org" , "rex.tsai@canonical.com" , "jesse.sung@canonical.com" , "yc.cheng@canonical.com" , Shih-Yuan Lee Subject: Re: [PATCH] ARM: NEON detected memcpy. References: <5163D9B8.7030008@arm.com> <51641077.4000102@redhat.com> <51642CF3.2040506@arm.com> In-Reply-To: <51642CF3.2040506@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00036.txt.bz2 On 04/09/2013 11:00 AM, Richard Earnshaw wrote: >> At present the only policy we have as a community is that faster is >> always better. > > > You still have to be careful how you measure 'faster'. Repeatedly > running the same fragment of code under the same boundary conditions > will only ever give you the 'warm caches' number (I, D and branch > target), but if the code is called cold (or with different boundary > conditions in the case of the Branch target cache) most of the time > in real life, that's unlikely to be very meaningful. Agreed, but that's what whole system benchmarking is for. We can't solve all problems at once, and we had zero benchmarking before we started this work for 2.18. Hopefully by 2.20 or 2.21 we have some kind of whole system benchmarking that allows users to monitor their system, gather data, and submit it back to the project for analysis. Cheers, Carlos.