This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
memcpy walk benchmark [was: Hoist ZVA check out of the memset function]
- From: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, "adhemerval dot zanella at linaro dot org" <adhemerval dot zanella at linaro dot org>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- Date: Thu, 12 Oct 2017 07:24:14 +0530
- Subject: memcpy walk benchmark [was: Hoist ZVA check out of the memset function]
- Authentication-results: sourceware.org; auth=none
- References: <DB6PR0801MB20531D1099A99E5A4DF1E042834A0@DB6PR0801MB2053.eurprd08.prod.outlook.com>
- Reply-to: siddhesh at sourceware dot org
On Thursday 12 October 2017 02:50 AM, Wilco Dijkstra wrote:
> Finally we'll need to look into more detail at the new memcpy benchmarks -
> while looping through memory seems like a good idea, it appears like it
> only increments by 1. So at first sight it's still testing the exact same thing as
> the existing benchmarks - all data is always cached in L1. For memset I guess
> we're still missing a randomized benchmark based on real trace data.
That's a slightly incorrect description of the benchmark. The benchmark
walks through two buffers, one forward and one backward. While it
increments one buffer, it decrements the other. Also, it interchanges
the source and destination buffers for alternate memcpy calls.
Altogether it ends up ensuring that the L1 hit impact is significantly
reduced; the reduction in impact is proportional to the size of the
memcpy, so larger sizes would almost never hit L1.
We are indeed missing a randomized memset benchmark. I would be happy
to review one :)
Siddhesh