[boost] Re: Raw Array Classes

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-09-01 19:56:37

> The URL I have is : http://monet.uwaterloo.ca/blitz/
> but it seems to be down currently. I do know what you mean 
> about being viewed as
> a troublemaker.
> I insist on using the standard C++ library wherever possible 
> instead of the
> preferred in-house use of MFC. I detest MFC and try to never 
> use it. Recently,
> however, my decision was vindicated when a large client 
> expressed concern over
> some code that we were licensing them - they wanted to make 
> sure it used
> portable code - specifically STL over MFC as they are on a 
> different platform
> than us.

I don't blame you.  When I first found out how MFC manages to fake classes
into the Windows messaging scheme, I was aghast.  It basically violates
every maxim about data-hiding and encapsulation.  But then, there aren't
many other ways to get the Windows API wrappered in C++, since it was never
written with OOP in mind.
> 
> I myself haven't used blitz but I have heard great things 
> about it, and was
> interested in how it would compare up for the stuff you are 
> doing, and if it was
> even appropriate for that.
> 
> Do you really see a great speedup by hand-coding the assembler ?

Depends on the routine, and on how well I've optimized it in C/C++ before
deciding to convert to assembler.  It's a major pain in the bootie, and
maintenance can be a nightmare, but for some core routines that get executed
a lot you can really get a major boost by taking advantage of pipeline
optimizations, cache prewarming, and special knowledge you have about your
data and code that the compiler optimizer can't know.  But it takes about
ten times as long to achieve that kind of optimization, so you only do it to
routines that really need it.  For me, that tends to be 3D graphics,
advanced physics modeling, and number-intensive AI.  For other stuff,
there's not usually much point, at least in the kind of code I write.  For
people like Andy Glew, I'd think it would come in handy in other areas,
given what he's said about his code.  Depends on where your code spends all
its time.  Plus how weird you're willing to make the code look <g>.  Often,
the obvious data layouts are the poorest performing in terms of cache usage,
and you'll get lots better results by reverting to something really
primitive-looking.