This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/*] Generic string memchr and strnlen
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: Chris Metcalf <cmetcalf at ezchip dot com>, 'GNU C Library' <libc-alpha at sourceware dot org>
- Date: Wed, 12 Aug 2015 16:07:02 +0200
- Subject: Re: [PATCH 4/*] Generic string memchr and strnlen
- Authentication-results: sourceware.org; auth=none
- References: <20150724170425 dot GA10041 at domone> <003d01d0c63b$0080b730$01822590$ at com> <20150724191248 dot GA2889 at domone> <004201d0c873$bd3b9fe0$37b2dfa0$ at com> <20150727165642 dot GA22842 at domone> <55B67BA7 dot 7030606 at ezchip dot com> <20150727232224 dot GA21851 at domone> <004b01d0c936$5f6ed3a0$1e4c7ae0$ at com> <20150812051245 dot GA16265 at domone> <005201d0d505$78b0cd70$6a126850$ at com>
On Wed, Aug 12, 2015 at 02:47:46PM +0100, Wilco Dijkstra wrote:
> > OndÅej BÃlka wrote:
> > On Tue, Jul 28, 2015 at 02:07:35PM +0100, Wilco Dijkstra wrote:
> > > > OndÅej BÃlka wrote:
> > > > On Mon, Jul 27, 2015 at 02:42:47PM -0400, Chris Metcalf wrote:
> > > > > On 07/27/2015 12:56 PM, OndÅej BÃlka wrote:
>
> > Then could you review a generic patch that I am about to ping?
>
> Do you mean https://sourceware.org/ml/libc-alpha/2015-08/msg00443.html?
> I don't see a patch attached...
>
I wrote it long ago, here:
https://sourceware.org/ml/libc-alpha/2013-10/msg00201.html
> > > > > So I'm not sure which point you are making but unless you know
> > > > > something about the average distribution of the characters in the
> > > > > strrchr() string to suggest they are likely to occur in the last third
> > > > > of the string more than 50% of the time, I don't think I'm convinced.
> > >
> > > So what we really need is better statistics on strrchr and friends. Looking
> > > at GLIBC sources, it seems that >90% search for '/' in a path.
> > >
> > > Do you have actual stats for strrchr OndÅej? That would really help solving
> > > this issue. What I'd like to know is:
> > >
> > > 1. Average length of the strings
> > > 2. What percentage fails to match
> > > 3. Average number of matches per string if it matches at least once
> > > 4. Average relative position within string of last match
> > >
> > > With that info we could create a simple patch for bench-strrchr.c to make
> > > it use realistic inputs. Then based on that we can fix the generic code and
> > > let maintainers further tune their optimized implementations if they do not
> > > beat the generic code.
> > >
> >
> > Yes, I used dryrun for that. You don't need to model microbenchmark from
> > that data which could go wrong in several ways but use dryrun to
> > directly replay these.
>
> Still bench-strrchr.c needs to be updated to use realistic inputs so people can
> optimize for the right dataset.
depends how you do that, you could now use as benchmark
./testrun.sh dryrun/bin/bench_strrchr -u
I could sync benchmarks to use that benchmark, it depends on preference
if we use that or keep it as separate project.