What is Data Oriented Design?
DOD is all about changing the design of an application to streamline the processing of any data, by avoiding branch misprediction for example. This means designing for the data processing needs in relation to the architecture of the target platform(s), rather than for a chosen method of abstraction.
In a traditional object oriented design of a racing game there would be a Car class which would hold position, speed and numerous other values. The physics engine would need to crunch a subset of those values constantly to make sure the cars don’t drive through each other, which means a big for each loop that goes through all the Car instances and calls a doPhysics method passing in several values from each car.
The game is being ported to the PS3 and the need has arisen for the physics to run on a SPU but those have their own dedicated RAM. The array of Cars design results in lots of small value transfers to push the relevant values to a SPU then the physics calculations run followed by a bunch of individual transfers back to main memory. It could even mean that the transferring in and out might take longer than the physics system takes to process how fast a car is approaching another.
If we put on our DOD hat, then we see that it’s much better to store an array of speeds and an array of positions for all cars together and transfer that entire array in one, process it and then transfer them back again.
So what are you doing again?
My intention over the next couple of posts is to investigate the effect of data oriented design changes in Java. Given that this isn’t particularly planned there may be an element of stream of consciousness to the subsequent posts.
Now because Java compiles to an intermediate form, there’s an added complication when trying to determine how much of a difference changes made in the source code have. The Hotspot compiler can also rewrite previously compiled native code if it believes that it can be improved. This also has the result of making the JVM non-deterministic, so the same native code can’t be guaranteed to be generated for every run.
What have you got so far?
As usual for my posts there’s a shiny project for you to clone, play about with and criticise to your hearts content up on Github:
Debug JVMs provide some extra options over and above the stock ones, with the -XX:PrintAssembly option printing out the assembly generated at runtime. More information on that is here: