This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Faster strchr implementation.
- From: Liubov Dmitrieva <liubov dot dmitrieva at gmail dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 14 Aug 2013 11:46:23 +0400
- Subject: Re: [PATCH] Faster strchr implementation.
- References: <20130807140911 dot GA31968 at domone dot kolej dot mff dot cuni dot cz> <CAHjhQ926EE-MYDJR5Eftf+DUefBg-Gox0pw57vZ7XUwsO3OPJg at mail dot gmail dot com> <20130808190716 dot GA4589 at domone dot kolej dot mff dot cuni dot cz> <CAHjhQ92+C6uXyrUhTd3OWuoa6v2SeUaKLBuqaNX5Sqtn4ANBdg at mail dot gmail dot com> <CAHjhQ90S-1uBhwV44KODTcQkr=0U-P+_9Pu0O=RbYYY9e82JCA at mail dot gmail dot com> <20130809164420 dot GB4972 at domone dot kolej dot mff dot cuni dot cz>
I have some comments on the results getting from here:
http://kam.mff.cuni.cz/~ondra/benchmark_string/strcmp_profile.html
http://kam.mff.cuni.cz/~ondra/benchmark_string/strchr_profile.html
http://kam.mff.cuni.cz/~ondra/benchmark_string/strrchr_profile.html
* strrchr: As far as I understood you are suggesting to make total
clean up for strrchr removing all IFUNCs and use your new version
everywhere.
I see _no_bsf version is still better for atom for some cases. Are you
sure that cases where your version is better are more important for
atom users?
http://kam.mff.cuni.cz/~ondra/benchmark_string/atom/strrchr_profile/results_rand_L3/result.html
You links to documentation don't work and I can't to get more details
about the tests until reading the test codes.
http://kam.mff.cuni.cz/~ondra/benchmark_string/atom/strrchr_profile/results_rand_L3/doc/properties.html
* strchr: Are you suggesting to set ON slow_BSF flag for Silvermont
and use IFUNC for switching between slow_BSF and the new version,
remove sse42 version from the glibc sources?
With this, I have a concern with Haswell degradation showing by the plots:
http://kam.mff.cuni.cz/~ondra/benchmark_string/haswell/strchr_profile/results_rand_noicache/result.html
And switching slow_BSF flag on for Silvermont will impact other
functions, how are you going to resolve the dispatching here?
* strcmp: I can't agree that the new version is always better for atom:
http://kam.mff.cuni.cz/~ondra/benchmark_string/atom/strcmp_profile/results_rand_L3/result.html
http://kam.mff.cuni.cz/~ondra/benchmark_string/atom/strcmp_profile/results_rand_L2/result.html
If you are going to make total clean up and replace everything with
the new version, this probably can introduce some performance
regressions for atom customers. It is ok to replace for Haswell and
Silvermont but we can't harm atom performance.
--
Liubov