Re: [PATCH 4/* v2] Optimize strchrnul more

[OndÅej BÃlka <neleai at seznam dot cz>]

On Tue, May 26, 2015 at 01:23:36PM +0100, Wilco Dijkstra wrote:
> > OndÅej BÃlka wrote:
> > On Sun, May 24, 2015 at 06:32:14PM +0200, OndÅej BÃlka wrote:
> > > Hi,
> > > this is nontrivial optimization of string inlines.
> > > First it decreases icache pressure as you don't need strchr.
>

I addressed these in original mail but I will reply again anyway.
 
> It's not obvious to me that is the right thing to do. Generally it is best
> to use the standard C90/C99 functions rather than infrequently used
> non-standard ones. A quick grep of GLIBC shows strchr is used a lot more
> than strchrnul, and 9 targets have an optimized strchr vs 5 for strchrnul.
> 
For optimizations its often handy to introduce new specialized functions that 
are faster. Strchrnul fits that role.

Yes there will be transition period where apps will use both strchr and
strchrnul but eventually only strchrnul would be used.

As architectures thats problem that maintainers should address. I could
add _HAVE_FAST_STRCHRNUL and maintainers would enable that when they add
implementation.

Also you need to do this way as for strchr you would need do strlen if
it returns null.

> Using strchrnul also means extra work compared to calling strchr at the
> callsite (the *__r == c) as well as in strchrnul if the character is not
> found (returning NULL is easier than computing the pointer to the 
> terminating nul character).
> 
This is false. using strchrnul is one reason for this optimization.
With recent gcc since 4.9 there would be extra branch only when user
didn't check if function returns null.

gcc does simplify pattern ((*s == '\0' ? s : NULL) == NULL) 
into *s == '\0'

Then to answer that returning NULL is easier you didn't optize your
implementation enough. You should combine char mask with null mask and
have only one check instead of two separate ones for null and character.

Also you forgotten to add cost of branch misprediction. It isn't that
terrible here, character is found only 16.35% times but still
significant.

And you need to calculate index of zero byte anyway. A character could
be also found and you need to determine if character or zero comes
first.