Think Objects But Write Assembler

This refers to the practice of having an OO mindset when programming in a non-OO environment.

The original reference (HighPerformanceWithGoodDesign) lists C++ as an OO language where one might have to ThinkObjectsButWriteAssembler. I don't think that this is ever necessary. If you are working in OO then do it. Not half-way. DoOrDoNot.

If your code is not fast enough, run a profiler on it. Find bottlenecks. Refactor your code to get the speed increase you need. Also consider changing compilers. The GnuCpp compiler has varying levels of optimizations it performs on the code it compiles. It will automatically un-roll loops, pool memory use (for temporary variables), etc.

See Also: ThinkObjectsAnyway

EditHint: Shouldn't some of this be refactored and moved to GrokLoops?

Un roll loops??

Un-roll loops? No wonder software today sucks. How big is your loop? If it's big, you don't save much unrolling it. If it's small, it will be cached and again, you don't save much. Mainly you just make your program bigger for no gain. If you really need it to be fast, take your loop and actually write assembler. -- AndyPierce

The benefit of unrolling loops is to prevent branch mis-predictions which take several CPU instructions to recover from.

Obviously even those who write assembler are prone to error. This is a HumanCondition?.

If you are running so close to the performance limits of your CPU that unrolling loops makes a significant difference in performance, you should not be writing in any language other than assembler (for the critical performance areas).

Assembler only if you must..

You probably should also be passing parameters via register rather than stack and keeping local variables in registers as opposed to memory (changes which will probably improve your performance much more than unrolling loops). You also need to pay close attention to your memory bus width, variable alignment in memory, and variable size to minimize fetch cycles. Basically having to work near the performance limits of your hardware stinks. You need to make a lot of things subservient to instructions per second. If it all possible, you need to specify a hardware platform which greatly exceeds the minimal needs of your application. -- WayneMack

It's usually not a case of trying to squeeze a specified performance from a fixed hardware platform rather it's a question of, given a platform, how to get more from it than competing designs do. From this perspective, it can become a fun challenge rather than a burden. In games programming, the pressure for this is commercial, for with more speed you can do more cool things that lift your product above other products.

In many (most?) projects, it makes much more sense to buy more hardware than spend time / developer effort on assembler level optimizing.

Assembler level programmers particularly need to make sure they think about overall program structure. The skills that make for an excellent optimizer of a small crucial core routine may be less useful where an overall perspective on the design structure is needed. Some people have both skills, but it is not automatic that one follows from the other.

Assembler lets one easily do tail calls and pass arguments in registers. Compared to C, factoring in small functions becomes cheaper performancewise. What do you prefer: lot of little methods written in assembler, or one big bloated C function? -- StephanHouben

So it's possible to code poorly in any language. How does that make a case for writing assembler?

CategoryOptimization