4 ms·

When I read articles like this I think of a quote from Carmack. "The Escalation programmers come from a completely different background, and the codebase is al

When I read articles like this I think of a quote from Carmack. "The Escalation programmers come from a completely different background, and the codebase is all STL this, boost that, fill-up-the-property list, dispatch the event, and delegate that. I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion." (http://www.bethblog.com/index.php/2010/10/29/john-carmack-discusses-rage-on-iphoneipadipod-touch/ http://www.bethblog.com/index.php/2010/10/29/john-carmack-di...) The rage in the game dev community these days is all about highly cache aware Data Oriented Design (DOD) over OOP. Curiously there aren't a lot of DOD discussions or articles on HN.

helmut_hed 15y ago
I read the link, but there's no data there... just the high-level conclusion. It would be interesting to know which features or approaches he found problematic. Otherwise it's just "doesn't work for me".
Chris_Newton 15y ago
> 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.)

helmut_hed 15y ago

I read the link, but there's no data there... just the high-level conclusion. It would be interesting to know which features or approaches he found problematic. Otherwise it's just "doesn't work for me".

Chris_Newton 15y ago

> 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.)