From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13886 invoked by alias); 9 Sep 2013 17:11:44 -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 13874 invoked by uid 89); 9 Sep 2013 17:11:44 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2013 17:11:44 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VJ4zz-0002v9-Lz from joseph_myers@mentor.com ; Mon, 09 Sep 2013 10:11:39 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 10:11:39 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Mon, 9 Sep 2013 18:11:37 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VJ4zw-0007uj-0s; Mon, 09 Sep 2013 17:11:36 +0000 Date: Mon, 09 Sep 2013 17:11:00 -0000 From: "Joseph S. Myers" To: Will Newton CC: "libc-ports@sourceware.org" , Patch Tracking Subject: Re: [PATCH v3] ARM: Improve armv7 memcpy performance. In-Reply-To: Message-ID: References: <522D977E.2000906@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-09/txt/msg00072.txt.bz2 On Mon, 9 Sep 2013, Will Newton wrote: > I believe the glibc memcpy benchmark is not capable in its present > form of showing the difference between this version of the code and > the current one: > > 1. The variety of alignments benchmarked is not adequate > 2. The variability of the benchmark results is quite high (more runs > required and page allocation issue) > 3. The output of the benchmark contains no measure of variance > 4. There is no means of showing graphically the output of the > benchmark (for subtle differences this is necessary IMO) Please make sure the wiki todo list includes all these areas for improvement of the benchmarks. > These are all surmountable problems but I would rather not gate > acceptance of this code on a satisfactory resolution of the above > issues. I can provide output from the cortex-strings benchmark quite > instead though. If your summary of the benchmarking discussion indicates that the existing glibc benchmark is not relevant for the cases addressed by the patch, then it's indeed appropriate to give such results from another benchmark. -- Joseph S. Myers joseph@codesourcery.com