Data-oriented design is a paradigm that boils down programming to transformations of data. Treating software in this way allows programmers to make better use of modern computing hardware, where transferring memory from RAM to the CPU cache is very slow and operating on large chunks of sequential data is very fast. Code also becomes simpler to write and follow, but it loses some reusability in the process.
Data-oriented design (DOD) is a paradigm that boils down programming to transformations of data. Treating software in this way allows programmers to make better use of modern computing hardware, where transferring memory from RAM to the CPU cache is very slow and operating on large chunks of sequential data is very fast. Code also becomes simpler to write and follow, but it loses some reusability in the process.
It is somewhat opposed to object-oriented programming (OOP). Treating each object individually and entirely at once is not very efficient, as it causes numerous cache misses, one of which can cost hundreds of CPU cycles. As well, encapsulation and polymorphism make it difficult to understand just what is happening behind the scenes.
Another important advantage, especially with today's multicore systems, is that data-oriented operations are often embarassingly parallel - they can be spread out over many threads without requiring synchronization.
An easy example of data-oriented design for game programmers to understand is the ubiquitous particle system. Because particle systems deal with tens of thousands of elements, it is common knowledge that each particle should not be a separate object. Instead, the data is organized as a structure of arrays, where each component (position, velocity, lifetime, color, texture) of a given particle is stored in a different array at a common index. Each particle is represented by (the components at) an index.
Instead of looping over a
Vector<Particle> and calling
Update(dt) on each, we have a single
Update(dt) that only loops over the components it is interested in: position, velocity, and lifetime; and updates those. This allows the CPU to make very efficient use of the cache, which makes the update blindingly fast, or at least a lot faster than it would be if it had to pull the whole particle data each time and jump to a new function.
Some other conventionally data-oriented systems include:
- Component-entity systems
Types of Questions
The most common type of question to be anticipated that concerns data-oriented design would be asking how a certain, traditionally object-oriented, system could be implemented using DOD techniques, or looking for ways to improve an existing data-oriented implementation. It's probably helpful to consider including the data-oriented design tag when asking about component-entity systems and multithreading as well.
However, it should be noted that data-oriented and data-driven are not the same thing! The two concepts are often confused, but concern totally orthogonal software design topics.
- http://gamesfromwithin.com/data-oriented-design - A great article that goes into greater detail about why data-oriented design is often better than object-oriented programming.
- http://dice.se/wp-content/uploads/Introduction_to_Data-Oriented_Design.pdf - A presentation by DICE that compares an object-oriented implementation with a data-oriented one by their performance characteristics.
- https://docs.google.com/presentation/d/17Bzle0w6jz-1ndabrvC5MXUIQ5jme0M8xBF71oz-0Js/present?slide=id.i112 - A presentation by the Bitsquid Engine developers that shows some of the ways in which data-oriented design can be applied to existing game programming technologies.
- http://www.youtube.com/watch?v=16ZF9XqkfRY - A great lecture by Sean Middleditch of DigiPen about data-oriented design.