DATA-ORIENTED DESIGN The hardware will thank you.
If you wish to submit an article, please contact email@example.com for details.
Some people optimise code by guesswork, which is possibly why a lot of people recite "premature optimisation is the root of all evil". There is no good way past the obvious platform specific hints to optimise a codebase unless you first know how much time is being spent where. You must profile. You must gather data.
In these posts by Drew Thaler evidence is used to find the real culprit. Without evidence, in both cases, the assumptions would have blocked the real reason from sight forever.
Never profile by framerate, you need to know how long your code takes, not the reciprocal. One more tool in your belt when analysing the data, figure out if you want to know about X, or 1/X, which is more pertinent?
Data Oriented Design relies on data, so unless you have tools and techniques for doing just that, you're working blind. Here is a post by Sean Houghton on how he analyses data from play sessions.
The analysis of telemetry can have similarities to aspects of tuning for your data. Sometimes you can only make the necessary mental connections by finding new ways to visualise what's really going on. The more chances you give yourself to recognise patterns, the higher the chance you can find out something very useful.
Pipelined CPUs don't like branching, here are a few techniques for reducing the branch count in code in general.
This time, why branches can be dangerous performance black holes, and how to remove them. As with most articles by Tony Albrecht this article features evidence that backs up the claims. A good example for others in how to present convincing arguments in their posts.
Vectors in registers should be allowed to stay there.
Load Hit Store is never as annoying as when it makes your awesome vector based code suddenly fall apart. Subjecting a 4 element vector to a single element adjustment seems like such a small thing, hopefully this article by Jaymin Kessler will help you realise that you miss the cache so much that you cry yourself to sleep every night with a picture of it under your pillow.
This post on the UNIX philosophy talks about how effective decoupling the stages of a pipeline can be, how it adds flexibility, modularity, and testability.
What is not mentioned is that this way of processing data applies at all levels, even down to your logic code that drives your render calls. Games are databases with highly complex query functions, and investing time in understanding how to drive a complex query through combinations of transforms and intermediate results such as this art pipeline example, can lead to more flexible, modular, and testable game code.
Aliasing, what it is and how to avoid it.
AltDevBlogADay by Julien Hamaide.
Angry, Intolerant, Snarky, Patronising, and Right 09/11/2011:11:40:57Typical C++ Bullshit: by Mike Acton
A brain dump on data-oriented design, many pointers to things to keep in mind and some top tips on the stages you go through when optimising for hardware.
This post by Michael A. Carr-Robb-John, veteran games coder presents some of his own components. Component oriented entity systems are some of the more likely patterns you'll see cropping up in data-oriented design.
Cache oblivious code is not ignorant, just not dependent.
So, keep in mind space filling curves and binary reflected gray code as possible access patterns to your data to maximise cache hits when you don't even know the target hardware spec.
These access patterns shuffle back and forth over similar addresses so are much more likely to hit items in the cache even without tuning for the specific platform. You trade off in readability, but it does mean that you can turn the code into a black box as even future hardware releases are likely to benefit from this design choice.
Most data-oriented development should consider the case for parallelism, and this talk by computer science veteran Guy Steele provides inspiration for parallelising seemingly inherently serial algorithms, and also mentions pitfalls that can cause trivially parallel operations to turn into high latency serial operations.
We have Noel Llopis to thank for his Game Developer article that coined the term Data-Oriented Design:
Pitfalls of Object Oriented Programming 08/11/2011:12:58:50The Article, by Tony Albrecht that brought it to everyone's attention:
Stop looking at the code, look at what happens to the data 08/11/2011:12:10:34#AltDevBlogADay post from one of the internet's most helpful low level programmers, Fabian Giesen.
When you are looking at data, values, access patterns and the like, there are some things you need to keep in mind when building your better solutions. This seris of posts will be about things that you should keep in mind, from how to utilise the cache, to what opcodes are so slow it's actually better to have a lookup table*
Item 1: write combining:
*it's never better to have a lookup table.