HEADS DOWN

[Sean C. Farley]

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 at farley.org