This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use strlen when searching for a nul char
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Mike Frysinger <vapier at gentoo dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: 'GNU C Library' <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Wed, 20 Apr 2016 15:31:03 +0000
- Subject: Re: [PATCH] Use strlen when searching for a nul char
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <DB3PR08MB008978DA72CE0E1B93BB477483A60 at DB3PR08MB0089 dot eurprd08 dot prod dot outlook dot com> <20160419175706 dot GI5369 at vapier dot lan> <AM3PR08MB0088C41881332E9D5DF94BCC836C0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com>,<20160419222134 dot GQ5369 at vapier dot lan>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 19 Apr 2016 18:01, Adhemerval Zanella wrote:
> On 19-04-2016 17:51, Mike Frysinger wrote:
> > 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.
> My idea is to cleanup the header bit a bit until we could just removei
> it. That's why I would prefer to not add any more optimization bits
> on it.
The latest string.h is already a lot smaller, and it should be feasible to get rid of
it this release. However it means removing some optimizations as not all are
useful enough to move to string.h (and/or be added to GCC):
The strdup case with a string literal is likely so rare and the possible speedup
by inlining memcpy so small (compared to the overhead of malloc) that removing
it can't make any difference.
The __strsep_*/__strok_* inlines are unlikely beneficial if we ensure small match
strings are special cased in the strsep/strtok code (which is already much faster
with the improved strpbrk and strspn).
The strncmp inline doesn't appear generally useful - do people really accidentally
write strncmp (s, "abc", 2)??? The strcmp one could be useful but it's better done
inside GCC based on target preferences and whether it is an equality comparison.
That leaves mostly defines like this:
# define strncpy(dest, src, n) __builtin_strncpy (dest, src, n)
I believe these have no benefit so can be removed completely.
If we can agree on this then string2.h can be removed completely!