DATA-ORIENTED DESIGN The hardware will thank you.
If you wish to submit an article, please contact firstname.lastname@example.org for details.
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.