From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23282 invoked by alias); 7 Oct 2015 16:40:09 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 23259 invoked by uid 89); 7 Oct 2015 16:40:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com From: "Wilco Dijkstra" To: "'Joseph Myers'" , Cc: "GNU C Library" References: <003a01d1010c$ad404240$07c0c6c0$@com> <5F638E7C-B8BD-4F94-8278-1F8B359CACCA@gmail.com> In-Reply-To: Subject: RE: [PATCH] Use strlen when searching for a nul char Date: Wed, 07 Oct 2015 16:40:00 -0000 Message-ID: <003c01d1011e$cda64e50$68f2eaf0$@com> MIME-Version: 1.0 X-MC-Unique: Q3Appv5mTDSTaBZMQj8zrQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-10/txt/msg00165.txt.bz2 > Joseph Myers wrote: > On Wed, 7 Oct 2015, pinskia@gmail.com wrote: >=20 > > > On Oct 7, 2015, at 7:30 AM, Wilco Dijkstra 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? >=20 > 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 > 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