[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7d6634b-6560-07fe-6a0a-411f2f95a0f8@landley.net>
Date: Fri, 16 Sep 2016 20:40:05 -0500
From: Rob Landley <rob@...dley.net>
To: Rich Felker <dalias@...c.org>
Cc: "j-core@...ore.org" <j-core@...ore.org>, musl@...ts.openwall.com
Subject: Re: Re: [J-core] Aligned copies and cacheline conflicts?
On 09/16/2016 05:16 PM, Rich Felker wrote:
> Attached is a draft memcpy I'm considering for musl. Compared to the
> current one, it:
>
> 1. Works on 32 bytes per iteration, and adds barriers between the load
> phase and store phase to preclude cache line aliasing between src
> and dest with a direct-mapped cache.
>
> 2. Equally unrolls the misaligned src/dest cases.
>
> 3. Adjusts the offsets used in the misaligned src/dest loops to all be
> multiples of 4, with the adjustments to make that work outside the
> loops. This helps compilers generate indexed addressing modes (e.g.
> @(4,Rm)) rather than having to resort to arithmetic.
>
> 4. Factors the misaligned cases into a common inline function to
> reduce code duplication.
>
> Comments welcome.
Superficial comments first:
I know the compiler's probably smart enough to convert %4 into &3, but
given that the point is performance optimization I'd have thought you'd
be explicit about what the machine should be doing?
Both chunks of code have their own 8 register read and 8 register write
(one is 0-7, one is 1-8).
Design comments:
Instead of optimized per-target assembly, you have an #ifdef gnuc
wrapped around just under 70 lines of C code with an __asm__
__volatile__ blob in the middle, calling a 20 line C function. Because
presumably on sh this will produce roughly the same workaround for the
primitive cache architecture, only now you're doing it indirectly and
applying it to everybody.
The motivation for this is that j2 has a more primitive cache
architecture than normal these days, so it needs an optimization most
other chips don't. This is "generic" so it'll be built on
register-constrained 32 bit x86, and on 64 bit systems where it should
presumably be using u64 not u32.
And of course gcc inlines its own version unless you hit it with a brick
anyway, so solving it in musl is of questionable utility.
I'm not sure you're focusing on the right problem?
> Rich
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
