This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Use strlen when searching for a nul char
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Joseph Myers'" <joseph at codesourcery dot com>, <pinskia at gmail dot com>
- Cc: "GNU C Library" <libc-alpha at sourceware dot org>
- Date: Wed, 7 Oct 2015 17:39:57 +0100
- Subject: RE: [PATCH] Use strlen when searching for a nul char
- Authentication-results: sourceware.org; auth=none
- References: <003a01d1010c$ad404240$07c0c6c0$ at com> <5F638E7C-B8BD-4F94-8278-1F8B359CACCA at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1510071505450 dot 29388 at digraph dot polyomino dot org dot uk>
> Joseph Myers wrote:
> On Wed, 7 Oct 2015, pinskia@gmail.com wrote:
>
> > > On Oct 7, 2015, at 7:30 AM, Wilco Dijkstra <wdijkstr@arm.com> wrote:
> > >
> > > Expand strchr (s, '\0') in C/C++ to use strlen. This is faster on most
> > > targets as strlen is a simpler function. Passes GLIBC tests. I'm
> > > planning to do the same for strrchr, strchrnul and rawmemchr in future
> > > patches as people frequently use all of these to find the end of a
> > > string.
> > >
> > > OK for commit?
> >
> > Shouldn't this also be an optimization inside gcc if not already?
>
> I agree; I'd rather discourage the addition of such optimizations as
> inlines in glibc unless they depend on information that's inherently not
> available to GCC (e.g. properties of architecture-specific function
> implementations in glibc). As I said before in
> <https://sourceware.org/ml/libc-alpha/2015-06/msg00146.html> the aim
> should be to make the GNU system as a whole as good as possible.
Does this mean we no longer care about supporting older GCC versions
efficiently in GLIBC?
Ie. can we remove bits/string2.h and just do a trivial implementation of
the inlines in string/string-inlines.c?
> (And please accompany performance claims such as "faster on most targets"
> with figures from the benchtests or a reason it's hard to produce such
> figures. In this case I think the transformation could be justified for
> GCC as something architecture-independent without specific performance
> claims - strlen being inherently simpler because it only ever has to
> search for 0 bytes, so it should never be asymptotically slower than the
> alternative and may be faster.)
I did benchmark it of course, however the existing benchmarks don't address
constant arguments at all. Strlen is a good 2x faster than strchr on Cortex-A57
for larger sizes (for really small sizes strchr is sometimes better but that
just shows that strlen could be further improved for small sizes).
Wilco