Status of strchr

[Ondřej Bílka]

On Wed, Aug 14, 2013 at 11:46:23AM +0400, Liubov Dmitrieva wrote:

A problem here is that my 64-byte loop is after 512 characters fastest
but there is big constant overhead that makes 16-byte loop better at
that interval.

It is partially caused by that I did not do much tuning to this
implementation. I wrote strchr_new_v2 that decreases overhead somewhat
but it has a catch.


It is possible, other variant is to write header that does not use
unaligned loads. 

It is not only problem of atom but also for old athlons a no-bsf variant
looks 10% faster than what is selected and my improvement.
http://kam.mff.cuni.cz/~ondra/benchmark_string/athlon_x2/strchr_profile/results_gcc/result.html

A silvermont is problematic as problem looks to be in loop overhead. One
possibility is wait how optimized can 64-byte loop be.

A second possibility is also try a 32-byte loop and see how it fares.


This test stresses implementation with code that trashes instruction
cache, branch target buffer... These factors matter when a function tends 
to be called rarely.

As for strchr I think that increase of code size is worth the cost.

We will see.

Also a catch of optimized implementation that I mentioned earlier is
that performance is sensitive to scheduling. I spend lot of time figure
out why a optimized implementation is about 5% slower on big
sizes(switch to block mode) on amd processors. It turned out that
unoptimized version was aligned to 8 bytes but not 16. This leads to
scheduling that is faster than when it is aligned to 16 bytes as I my
strchr_new_v2 does.

Ondra