Tips from Tricks of Windows Game Programming Gurus

[kryton9]

I am reading Tricks of the Windows Game Programming Gurus and the author André Lamothe mentions some tips that surprised me somewhat and I wondered if these would apply to our programs in thinBasic. This book was written 9 years ago, so a lot has changed in hardware also, so I was wondering how relevant this info would be today:

1. Don’t be afraid to use global variables. Parameter passing in time critical areas is not good.
2. Use inline functions. (I know this can only apply to compiled c/c++ type apps, but wanted to mention it.
3. Always use 32-bit variables rather than 8- or 16-bit.
4. Program in a RISC-like (Reduced Instruction Set Computer) manner. He mentions to break things into nice simple steps and not to combine multiple
expressions into one.
5. Use binary shifts for simple multiplication and Division of integers by powers of 2.
6. Don't write a lot of complex data structures for simple objects. Use arrays where you can instead of anything more complex.
7. Don't go class and overloading crazy. No more than one inheritance level. (This surprised me as it seems at Epic Games, they really do class at many levels)

[ErosOlmi]

Well, I'm not an expert on Gaming creation but is seems the list of advices are related to the fact 9 years ago CPU and GPU were quite slow compared to today's beasts so all mentioned indications try to improved programs execution speed.

Today, no one cares about programming details aimed to reduce CPU usage unless you are creating Gaming Engines or mission critical applications.

Instead: code cleaning, code optimization, performance execution is one of the nice aspects of computer programming. Reviewing your own code after some month optimizing it for speed execution, simplification adding more clever comments is one of my passions.

[Michael Clease]

Today, no one cares about programming details aimed to reduce CPU usage unless you are creating Gaming Engines or mission critical applications.



Thats the problem people dont worry about how fast code is anymore, they use the excuse "well CPU's are so fast these days it doesnt matter".

I believe it does, that makes me old school then I guess.

[Charles Pegge]

Hi Kent,
here is my take on these rules - assuming we are dealing with compiled code. With interpreted code, (the rules may be different - with best results being obtained by using the highest levels available and least amount of script.)

Clocks are notional since the latest Intel chips do many instructions in half clocks. CPU Registers can also work in parallel. But they give some indication of CPU workload.



1. Don’t be afraid to use global variables. Parameter passing in time critical areas is not good.


Cost: 1-2 clocks for every 32 bits of parameter being loaded onto the stack




2. Use inline functions. (I know this can only apply to compiled c/c++ type apps, but wanted to mention it.


Cost: 2 clocks allowing for call and return




3. Always use 32-bit variables rather than 8- or 16-bit.


They all have the same loading time as long as they are within a 32bit frame. If variables straddle 2 frames then two fetch cycles will be required.




4. Program in a RISC-like (Reduced Instruction Set Computer) manner. He mentions to break things into nice simple steps and not to combine multiple expressions into one.


Avoids extra stack work managing nested expressions and operator precedence (min 4 clocks per nesting.)




5. Use binary shifts for simple multiplication and Division of integers by powers of 2.


Multiplication is very efficient these days but big savings to had with division which may take up to 50 clocks.




6. Don't write a lot of complex data structures for simple objects. Use arrays where you can instead of anything more complex.


Simple data structures are best. Array indexes often have to be calculated, whereas data elements are simple offsets from a base address and cost nothing.




7. Don't go class and overloading crazy. No more than one inheritance level. (This surprised me as it seems at Epic Games, they really do class at many levels)


Should not make any difference if all the object mappings are resolved at compile time.

Conclusion: biggest saving is to avoid long division wherever possible :)

[kryton9]

Thanks Charles lots of cool info.

I am glad multiplication now a days is faster and no need, this way when you see the shift operators you know right away they will be for division, that is really going to be nice.

One question, what do you mean by simple data structures as opposed to arrays? You mean structs? I thought the array was the simplest form as he was comparing that to powerful linked lists in the rest of the paragraph? Just want to make sure I get this right :)

Thanks.

[zlatkoAB]

I only can say from my expirience in my interpreter that is inline
functions faster then called functions.
regards