Re: N-Dimensional array library submission...

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