This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH][AArch64] Optimized memset


> Ondřej Bílka wrote:
> On Fri, Jul 31, 2015 at 04:02:12PM +0100, Wilco Dijkstra wrote:
> > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up
> to 16
> > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes
> align
> > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero
> of more
> > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes
> 64 or
> > 128. STP of Q registers is used to reduce codesize without loss of performance.
> >
> > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with
> varying sizes
> > and alignment the new version is 50% faster.
> >
> > OK for commit?
> >
> I have two comments, first is that you should try same optimizations I
> did on x64.
> 
> First what surprised me is why you stop full unrolling at only 96 bytes
> as you could go upto 256 bytes and code would be still relatively small.

There is no need to unroll further as it will use the dc zva instruction
to clear whole cachelines for larger sizes.

> Then you could use trick that you could handle size 32-96 bytes and
> x-3*x range in general by using following which cuts number of branches.
> *s = c;
> *s + (size - x) / 2 = c;
> *s + size -x = c;

Yes that might be feasible as a further improvement for the next version.

> Second is to turn sizes smaller than 16 bytes branchless by using
> conditional moves to write to stack when size is smaller than constant
> for example in following way.
> 
> uint64 *p8 = size >= 8 ? s : stack;
> uint64 *p4 = size >= 4 ? s + (size & 8) : stack;
> uint64 *p2 = size >= 2 ? s + (size & 12) : stack;
> char *p1 = size ? s + size - 1 : stack;
> *p8 = c;
> *p4 = c;
> *p2 = c;
> *p1 = c;

Yes that is possible too. I'll have a look into that for the next version
after this one. That'll need real data as it would now always do 4 stores
and usually writes to the stack.

Wilco





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]