Boost logo

Boost :

From: rgarcia1771 (garcia_at_[hidden])
Date: 2001-12-27 16:26:49


--- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
> > What problems were you having with gcc-2.95.3?
>
> My small 'performance test' for instance (in attach. a fresh copy).
>
...
> > I have had some great preliminary success with KCC, but
> > more investigation of this is necessary.
>
>
> Can you elaborate on the performance with KCC ?

I received your small performance test. Thanks a lot. I ran it on a
few compilers. The example works under gcc 2.95.3, but the trick is
that you must supply "-ftemplate-depth-50" for it to compile. The
default depth of 17 isn't adequate. I will add some notes on
compiler support to the documentation.

In short, I'm finding that both KCC and gcc seem to optimize the
abstraction layer away. I haven't done anything comprehensive, but
here are my single-run results:
(note: Toon's test code times some operations with a flat C-style
array of data, then the same code using multi_array, followed by the
C-style array again).

# GCC 2.95.3 (Yellow Dog Linux (on my laptop, Powerbook G3 500Mhz)
# c++ -O2 -ftemplate-depth-50 ...
1.46
2.34
1.51

# KCC <version?> (Solaris - SunBlade 1000)
# KCC +K3 -O2 ...
1.28
1.53
1.21

# GCC 3.0.2 (Solaris - SunBlade 1000)
# c++ -O2
1.04
3.52
1.31

>
> I just saw multi-array is about to be 'reviewed'. I would suggest
that
> for multi-array, as this should be the case for any numerics
library in
> boost, performance is also evaluated before and during the review.
>

Agreed. Bear in mind that I have designed multi_array to be useful
for both numeric and non-numeric tasks that require a multi-
dimensional container. Nonetheless, performance is important,
especially for the numerics.

> Although "early optimisation is the root of all evil", performance
> issues _are_ important for the design of numeric-intensive codes
and
> thus also are important for acceptance. On the other hand we don't
need
> to be too strict : I think it would be sufficient if there is *at
least*
> one multi-platform compiler that can produce efficient code for the
> library, it does not have to super-efficient on all of course. If
one
> compiler can generate efficient code, it's a deficiency of the
other
> compilers that they are not able to generate good code and not a
> deficiency of the library.

So far it appears that two compilers (KCC, GCC) can optimize away the
abstraction layer for the most basic use of the library. I'm
especially curious to see how it fares under MSVC, but I won't have
access to it for another week.

Cheers,

ron


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk