Skip site navigation (1)Skip section navigation (2)
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>