From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3647 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Thinking about release Date: Sun, 14 Jul 2013 23:25:37 -0500 Message-ID: <1373862337.1776.3@driftwood> References: <20130711033754.GL29800@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1373911578 8618 80.91.229.3 (15 Jul 2013 18:06:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Jul 2013 18:06:18 +0000 (UTC) Cc: musl@lists.openwall.com, Andre Renaud To: musl@lists.openwall.com Original-X-From: musl-return-3651-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 15 20:06:20 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UynAB-0001WJ-EF for gllmg-musl@plane.gmane.org; Mon, 15 Jul 2013 20:06:19 +0200 Original-Received: (qmail 6069 invoked by uid 550); 15 Jul 2013 18:06:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 6060 invoked from network); 15 Jul 2013 18:06:17 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=x5zoJZFqnLrlt07/HYCPvr9OvAYM38VlSeQoGKJr5LI=; b=HJA4XAoUe9fbQsjp+GB5KI2rRhl0oTPtIrmA5qaAO2bFmDteDS2yRtEx1pol61uKsN bbOgnQ9TwbAeL9m/rLGzPuvSKRJe/w2+/EQ/bBpvsdC1I4zlYOc+CnHTAS9kWmQLCZas 6nb2+073gtSH3jf8RtPoGugDdi58duZT4BiKsrb48so3dut8g+6rxwe8zttq5D6M5f3e 9/aaLgsm0hTKwapi2VFraitZtQMkZBi78HC50KGriaDM4SgUG/X9SRYShofBq+afSIGL kIL8VTsduqGv2GLMzRiwaR0z+YYiwBU7I30AW/Fm+IqZ+lHpgaDZIK1vYqrQyFfWf5F+ WlBg== X-Received: by 10.50.16.8 with SMTP id b8mr7915359igd.1.1373911565152; Mon, 15 Jul 2013 11:06:05 -0700 (PDT) In-Reply-To: <20130711033754.GL29800@brightrain.aerifal.cx> (from dalias@aerifal.cx on Wed Jul 10 22:37:55 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQnKUNdwEz7rSfBLWH7xdaVtAoGCX2vAUSEpnnqtz7zUahRIz8GdgkQWorxOd9IX3IfTPIsG Xref: news.gmane.org gmane.linux.lib.musl.general:3647 Archived-At: On 07/10/2013 10:37:55 PM, Rich Felker wrote: > On Thu, Jul 11, 2013 at 10:44:16AM +1200, Andre Renaud wrote: > > > This results in 95MB/s on my platform (up from 65MB/s for the =20 > existing > > > memcpy.c, and down from 105MB/s with the asm optimised version). =20 > It is > > > essentially identically readable to the existing memcpy.c. I'm not > > > really famiilar with any other cpu architectures, so I'm not sure =20 > if > > > this would improve, or hurt, performance on other platforms. > > > > Reviewing the assembler that is produced, it appears that GCC will > > never generate an ldm/stm instruction (load/store multiple) that =20 > reads > > into more than 4 registers, where as the optimised assembler does =20 > them > > that read 8 (ie: 8 * 32bit reads in a single instruction). I've =20 > tried >=20 > For the asm, could we make it more than 8? 10 seems easy, 12 seems > doubtful. I don't see a fundamental reason it needs to be a power of > two, unless the cache line alignment really helps and isn't just > cargo-culting. (This is something I'd still like to know about the > asm: whether it's doing unnecessary stuff that does not help > performance.) You're going to hit bus bandwidth at some point, and that's likely to =20 be a power of two. > > various tricks/optimisations with the C code, and can't convince GCC > > to do more than 4. I assume that this is probably where the =20 > remaining > > 10MB/s is between these two variants. >=20 > Yes, I suspect so. One slightly crazy idea I had was to write the > function in C with just inline asm for the inner ldm/stm loop. The > build system does not yet have support for .c files in the arch dirs > instead of .s files, but it could be added. Does it have support for a header definining a macro containing the =20 assembly bit? > > Rich - do you have any comments on whether either the C or assembler > > variants of memcpy might be suitable for inclusion in musl? >=20 > I would say either might be, but it looks like if we want competitive > performance, some asm will be needed (either inline or full). My > leaning would be to go for something simpler than the asm you've been > experimenting with, but with same or better performance, if this is > possible. I realize the code is not that big as-is, in terms of binary > size, but it's big from an "understanding it" perspective and I don't > like big asm blobs that are hard for somebody to look at and say "oh > yeah, this is clearly right". >=20 > Anyway, the big questions I'd still like to get answered before moving > forward is whether the cache line alignment has any benefit. I'd expect so. Fundamentally what the processor is doing is fetching =20 and writing cachelines. What it does to the contents of the cachelines =20 is just annotating that larger operation. (Several days behind on email, as usual...) > Rich Rob=