There was a time where data structures were important and every programmer would think in terms of procedures that simply transformed these data structures into other data structures. Many others would put their focus on declarative languages, and concretely, on functional programming (With ( Beautiful (Languages (like Lisp))). Yet the revolution in the world of programming paradigms was yet to come: Object Orientation arrived to tell a universal truth to all unwary and naive designer and programmer: "in our daily lives, we think in terms of objects, therefore objects should be the building blocks for your systems". And voilà! Smalltalk, C++, Java, and lots of other languages would stick to this paradigm, advocating code reuse and mental models of the system better aligned with the problem domain thanks to several techniques such as abstraction, inheritance, polymorphism and late binding. Object Orientation seemed to be the One that would guide programmers towards successful, robust, maintainable and reusable systems, especially with new languages that hid low-level dirty details like memory management.
Schools and universities then started to teach this new paradigm, first as a complement to previous programming practices, and soon, their curriculums would be centered around them. Because, why on Earth to teach C when most of the companies today called for Java programmers? Why to teach a paradigm that is obsolete, only present at legacy systems that are bound to being wrapped around web services or Java interfaces?
Object orientation really seemed so perfect that when a teacher at my University asked us to give him one disadvantage of this paradigm, neither of us would be able to find a clear answer. Yes, everybody was thinking that Object Orientation was the best, and that it was unbeatable.
Nonetheless recently I noticed something. In the same way as Sauron was secretly spawning enemies and planning its revival in the Middle Earth, some strange people were colluding in the deepest corners of the Internet to bring back something ""new"", something that cannot even be called a paradigm: data orientation. But what's more important: not only are these people convinced that data orientation is a plus, but they (most of them at least) are also convinced that object orientation is not that good, and that even could lead to very poor results.
Ok, let's put things in their context. Most of the people I read about who advocate data orientation (DO, from now on, which I will briefly explain in short) work in the games industry or are indie game developers. This is important because one of the benefits of DO is a boost of performance due to more efficient memory usage.
As I mentioned before, DO does not seem to be a paradigm on its own, but rather a set of guidelines and ways of thinking, without any programming support or special techniques enforced by compilers or programming languages. The best way to understand (at least for me) what DO means, is by citing some of its mantras:
The main reason of the uprising of DO is the ever-growing gap between the processor and the memory. Processors are steadily faster, especially when considering multi-core and multi-processor environments. On the other hand, memory is not progressing as fast, so very often the processor is idle hundreds of cycles while waiting for data coming from memory. DO aims at exploiting the cache (a fast memory between the processor and main memory), and at making code easier to be divided among threads for exploiting cores and processors, something that is hardly possible with object orientation.
When you read some of the techniques that underlie DO, you may find that many of these techniques are well-known programming tricks that good programmers have known for years... but now they are being spread out and someway systematized for the public knowledge. For a quite comprehensive summary of these techniques, take a look here.
In this fantastic video, Mike Acton, engine director at Insomniac Games, explains data orientation with practical examples and how it can be implemented in a language like C++.
Ok, let's put things in their context. Most of the people I read about who advocate data orientation (DO, from now on, which I will briefly explain in short) work in the games industry or are indie game developers. This is important because one of the benefits of DO is a boost of performance due to more efficient memory usage.
As I mentioned before, DO does not seem to be a paradigm on its own, but rather a set of guidelines and ways of thinking, without any programming support or special techniques enforced by compilers or programming languages. The best way to understand (at least for me) what DO means, is by citing some of its mantras:
- The platform is the hardware, not the software. Know your platform, because abstraction is not that good.
- The code is not important. Data is important. Code only serves the purpose of transforming data in trivial ways. Design your code around your data, not the other way around.
- Different problems lead to different ways to organize data.
- When there is one, there are many. Don't think that a function will have to perform an action on only one object (typical object-oriented mindset), but think that this function will be applied to a bunch of objects.
The main reason of the uprising of DO is the ever-growing gap between the processor and the memory. Processors are steadily faster, especially when considering multi-core and multi-processor environments. On the other hand, memory is not progressing as fast, so very often the processor is idle hundreds of cycles while waiting for data coming from memory. DO aims at exploiting the cache (a fast memory between the processor and main memory), and at making code easier to be divided among threads for exploiting cores and processors, something that is hardly possible with object orientation.
When you read some of the techniques that underlie DO, you may find that many of these techniques are well-known programming tricks that good programmers have known for years... but now they are being spread out and someway systematized for the public knowledge. For a quite comprehensive summary of these techniques, take a look here.
In this fantastic video, Mike Acton, engine director at Insomniac Games, explains data orientation with practical examples and how it can be implemented in a language like C++.
Here you can find lots of useful resources about DO. And here, a very interesting blog about the development of a game engine in which some DO considerations have been taken.
The point of this post is to reflect about a reality: the domain of Computer Science is in constant evolution, and hardware considerations constrain the way the software evolves. This evolution may even come in terms of a circle, coming back to the origins. But it's even more serious. We've been taught for years that abstraction is good, and that we don't need to worry about the platform on which we are developing. In performance-sensitive systems in general, and in game engines and games in particular, this is no longer true. Actually, developers are demanding to be able to work "closer to the metal" in the graphics domain as well.
I must add a personal comment though for all of you who are newcomers to the world of games programming. As I mentioned in an older post, abstraction is good, and should be you ally when you're starting. So don't worry about the nitty-gritty intricacies of low-level details. Just design your game in as high-level way as you can.
However, beware, you advanced programmers who want to delve into the world of game engine programming!! Embrace data orientation or perish!!
See you!
FM
The point of this post is to reflect about a reality: the domain of Computer Science is in constant evolution, and hardware considerations constrain the way the software evolves. This evolution may even come in terms of a circle, coming back to the origins. But it's even more serious. We've been taught for years that abstraction is good, and that we don't need to worry about the platform on which we are developing. In performance-sensitive systems in general, and in game engines and games in particular, this is no longer true. Actually, developers are demanding to be able to work "closer to the metal" in the graphics domain as well.
I must add a personal comment though for all of you who are newcomers to the world of games programming. As I mentioned in an older post, abstraction is good, and should be you ally when you're starting. So don't worry about the nitty-gritty intricacies of low-level details. Just design your game in as high-level way as you can.
However, beware, you advanced programmers who want to delve into the world of game engine programming!! Embrace data orientation or perish!!
See you!
FM
