High Performance With Good Design

It's often assumed that...: "Ohmygod! We have ambitious and strict performance requirements... So we'll have to throw out all the 'good design' techniques, and just do a lot of crazy CowboyCoding to make it run as fast as possible."

Now hold it there partner: Good design makes it easier to optimize for performance in those places where it really matters.

Case in point -- ACE framework and TAO CORBA server:

Highly ObjectOriented design with extensive use of DesignPatterns. It's maker, Douglas Schmidt is widely known for his lectures and articles on the use of DesignPatterns.

ACE and TAO are used in real-time applications on aircraft.

[EditHint: Feel free to precis this]

Verifiable correctness (and therefore good design) are absolutely crucial in this application (aerospace). Generally the processors should have capacity surplus to requirements, a good safety margin, so possibly the need for extreme optimization is not critical in this application, or only critical in some very localized parts of it?

My impression is that the "real time" software above operates under the constraint that its performance be predictable and very high. For example: Their IDL compiler munges the data until it can get a "perfect hash" on the methods of each interface. Thus, it can avoid hash collisions and linear search times for method lookups. -- JeffGrigg

Now if you think your silly game has to avoid all use of objects and patterns because it "has to go fast," I think you still have a few things to learn. -- AnonymousDonor

And Mr AnonymousDonor, you have a few things to learn if you think it can be done with widely available tools like C++. You may need to ThinkObjectsButWriteAssembler, at least for some of it. Have you actually ever written a 'silly game' in C++? -- JamesCrook Hmm. Now if I'd actually read what you said I'd see that you were saying just that games coders don't need to abandon ALL objects and patterns. With which I thoroughly agree..

ACE and TAO are written in C++, with objects and patterns. And they exibit high performance.

I think Mr. AnonymousDonor (AnonymousCoward?) is trying to say that game programmers should use objects and patterns. -- JeffGrigg

There are usually two contributing causes to poor performance, poor architecture and under powered hardware (either CPU or communications lines). Improving the design through refactoring will also address performance issues in the first case. In the second case, you will have to adjust your design to meet the constraints of your hardware. As a final note, reading source code is absolutely the worst way to predict performance. You can do some modeling of key areas up front to guide your initial design, but then you will have to rely on full system level tests and measurements to identify performance problems. Trying to save CPU cycles on an instruction by instruction basis is rarely effective or necessary. --WayneMack

On my current project we are using all C++ (with small amounts of assembly where absolutely necessary, and/or on the graphics chips), and this is the most well-executed and well-performing game project I have been on so far.

In my experience, OO just means more and better organization. And disorganization and messy code just creates more problems all around, in maintainability, bugginess, and performance.

It's all up to the particular programmer(s) in question, of course, and obviously OO "can be done" in C or whatever. But the time saved in using a made-for-OO language, using OO concepts, is not to be underestimated.

I've been writing games for the last 13 years, starting with pure assembler, moving to C and lately to C++.

As with most performance-critical projects though, there are a few core parts that will use up the majority of the available processing power and you have to optimize those parts heavily to compete in today's games industry. That may mean getting rid of class hierarchies, exception handling and similar constructs that create even a little overhead. But it's still possible to do most of the work in C++ and to wrap the nasty parts within good interfaces. In my company we still have to hand-optimize our graphics shaders in assembler and align memory reads/writes to hardware boundaries in order to squeeze the last bits of performance out of the machines, but the engine using those shaders and hard-optimized parts is still written in C/C++.

Mind though, we're talking PCs and the latest generation of games hardware (GameCube?, PlayStation2, Xbox) here. I would expect a GameBoy? game to include a lot more "hardcore" programming as the memory requirements are incredibly tight and performance is crucial. There's always someone who'll throw out any overhead and fine-tune his assembler and get that extra flash in there.

Then again. Even on a GameBoy? I wouldn't write the HighScore? handler in assembler.

-- AndreasAxelsson

PrematureOptimization is the root of all evil! Write your game in a highish-level language and OptimizeLater. USE A PROFILER to find the 5% of the code that matters; optimize that. There might be as much as 1% that deserves to be optimized right down to assembler. Until you ProfileTheCode? you will not know where that 1% is.

[CategoryGameProgramming]