3 ms·

> Curiously there aren't a lot of DOD discussions or articles on HN. How much is there to say, really, once you've got the basic idea? OOP has always emphasiz

> Curiously there aren't a lot of DOD discussions or articles on HN. How much is there to say, really, once you've got the basic idea? OOP has always emphasized single objects. Part of that emphasis is that data is grouped by object rather than by field. For some applications, this style can work well. GUIs are the canonical example. However, if speed really matters, a focus on individual objects is rarely helpful, because it doesn't support typical data access patterns where algorithms probably want to work with one field for many objects rather than many fields for the same object. This doesn't just matter for games. If you're working on any kind of mathematical code using large matrices, something as simple as choosing row-major vs. column-major ordering appropriately can make a very noticeable difference to performance on modern hardware with several layers of cache. One of the nicer things about C++ is that while it supports OOP (at least in the variation that has become most popular) it doesn't try to shoe-horn everything into being an object and is quite happy for you to worry about your own memory layouts if you want to. Once you've understood that basic point, there isn't really much else to know about Data Oriented Design. It seems like one of those ideas that has been capitalised to make it seem more important than it really is. If no-one had popularised OOP, despite its fundamental flaws in this respect, perhaps we would have just called the DOD approach "common sense"...

forrestthewoods 15y ago
I think the types of DOD being discussed in the great twitter wars are far more complex than common sense. http://macton.smugmug.com/gallery/8936708_T6zQX/1/593426709_ZX4pZ#593426709_ZX4pZ http://macton.smugmug.com/gallery/8936708_T6zQX/1/593426709_...
- Chris_Newton 15y ago
  I remember when that first did the rounds a few years ago... The thing is, while it's interesting seeing the potential trouble spots Acton highlighted, he didn't actually show a better way of doing any of it. As someone who has also done his fair share of low-level/high-performance programming in C++, I would take some convincing that the result isn't going to be somewhat faster but effectively write-only code. That might be OK if you know your target platforms well enough to count on those micro-optimisations not being premature and you know no-one is going to care about maintaining your code for very long, which is not entirely unrealistic in the games industry but doesn't apply to much else. However, I think a lot of the ideas on those "slides" go beyond Data Oriented Design as the term has come to be used, and into general low-level, architecture-specific optimisations. There's nothing wrong with exploring the latter, of course, but I'm not sure it's helpful to conflate very fine-grained, platform-specific, relatively localised adjustments with a high-level view of how to group multiple properties on a set of objects in memory, or with the more general principle of transforming your data in advance into some format that lends itself to the kind of processing you want to do. (None of which is to say that articles on how to do that sort of low-level optimisation on popular platforms wouldn't be interesting. I'm just suggesting that they would probably have to go some way beyond what is commonly called DOD today before they were likely to get interesting.)

forrestthewoods 15y ago

I think the types of DOD being discussed in the great twitter wars are far more complex than common sense. http://macton.smugmug.com/gallery/8936708_T6zQX/1/593426709_ZX4pZ#593426709_ZX4pZ http://macton.smugmug.com/gallery/8936708_T6zQX/1/593426709_...

Chris_Newton 15y ago
I remember when that first did the rounds a few years ago... The thing is, while it's interesting seeing the potential trouble spots Acton highlighted, he didn't actually show a better way of doing any of it. As someone who has also done his fair share of low-level/high-performance programming in C++, I would take some convincing that the result isn't going to be somewhat faster but effectively write-only code. That might be OK if you know your target platforms well enough to count on those micro-optimisations not being premature and you know no-one is going to care about maintaining your code for very long, which is not entirely unrealistic in the games industry but doesn't apply to much else. However, I think a lot of the ideas on those "slides" go beyond Data Oriented Design as the term has come to be used, and into general low-level, architecture-specific optimisations. There's nothing wrong with exploring the latter, of course, but I'm not sure it's helpful to conflate very fine-grained, platform-specific, relatively localised adjustments with a high-level view of how to group multiple properties on a set of objects in memory, or with the more general principle of transforming your data in advance into some format that lends itself to the kind of processing you want to do. (None of which is to say that articles on how to do that sort of low-level optimisation on popular platforms wouldn't be interesting. I'm just suggesting that they would probably have to go some way beyond what is commonly called DOD today before they were likely to get interesting.)