[boost] Re: Raw Array Classes

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-09-03 12:12:12

> My notes have his graphs indicating a 2X performance improvement
> when using the Blitz++ to C translator, compared to using 
> vanilla templates.

To me, that sounds like the current crop of C++ compilers just don't have
adequate optimizers (well, we know they all fall down in one area or
another).  Since templates have become sort of standard only lately, I guess
I'm not too surprised that most C++ compilers don't optimize them well.  But
there shouldn't be any reason they *couldn't*, if the compiler writers would
focus their attention on the problem.  The mere fact that the guys at
Argonne could write such a translator and get a 2X performance boost is
pretty well proof of that; I don't really think that the standard C++ speed
boojums like vtable overhead could be accounting for that kind of speed
loss.

BTW, on a totally different tack, last night I ran into a problem with VC++
5.0 SP3's vector<>::operator[], in which (I spent some time verifying this
at the assembler level) the operator basically functioned as an array index,
returning int-length offsets from the front of the internally-allocated
storage within vector (which happened to be contiguous in this example),
instead of the correct object reference.  I sort of suspect some form of the
acknowledged bug wherein the compiler has trouble identifying the value type
if it's a user-defined object.  According to MSDN, that's supposed to cause
a compiler error, but in my case, it compiled, then returned bogus
references which promptly crashed the app.  Apparently, it was returning
whatever sat at the sizeof(int) * index location from the front of allocated
memory as though it were an object of the correct type.  However, the
objects were considerably larger than ints.  Anyone else ever see this
behavior?  Workaround?  I ended up rewriting a fair chunk of code in a way
I'd be embarassed to show anyone at a job interview, just to get it working
<g>.