5 ms·

> The core of DOD is not about optimization or making fast programs through hardware consideration; it is about organizing programs around a deep knowledge of d

• DixieDev 4y ago
  It's a strange sentence for sure. Organising your programs around data and its transformation happens to mean you are aware of how hardware organises, represents, and transforms data, and accommodate that to keep things running smoothly. I would say the purpose of DoD is most certainly to make fast programs, but guess the point of that quote is just to further emphasise that this is all about data.
  • Warwolt 4y ago
    I think this is a very important distinction though, because if DOD is to be possible to consider as a programming paradigm you'd have to be able to state how a program is meant to be built up from scratch. An object oriented programmer would propose the program to be built up from objects, the functional programmer would propose to build with pure functions. I would image a DOD programmer would propose to build the program with data transforms, which is a more general thing than just "make program go fast". Of course making good use of hardware is easier in a paradigm that uses hardware level data transforms as its building block, but I don't think it makes any sense to make that the _defining_ feature of the paradigm.
    • jstimpfle 4y ago
      The emphasis is on the data, not the transforms. The code is often not the interesting part.
• peteradio 4y ago
  Saying you want to make a highly optimized fast program doesn't guide you how to actually do it. The pattern says "when we focused on the data layer, optimization and speed came more naturally".
• Tomis02 4y ago
  Not an expert but have a strong opinion. Many developers reject DOD because "performance isn't that important in [some software type]". However, using DOD can have other benefits unrelated to performance, IMO. From the article: "DOD promotes solving concrete problems as opposed to generic ones". Given that DOD is biased against unnecessary abstractions, this can improve the code's readability (e.g. no more Abstract Factory Manager Generators) and thus maintainability. As Mike Acton pointed out, it's very useful to be able to easily reason about what your software is doing (not just a particular class, in isolation). The quote you mentioned seems to be in opposition to the OOP-centric view of the world, and hints to alternative ways of organizing code (PODs and transformations).
  • memco 4y ago
    Andrew Kelley gave a presentation where he discusses how DOD was actually giving significant performance improvements for zig: https://vimeo.com/649009599 https://vimeo.com/649009599. DOD may not be explicitly concerned with performance, but it could provide performance improvements in some situations.
    • runevault 4y ago
      DOD 100% gives performance benefits. The problem becomes some people acting like that is the ONLY benefit, which is why you see more and more pro DOD people trying to make the other benefits clear so that people will stop thinking it is ONLY an optimization technique, because then people who aren't as worried about blazing fast performance will still consider it in case the other benefits help their problem case.
      • memco 4y ago
        Part of why I reference the talk is that he was advocating for it in a broader context because he found it simplified the architecture and reduced memory and execution time for his project which isn’t a game. I would love to see more exposition on the subject in different contexts so people get a feel for what DOD might look like in different spheres of development especially in more general programming environments. I don’t yet have much experience with it myself but I know that each time I have explored a different design pattern I have learned useful things so I look forward to learning more about it and finding ways to use it.
• bitwize 4y ago
  I'm not an expert but I am writing a game using DOD and ECS, in Java, for Android, and it's a 2D game so performance is not an utmost concern. I can say that using the ECS pattern and being data-driven has absolutely saved my bacon and made the dev process so much easier. Tricky things, like adding new enemy or elevator behavior, have turned out to be not so tricky when I get to the implementation bit, because the ECS makes things orthogonal when they would be tangled up with each other in a strictly OO model.
• zmgsabst 4y ago
  I see DOD as enabling optimization, because your code is “naturally” laid out in a way that exposes data representations and transforms you can create optimized versions of. But you can do DOD without that being your goal, because ultimately DOD is saying that you use “classes of objects and maps between them” as your framework for design. That it allows you to substitute efficient versions for each is a benefit, not a requirement.
• corysama 4y ago
  DOD actually started as an alternative to class inheritance hierarchies. The performance benefits were recognized and popularized after it was implemented. https://www.gamedevs.org/uploads/data-driven-game-object-system.pdf https://www.gamedevs.org/uploads/data-driven-game-object-sys...
  • thisNeeds2BeSad 4y ago
    Eh, inheritence is relatively performance friendly.. all the stuff is after all wrapped into one onion shaped object. The problem starts with pointers - aka loose composition and not having "work-bundles" for the hootloop, which usually ideally come as arrays of work-packages. MA, MA, MA
• pdpi 4y ago
  The shape of the architecture, and the practical effects of that architecture on performance are two distinct topics. You can have have a long and interesting discussion about the advantages and disadvantages of data-oriented programming versus the object-oriented approach without ever touching the topic of performance. Also, DOD isn’t fast unto itself, it just lends itself to fast implementations.
• jayd16 4y ago
  The goal is to ship games. Games have a fuzzy definition and what you're building always changes during the process. Iteration is very important. You can that by noticing that every game engine has a non-compiled scripting tier usually on top of a slow to compile core. DoD lets you tweak data w/o a recompile. Data is composable and transferable. DoD is highly iterative and that's a major reason why its in the running. That said, its also nice that DoD can fairly easily be array oriented and that's where a lot of the speed comes from. As far as DOTS goes, Unity has been advertising the performance pretty hard because in the short term its going to be a step down ergonomically.
• danbolt 4y ago
  I’ve used ECS in various games, and there’s a huge advantage in being able to “map out” your tick from a bird’s eye view. Or, since each of your systems are relatively self-contained, your `update` function will more or less allow you to inspect which order they’re in and when they’ll iterate. I’ve worked on games where that logic has been hidden behind a bunch of vtables, and that made it unclear where/when certain logic was happening.
  • drittich 4y ago
    ECS is a good example of multi-benefit DoD because it's clearly meant to be performant, but there are significant benefits that come from using discrete components rather than typically more complex OO classes, for example. I've built pretty large update loops (using dozens of systems), but the complexity doesn't seem to grow much as I add more, and systems themselves are generally small. Maintaining correct order of system update calls has been the trickiest part.
• interroboink 4y ago
  Compare this with the first sentence after the abstract: "Data-oriented design (DOD) grew when game developers needed to use modern hardware architectures for performant games, and existing software processes did not meet their needs." So, I think performance and DOD have been closely tied together from the start. There has been some evangelism to push it out of "it's just for optimization" territory (and reasonably so), but I'm not sure I agree with their notion of "core".
• drittich 4y ago
  Not an expert. My take is this: I was thrilled several times when I started exploring ECS. As a long time pseudo OO developer (not a fan) I found that first of all ECS really did help me write fast update loops, and when the loop become slow it was easy to determine what was slow simply by commenting out different system update calls. IMO it really delivers on the performance front of you pay attention. Second, you can't always do this, but I had cases where once an entity had no more components, it simply ceased to exist, and there was no separate collection simply containing entities themselves. A novel approach compared to OO, and I found it refreshing. Third, it encourages you to think about each component separately, because they will have their own collection and engine. This makes refactoring so easy, because you are looking at typically a handful of properties at most, and a small dedicated engine routine. This delivers on many of the promises of microservices. The last obvious but IMO incredibly important benefit I found was the loose coupling that resulted. Sure not everything is isolated, I would often need to share components between services, but usage and purpose was clear and obvious, and I found myself refactoring components with ease. Contrast this with OO design that encourages abstract concepts like User which, it turns out, have the gravity of black holes and can swallow up any number of properties that SEEM like they should go there. Good luck teasing this apart later, and even remembering what half of them do. I found the concept in the article that humans are more likely to make additive than subtractive changes profound, and it seems we must recognize this and fight against it as developers wherever we can. (It's definitely true in the audio world, where, e.g., people are much more likely to make additive than subtractive EQ changes, unless they're professionals.)