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] Improve bench-strstr

Hi Carlos,

>On 10/29/18 11:48 AM, Wilco Dijkstra wrote:
>> Improve bench-strstr by using an extract from the manual as the input
>> to make the test more realistic.  Use the same input for both found and
>> fail cases rather than using a memset of '0' for most of the string,
>> which measures performance of strchr rather than strstr.  Add result
>> checking to catch potential errors.  Remove the repeated tests at slightly
>> different alignments and add more large needle and haystack testcases.
> Can you expand a bit more on the theory behind this change?
> I can understand the desire to use english language text as the input
> for strstr to ensure that the microbenchmark performance more closely
> matches that which might be found parsing real English text.

Yes, the idea is to use character occurrence frequencies that are similar to 
actual uses rather than some synthetic string with a highly improbable
distribution (which also makes half the benchmark tests useless).

> I can also understand a desire for large needle and haystack testscases.

Yes, and we actually use the long needle code.

> Why are we adjusting MIN_PAGE_SIZE?

This is needed if you want the buffers to be a bit larger. It seems to reserve
only 2 pages by default, but that could mean only 2 512 byte pages rather
than a known fixed amount as required by many of the benchtests.

> Why do we remove tests at differing alignments? I presume that this
> kind of alignment based test is to catch cases where the algorithm
> performs poorly or expects certain alignments, or again performs poorly
> when crossing page boundaries. Why would we remove it from this specific
> test?

Unlike block based functions like memcpy, strstr is byte oriented, so there is
no alignment sensitivity. Obviously it calls some other string functions, but
those alignments are random and unrelated to the initial alignment.

In general alignment is way overrepresented: traces show strings are often 
aligned (far more than you'd think due to globals, alloca and malloc overaligning), 
and even if there is alignment sensitivity, the exact alignment doesn't matter at all
(beyond it's not aligned). So all the combinations of alignments are wasted effort
and just clutter the results.


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