From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29727 invoked by alias); 18 Apr 2013 09:39:30 -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 29717 invoked by uid 89); 18 Apr 2013 09:39:30 -0000 X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL,TW_CP autolearn=no version=3.3.1 Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 09:39:29 +0000 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 AC84D6A71D; Thu, 18 Apr 2013 11:39:23 +0200 (CEST) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 4DB746046E; Thu, 18 Apr 2013 11:39:00 +0200 (CEST) Date: Thu, 18 Apr 2013 09:39:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: Will Newton Cc: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , libc-ports@sourceware.org, patches@linaro.org Subject: Re: [PATCH] ARM: Add Cortex-A15 optimized NEON and VFP memcpy routines, with IFUNC. Message-ID: <20130418093900.GA3653@domone.kolej.mff.cuni.cz> References: <516BCEE5.9070809@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-04/txt/msg00090.txt.bz2 On Mon, Apr 15, 2013 at 11:38:49AM +0100, Will Newton wrote: > On 15 April 2013 11:06, Måns Rullgård wrote: > > Hi Måns, > > >> Add a high performance memcpy routine optimized for Cortex-A15 with > >> variants for use in the presence of NEON and VFP hardware, selected > >> at runtime using indirect function support. > > > > How does this perform on Cortex-A9? > > The code is also faster on A9 although the gains are not quite as > pronounced. A set of numbers is attached (they linewrap pretty > horribly inline). > > I forget to ask where to get benchmark source. Without it there is no way to tell if it was done correctly. You must randomly vary sizes in range n..2n and also vary alignments.