Date: Fri, 11 May 2007 18:21:09 -0500 (CDT) From: "Sean C. Farley" <sean-freebsd@farley.org> To: Maxime Henrion <mux@freebsd.org> Cc: arch@freebsd.org Subject: Re: HEADS DOWN Message-ID: <20070511181141.P9004@baba.farley.org> In-Reply-To: <20070511083502.GJ54713@elvis.mu.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> <20070511083502.GJ54713@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 May 2007, Maxime Henrion wrote: > Sean C. Farley wrote: <snip of *env discussion> >> 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). That is interesting. Compiler optimizations sure have changed a lot while I was not looking. Please correct me if I am wrong: programs compiled by GCC on FreeBSD use the builtin strlen() unless told not. If builtin strlen() is disabled, i386 will use the assembly version while all other platforms use the C version. Regardless of the version, __pure is taken into account. It seems that __attribute__((pure)) is not supported by the Intel compiler. Would my strlen() be of any use when libc is compiled with it? Sean -- sean-freebsd@farley.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511181141.P9004>