[ODE] RE: ALLOCA

[Mark Wayland]

Trying not to incite a flame war...

My practical experience with using STL in a commercial game on the PS2 is
...
DON'T.  Even with customized allocators, it appeared in our profiles often.
We ended up removing it completely with _much_ faster custom containers
and subsequently banned it from our run-time codebase.

Use it as much as you want for tools, just not in the run-time code :-)
To get stuff running fast, simply don't dynamically allocate.
Pick a worst case scenario and pre-allocate for that. Pretty simple.

For all those doubting their abilities to write a linked list or resizing
array,
write test suites and try to test it before putting it into production code.
If you find yourself wanting maps or other fun STL things then, really, ask
yourself why - do you really need it? For most cases the answer should be
'no'. Works very well in practise.

As Pierre says, if performance matters - disassemble, curse compiler,
re-code and repeat. After a short time, you'll start understanding how
crap compilers are and how you have to spoon feed them to get
decent performance :-)

Oh well, that's my rant over with. Sorry for the intrusion, you may go
about your business now... ;-)

Cheers,
Mark.

----- Original Message ----- 
From: "Pierre Terdiman" <pierre.terdiman at novodex.com>
To: <gwesp at gmx.net>
Cc: <ode at q12.org>
Sent: Saturday, February 28, 2004 1:51 AM
Subject: Re: [ODE] RE: ALLOCA


> > > 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
>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode