DATA-ORIENTED DESIGN The hardware will thank you.

If you wish to submit an article, please contact support@dataorienteddesign.com for details.

Lots of good resources linked from this site by Daniele Bartolini: Data Oriented Design Resources

Data-Oriented Design book (2018 version)- html with links

Data-Oriented Design book (2018 version) - PDF download (better images)

Data-Oriented Design book - 2018 paperback version (with extra chapters)

Chinese translation provided by KouZhe / Martin Cole

Data-Oriented Design book (2018 version)- html with links

Data-Oriented Design book (2018 version) - PDF download (better images)

FIRST PREV : PAGE 3 : NEXT LAST

One more reason why C++ classes can cause problems 12/11/2011:13:34:52

the static keyword has three different meanings based on how it's used.

http://coc.dev77.com/2011/10/static.html

Though this post
http://developer.amd.com/documentation/articles/pages/6212004126.aspx
doesn't appear to be written by someone who knows why these things are true, the first item:

#1. Declare as static functions that are not used outside the file where they are defined
Declaring a function as static forces an internal linkage within that file, which can improve the performance of the code. Functions that are not declared as static default to external linkage, which may inhibit certain optimizations, such as aggressive inlining, with some C/C++ compilers.

This implies that because all class member functions are global scope, they potentially suffer the same optimisation limitation. Good old C++.

Also, ignore point 5, you should always be using bitwise operators for such trivial logic.

Evidence based approaches 12/11/2011:13:26:08

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.

http://altdevblogaday.com/2011/06/14/real-unusual-io-slowdowns-part-2/
http://altdevblogaday.com/2011/07/16/real-unusual-io-slowdowns-part-3/

Take the right measurements 12/11/2011:13:14:06

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?

http://altdevblogaday.com/2011/07/23/lying-numbers/

Reading data - Understanding data 11/11/2011:10:45:57

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.

http://altdevblogaday.com/2011/06/01/balance-and-flow-maps-2/

Things to consider : #06 10/11/2011:22:00:00

Pipelined CPUs don't like branching, here are a few techniques for reducing the branch count in code in general.

http://en.wikibooks.org/wiki/Optimizing_C%2B%2B/Code_optimization/Pipeline

Performance Optimisation : Lesson 2 10/11/2011:09:18:53

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.

http://overbyte.com.au/2011/11/10/optimisation-lesson-2/

Things to consider : #05 10/11/2011:02:37:12

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.

http://altdevblogaday.com/2011/01/31/vectiquette/

The UNIX Philosophy 09/11/2011:16:31:46

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.

http://altdevblogaday.com/2011/02/04/the-unix-philosophy-and-your-pipeline/

Things to consider : #04 09/11/2011:15:01:23

Aliasing, what it is and how to avoid it.

AltDevBlogADay by Julien Hamaide.

http://altdevblogaday.com/2011/01/17/aliasing-the-silent-killer/

Angry, Intolerant, Snarky, Patronising, and Right 09/11/2011:11:40:57

Typical C++ Bullshit: by Mike Acton

http://macton.smugmug.com/gallery/8936708_T6zQX#593426709_ZX4pZu

Justin Liew on Data Oriented Design 09/11/2011:10:23:33

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.

http://justinliew.com/blog/?p=2890

Components 08/11/2011:20:55:42

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.

http://altdevblogaday.com/2011/10/08/a-handful-of-components/?utm_source=twitterfeed&utm_medium=twitter

Things to consider : #03 08/11/2011:14:36:12

Cache oblivious code is not ignorant, just not dependent.

http://www.1024cores.net/home/parallel-computing/cache-oblivious-algorithms

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.

http://en.wikipedia.org/wiki/Space-filling_curve

http://en.wikipedia.org/wiki/Gray_code

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.

Things to consider : #02 08/11/2011:14:12:29

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.

http://vimeo.com/6624203

Who came up with the name? 08/11/2011:13:02:01

We have Noel Llopis to thank for his Game Developer article that coined the term Data-Oriented Design:

http://gamesfromwithin.com/data-oriented-design

Pitfalls of Object Oriented Programming 08/11/2011:12:58:50

The Article, by Tony Albrecht that brought it to everyone's attention:

http://research.scee.net/.../Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

Pixeljunk Shooter 2 Lighting 08/11/2011:12:47:54

Jaymin Kessler presents two videos on PixelJunk shooter 2 fluid dynamics and SPU lighting.
PixelJunk Shooter 2 and SideScroller: Fluid And Lighting Part t 1
PixelJunk Shooter 2 and SideScroller: Fluid And Lighting Part t 2

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.
http://altdevblogaday.com/2011/09/21/checking-for-interval-overlap/

Things to consider : #01 08/11/2011:12:08:15

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:
http://mechanical-sympathy.blogspot.com/2011/07/write-combining.html

*it's never better to have a lookup table.

Latest #AltDevBlogADay post from BitSquid 8/11/2011:12:01:07

http://altdevblogaday.com/2011/11/07/an-example-in-data-oriented-design-sound-parameters/
Mastodon