Archived

This topic is now archived and is closed to further replies.

Heavy C++ use overhead

This topic is 5618 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Small question Im planning to do a heavily object oriented 3d engine. I just wanna know if using C++ specific code, like Polymorphysm, exceptions, virtual functions is viable for a 3d engine. It is REALLY slower? I know it is a bad idea to make core engine specifications as virtual functions, but for the ones that are calld less times?

Share this post


Link to post
Share on other sites
*Technically* it is slower, but unless your name is John Carmack or Mel that difference will be completely undetectable compared to all the other things slowing down your code (and frankly even John Carmack is saying good things about OO). Basically if your OO engine runs at 100fps on a GeForce4 super system, it will run at 100.05fps if rewritten to not use OO. Considering all the time you save, both in coding and in debugging (OO makes it so much easier to prevent, find and fix bugs), I would say OO is the way to go.

Share this post


Link to post
Share on other sites
It''s slower...

But I recommand you to do this.
I have a 3D engines which use many virtual functions. In 2 day I add a new platform or a new 3D API in my 3D engine.
In fact 3D engines are so complex that you can optimize many things else before to worry about latency create by virtual functions.

Good luck

Share this post


Link to post
Share on other sites
It''s slower... if used badly and in bad designs.

For example going overboard and having a CPixel class, a CVertex class and a CPolygon class all inherited from some CObject class, all with virtual accessor functions is going to get you hideous performance. But that is due to inappropriate use of the language rather than the language being slow.

If on the other hand the lowest level you get is CMesh, CMatrix etc, then it''s *extremely* unlikely it would be slower than plain C unless you''d made some bad coding/design mistake.

In fact in some circumstances you''d actually get faster code due to the compiler knowing more about the constraints on data (const correctness, aliasing etc).


Having said that, exceptions and RTTI are often best avoided since many *implementations* of them tend to add a whole bunch of extra code to make them work. The features themselves aren''t a problem though - it''s just I''ve never seen a good compiler implementation of them. STL should be fine on most platforms, though some of its memory allocation patterns in certain implementations might not suit you, particularly on some fixed memory platforms like games consoles.


[I''m only using the Cxxx naming convention to emphasise that I''m talking classes - personally I tend not to use it]


In our engine we make use of C++ features in most of the higher level code, and a few lower level parts such as:

- Maths functions (being able to do vector1+=vector2 type things is so much nicer than directly calling a C function to do it).

- Management lists/containers (lists of buffers, textures, etc). Templates and a few choice base classes can greatly simplify much code.

- Device, view, display command handling. We had a single D3D adapter encapsulated in it''s own "Adapter", making multiple Adapter classes allowed us to add multimonitor support in less than a day. (Though it was one thing thought of at the design stage)


I suppose it depends how heavy you mean. In some places for example we pass "command" structures where in a more OO world we may say use a Command pattern.

Learn the costs of each OO feature, then decide at each stage of your engine *design* "is this being called at such a high frequency that the 2 cycle overhead for XX virtual function call is going to have a negative impact". Careful design is the key to good OO/C++ and optimal use of it.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
In fact, i saw the OGRE s Engine source code, as well as its documentation, wich is an example model to follow, i think.


They made heavy use of inheritance, exceptions, and templates.

The immediate result is their code is really easy to follow and understand, all seems to be so natural.

The power of the processors, I think, is not more the bottleneck in a 3d engine. Because in ideal hardware conditions, they are only doing some physics and AI calculations, wich is, depending of the physic and AI not too costly.

well.


thanx foir the answer...


Share this post


Link to post
Share on other sites
It's not a question of OO being faster or slower. Your implementation will be the deciding factor.

Virtual functions in OO are probably faster than trying to "virtualize" your code written in C or Pascal, i.e. heavy use of switch-case, and can be easier to write and maintain.

Member functions are really no slower than passing in a pointer to a struct, and the code of your member function can be quite clean.

And with C++, you can step out of the OO realm when necessary to write time-critical, optimized code.

C++ often grabs lots of stack memory in certain circumstances involving copy operations. It's best to learn how that can happen and learn the ways to avoid it if such stack use isn't really necessary.

It's sloppy, careless use that can give C++ a bad rap, but it can be blazing fast if you use it smartly.

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.

Proxima Rebellion - A 3D action sim with a hint of strategy

[edited by - BS-er on July 24, 2002 9:56:49 PM]

Share this post


Link to post
Share on other sites
Odd thing, I saw this topic and reluctantly opened it up because I assumed that that original poster would get flamed with a bunch of uninformed, unexperienced bashings against OO in game programming.

Does this mean that the game programming community in general is finally warming to OO?


*If this gets posted multiple times I''m sorry, but I keep getting an SQL timeout error..

_____________________________________________
Come join us on IRC in #directxdev @ irc.afternet.org

Share this post


Link to post
Share on other sites
The finishing touches of DooM III were writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Where the Quake III engine has an advantage over a design like ORGE, is in cache coherency. With the OO scene-graph, you can jump all-over the memory space of the CPU each step the rendering. With Quake''s deterministic BSP trees, and flat player & projectile list, everything that the uses the same code is garuanteed to be rendered sequentially (there by minimizing CPU cache misses).
ORGE''s advantage is that it''s vastly more flexible.

Carmack also manages his memory efficently, whereas ORGE manages it''s memory automatically.

Carmack also performs extensive empirical studies to determin the optimal batching order for the rendering (seeing how grx card companies give him prototypes, this is hard to compete with).

Those three things are why the Quake engines have the highest frame-rates (along with high quality).

Share this post


Link to post
Share on other sites
The finishing touches of DooM III were writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Where the Quake III engine has an advantage over a design like ORGE, is in cache coherency. With the OO scene-graph, you can jump all-over the memory space of the CPU each step the rendering. With Quake''s deterministic BSP trees, and flat player & projectile list, everything that the uses the same code is garuanteed to be rendered sequentially (there by minimizing CPU cache misses).
ORGE''s advantage is that it''s vastly more flexible.

Share this post


Link to post
Share on other sites
no its not slow, it gets compiled into machine language! considering you cant even buy a CPU slower than 1000 mhz now at most stores, a few function pointers won''t make any difference unless you call the function a few million times a second.

So in other words, do whatever makes for an easy to use engine design and optimize your graphics instead. thats the slow part

Share this post


Link to post
Share on other sites
I would do as S1CA suggests and learn exactly what the processor is doing in each case your worried about. Sometimes the fast code is not necessarily what the advantage is, although if you do it right, you will always have code just as fast as C.

You have to remeber, like Cybertron said in a very simple way, both C and C++ get compiled into the exact same code. If you know exactly what the machine code looks like for what you are writing, you can avoid the pitfalls of, say, virtual functions. They have an advantage, and a disadvantage. Are you willing to pay for the virtual function table lookup, which is just a few machine instructions, three I think, to get the advantage of propagating to the corrent function?

Correctly architected C++ is just as fast as good C. And it has the advantages of being faster to code and more easier to do more complex architectures. Memory management is the main performance hit in programming. Learn that and the rest is pretty insignificant. Memory management is no harder in C++ than it is for C, Carmack just knows C so well, it's second nature to him. If you know C++ well enough, you can write an engine just as good as any other Carmack game.

One more thing, don't use exceptions to return common error codes like "File not found". Exceptions are just that, exceptional cases, used for terminal errors and worst case scenarios. I know not everyone agrees with this, but exceptions make modular coding a nightmare and are a huge performance hit compared to just returning an integer error code on the stack.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

[edited by - smanches on July 25, 2002 2:42:15 PM]

Share this post


Link to post
Share on other sites
Just to give you an example of how fast processors are, I did a little test the other day. What I did was put a loop that executes 20k times inside my render() function, and inside the loop, I placed about 10 asm instructions. After all that punishment, my example was running at 120fps, which, if you do that math ends up being 24 million instructions/sec. This was all going on with about 5 programs running in the background, and running on an athlon xp 1700+ (which will shortly become obsolete). Not to mention the cost of using DirectX 8.1, with app wizard code, and the fact that the loop itself uses several instructions.

Code executes fast, the only problem is with cache misses, and the dreaded page miss. If you are really that concerned about cpu overhead, I suggest you download "Code Analyser" (free - courtesy of AMD), and use it to find exactly what line of code is causing the largest performance footprint.

Share this post


Link to post
Share on other sites