Date: Fri, 11 May 2007 10:35:02 +0200 From: Maxime Henrion <mux@FreeBSD.org> To: "Sean C. Farley" <sean-freebsd@farley.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, arch@FreeBSD.org, Andrey Chernov <ache@FreeBSD.org> Subject: Re: HEADS DOWN Message-ID: <20070511083502.GJ54713@elvis.mu.org> In-Reply-To: <20070510184447.H4969@baba.farley.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean C. Farley wrote: > On Wed, 9 May 2007, Bruce Evans wrote: > > >On Wed, 9 May 2007, Andrey Chernov wrote: > > > >>On Tue, May 08, 2007 at 04:37:03PM -0500, Sean C. Farley wrote: > >>> Would it be preferred to go ahead to use strlen() in preparation > >>> for a faster strlen() in the future? > >>... > >>we can use strlen() in preparation for the future. > > > >Yes, it is better to use library functions if they do (almost) exactly > >what is wanted. > > > >>> I would still use the inline'd version when counting characters > >>> while watching for an '=' character. Or should it also be changed > >>> to perform a strlen() and then a strchr()? > >> > >>Combined strlen()+strchr() will be slower in any case than single > >>loop, so better leave it as is. > > > >The compiler could in theory reduce to a single loop, but I've never > >seen one that does and would use the loop myself. > > I changed the code[1] to use strlen() and strncmp() instead of some of > my hand-built functions while keeping the strlen() + '=' function. > Would there be any other changes anybody can see need to be made? What > type of testing would be desired? The regression tests I wrote provide > a good basic test. > > In an attempt to make strlen() faster, I wrote a new strlen()[2] that > performs a trick to boost performance by searching by word then by byte > within a word to find the NUL byte. It did not compare to the speed of > the built-in strlen() in GCC, but it is twice as fast as > lib/libc/string/strlen.c. It was hard to really compare due to the > built-in code as well as what __pure does. __pure seemed to make all > versions the same speed. At some times, I really did not know for > certain which version (assembly, builtin, original, new) of strlen() I > was testing. :) Just for the record, __attribute__((pure)) tells GCC that the function's return value solely depends on the parameters passed in (and possibly global memory). That is, if you call such a function several times providing the same parameters for each call, and if it is clear that no global memory can have changed in between, then you are guaranteed to get back the same result, and the compiler can safely get rid of some calls and enable some more optimizations. There is also __attribute__((const)) which basically is like pure except that the function isn't allowed to read global memory, and thus even more calls can be removed. I think we export this one as __pure2 in FreeBSD. Note that strlen() isn't 'const' because it's passed char pointers so you could call it two times passing the same pointers, but the memory they are pointing to may have changed in between. So strlen() is only 'pure'. For the interested reader, your functions always have these properties in a pure functional programming language, which allows the compiler to do some really neat tricks such as caching the result of functions to avoid evaluating them again (memoization). Cheers, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511083502.GJ54713>