This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] benchtests: New strlen-struct benchmark
On 08/08/2018 09:13 PM, Wilco Dijkstra wrote:
So my first question is, what are you trying to benchmark here?
The strings are all identically sized so it won't stress strlen. The
layout of the structs and strings is such that it ends up as one linear
sweep of memory (which any prefetcher should be able to spot).
Would better results on this test mean real code gets faster too?
Yeah, I added a larger padding in the struct to make the access stride a
bit uneven, but I suspect some prefetchers may still be able to do
something useful with it. I played around with the string and list
lengths to stabilize the benchmark numbers further, but I suppose stable
numbers don't necessarily mean useful numbers.
If you want to benchmark strlen in a more realistic way then it would
make sense to do something like the random memcpy (create an
array of strings based on a measured distribution and ensure the
strings are not laid out linearly in memory).
If you have a specific workload you want to mimic then it may be
better to keep it closer to the original code. Traversing a linked list of
10000 entries with 32KB strings seems quite unusual...
TBH I couldn't find any real workloads that use strlen that I could
emulate, which is why I did this weird attempt at emulating list
traversal. I was trying to stay away from inventing my own size
distribution because it becomes just another arbitrary data point that I
won't even understand fully and it's also harder to stabilize the
results; memcpy-random has that problem for example.
Do you have any specific ideas based on your experience with workloads
that you've seen in the past?
Thanks,
Siddhesh