|
Boost : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-19 08:01:21
What about loop unrolling? We added that to MPL with some success.
----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 19, 2001 4:33 AM
Subject: Re: [boost] Excessive preprocessor_test compile times
> From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> > Vesa Karvonen wrote:
> > > I'll see what can be done.
> >
> > I've checked in a change to status/compiler_status.html that
> > has links to the compile times files, which I uploaded to the
> > same place than the message files (sourceforge http).
> >
> > Please, all, have a look.
>
> hmm... It seems that most compilers have a slow preprocessor. I guess I
have
> been lucky to use compilers that all have relatively fast preprocessors.
>
> It IS possible to change the library implementation so that preprocessing
time
> is reduced. The downside is that more macros are needed. The current
version
> in the CVS uses the WHILE primitive to implement the arithmetic
operations.
> This way the macro recursion needs to be done only once. Previously ADD,
SUB
> and MUL were all implemented independently and preprocessing on some
compilers
> was clearly faster. The current implementation is significantly smaller,
which
> is why I think that it is preferable.
>
> Reducing the length of macro names could also improve preprocessing times
on
> some compilers, but I think that it should not make much difference.
>
> Another technique worth considering would be to use better algorithms
(O(log
> N) instead of O(N) or O(N*N)) to implement the arithmetic operations.
> Previously I considered it waste of time, because I thought that the range
> [0,128] was small enough so that the benefit would not be worth the
effort.
>
>
>
> Info: http://www.boost.org Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk