This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Improve bench-strstr
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Thu, 21 Feb 2019 18:40:46 -0300
- Subject: Re: [PATCH v2] Improve bench-strstr
- References: <DB5PR08MB1030D1F2F1ED06B80057B849837D0@DB5PR08MB1030.eurprd08.prod.outlook.com>
On 20/02/2019 21:11, Wilco Dijkstra wrote:
> Hi Adhemerval,
>
>> The twoway_strstr is essentially the generic_strstr, I am failing to
>> see the point of replicate it on bench-strstr.c
>
> Well this goes back to the discussion about providing a meaningful baseline
> when running the string benchmarks. I'm sure you've noticed my new proposed
> strstr [1] and memmem [2] implementations which beat the existing Two-way
> by a huge factor. So it's very useful to compare the new generic strstr with the
> Two-way implementation as it was. If at some point we replace Two-way
> altogether then it would make no sense to keep it in the benchmarks.
My point is now that you added a twoway implementation on bench-strstr,
I see to no point in continue to include the generic string/strstr.c
since we also check the one libc.so provide (strstr symbol itself).
So the my suggestion is just to remove the inclusion of generic
implementation.
If we decided to use a different algorithm on strstr we add this
on bench-strstr as well.
>
> [1] https://sourceware.org/ml/libc-alpha/2019-02/msg00021.html
> [2] https://sourceware.org/ml/libc-alpha/2019-02/msg00020.html
>
> Cheers,
> Wilco
>