This is the mail archive of the libc-alpha@sourceware.org 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] Use strlen when searching for a nul char


On 19 Apr 2016 17:27, Adhemerval Zanella wrote:
> On 19-04-2016 14:57, Mike Frysinger wrote:
> > On 25 Feb 2016 13:04, Wilco Dijkstra wrote:
> >> Remove the strchr (s, '\0') to rawmemchr optimization as using rawmemchr is
> >> a bad idea - I have a patch to add strchr (s, '\0') -> strlen to GCC7.
> >> Like strchr (s, '\0'), rawmemchr (s, '\0') appears a common idiom for finding
> >> the end of a string, however it is not the most efficient way of doing so.
> >> Strlen is a simpler operation which is significantly faster on larger inputs
> >> (eg. on x86 strlen is 50% faster than rawmemchr on strings of 1KB).
> > 
> > will there be a change in GCC to also detect rawmemchr(s,'\0') ?
> > 
> > even then, since this optimization isn't showing up until GCC7, shouldn't
> > we keep some logic here ?  i.e. transform strchr/rawmemchr(s, '\0') into
> > strlen before falling back ?
> 
> Personally I am not very found on the string2.h header and its intrinsic logic,
> which contains optimization logic that might not be true depending of the
> architecture string optimization.
> 
> Also for the specific optimization does we really need to keep pushing for 
> these specific inline implementations? I would prefer a much simple string2.h
> header than a convoluted one we have today.

i don't have a real opinion on keeping it or just tossing the whole
thing out.  but if we keep it, i think we should be adding the bits
that make sense (like my question above) rather than half-assing it.
-mike

Attachment: signature.asc
Description: Digital signature


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