[ODE] RE: ALLOCA

[Pierre Terdiman]

> > Depends on your app, really.
>
> Depends on the compiler/library/CPU combination/compiler settings, really.

Exactly. Which one can summarize by "the app" :)

That's the message I wanted to send : despite the STL beeing "standard", its
performance depends on so many external factors one can't really say "it's
fast enough, use it" or "it's not fast enough, roll your own".

Hence statements like "I have been using it since two years without any
performance problems" are, IMHO, not very useful :)

For me, having to constantly pay attention to what the
compiler/library/CPU/etc generates (i.e. actually looking at the assembly
all the time) outweights the benefits of using a standard library. It's
especially true in places where performance matters : I don't really want to
depend on the compiler's mood that day.

> push_back() is typically not needed once your data structures are set
> up, i.e. in the realtime part of the application.

I tend to disagree. As far as I'm concerned, I don't use vectors in sake of
it. If I know at start of day how big is my vector, well, I use a simple
(C-style) array. Sometimes I even do two passes over the data, counting how
many elements I'll have, just to avoid using a vector...

I use a vector when I really can't do anything else. For example in Opcode
(to stay somewhat on topic), resizable arrays are used for collision caches,
to hold indices of touched triangles. Here, elements are added to the vector
at runtime, and if you're not careful about that (e.g. using unwrapped STL
vectors), it's easy to end up duplicating the resizing code in all your
colliders, mainly in the middle of recursive collision calls - killing your
code cache fast.

So you can't really state that "push_back() is typically not needed in the
realtime part of the application". Depends on the app again...

> Plus, I'd first try a
> profiler to find out what CPU time percentage my push_back()'s _really_
> consume.

Yes. It certainly won't be noticeable in all cases. In our particular case,
it was a relatively big speed hit.

> Hmmm...  This compiler is about 6 years old and not very well-reputed
> for it's C++ standard library.

Certainly, but it's also one of the most commonly used ones - and the one we
use (latest service pack, yes). Anything that doesn't work on VC++ 6 is
unlikely to become very popular....

> Wouldn't you want to try a recent
> compiler with full optimization turned on?

I don't really feel like porting all my code to VC7, which is (IMHO) very
very painful to use. I also doubt the problem will disappear with another
compiler : this is a theoretical problem with templates. By nature they
inline almost everything, and what VC++ generates here is actually
"correct".

Anyway this is probably a topic for Sweng, not ODE.

Pierre