This is the mail archive of the 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] 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?


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