This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH][AArch64] Optimized memcpy/memmove
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: 'Ondřej Bílka' <neleai at seznam dot cz>
- Cc: "'GNU C Library'" <libc-alpha at sourceware dot org>
- Date: Mon, 28 Sep 2015 10:35:20 +0100
- Subject: RE: [PATCH][AArch64] Optimized memcpy/memmove
- Authentication-results: sourceware.org; auth=none
- References: <002901d0f794$66138480$323a8d80$ at com> <20150927084319 dot GA22368 at domone>
> Ondřej Bílka wrote:
> On Fri, Sep 25, 2015 at 02:16:33PM +0100, Wilco Dijkstra wrote:
> > Further optimize memcpy/memmove for AArch64. Copies are split into 3 main cases: small
> copies of up
> > to 16 bytes, medium copies of 17..96 bytes which are fully unrolled. Large copies of more
> than 96
> > bytes align the destination and use an unrolled loop processing 64 bytes per iteration. In
> order to
> > share code with memmove, small and medium copies read all data before writing, allowing any
> kind of
> > overlap. All memmoves except for the large backwards case fall into memcpy for optimal
> performance.
> > On a random copy test memcpy/memmove are 40% faster on A57 and 28% on A53.
> >
>
> Looks ok on high level, I didn't inspected this patch in detail but you
> should test it with dryrun to see real impact on performance.
Thanks. I haven't looked at dryrun yet but that is on my todo list. With more accurate
stats it may be possible to tweak it a bit further.
> I would here simply alias memcpy to memmove as there is minimal
> performance impact when you do check only for sizes larger than 96
> bytes.
That is an option indeed, however the entry check for memmove takes 1-2 cycles
on most CPUs, and it means more executed branches and more I-cache footprint for
memcpy, so I'd have to be absolutely sure it doesn't slow down memcpy.
Wilco