Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Introduction to Data Oriented Design with Rust

jamesmcm.github.io

Post reply on HN
Print view View original

31–40 of 161 posts

Re: An Introduction to Data Oriented Design with Rust

#31

Post by Arelius »

cogman10 wrote: post #10
blovescoffee wrote: post #3

I've read quite a few articles about DOD. I get how DOD is great but there are reasons OOP is still around (surely?) I suppose I'm still hung up on, what are the benefits of OOP that I'm missing? It seems like there are reasons OOP is so ingrained. I can see a couple of reasons that are environmental. For instance, OOP is taught in schools because students are often taught to program before they're taught about compu…

DOD generally implies a high level of coupling on the system. That's it's biggest weakness. It also pushes even more data management problems onto programmers which makes it easy to get things wrong. You take those downsides and you trade them for higher performance. Now, that doesn't mean that you can't have hybrid systems and get most of the benefits of both worlds. It does, however, mean that you will end up with…

> DOD generally implies a high level of coupling on the system. That's it's biggest weakness.

I'm not sure I understand what you mean by DOD generally implies a high level of coupling? Could you perhaps elaborate a bit?

Re: An Introduction to Data Oriented Design with Rust

#32

Post by Arelius »

blovescoffee wrote: post #28
erichocean wrote: post #8

Earlier quoted context omitted.

> It does seem like there are also legitimate concerns about refactorability and extensibility of DOD code. On the contrary, that's why people adopt DOD designs. It's way easier to add new stuff without breaking existing code/designs in a way that harms them.

If your data changes then won't you need to refactor more than if your data changes in OOP? I suppose "data changing" is an arbitrary measurement but I think that's what people refer to when they talk about refactoring DOD vs OOP.

Likely, yes, but the corollary is if your data structure stays similar and well defined, then you'll have smaller, cleaner and less refactors for reasons that are unrelated to a fundamental shift in your actual data

Re: An Introduction to Data Oriented Design with Rust

#33

Post by adamnemecek »

runevault wrote: post #25
mdtusz wrote: post #11

Earlier quoted context omitted.

Partially, but DOD like in the article examples work great when you have a "rigid" architecture like a game where having a struct to contain vecs/arrays of player attributes makes sense. This can break down when your "objects" require more flexibility and are used in multiple different contexts where an aggregate `PlayerState` struct doesn't play nicely. Not to say that DOD is bad, just that it shouldn't always be th…

ECS style DOD arguably makes putting things together easier though, because instead of having to update your actual object when you want to make a change, you only have to add the right component that contains the functionality you need to the given entity ID.

And don't get me started once you have some hierarchies. Sometimes a object changes and you need to notify a parent of this change. OOP really sucks at this.

Re: An Introduction to Data Oriented Design with Rust

#35

Post by throwaway894345 »

renewiltord wrote: post #34

The cost to legibility for the vectorization seems high. I wish there were a way to get the best of both worlds, i.e. specify the type you want and have it striped so that the struct is then vectorified.

Isn’t that a feature in Jai?

Re: An Introduction to Data Oriented Design with Rust

#36

Post by eyesee »

adamnemecek wrote: post #6

A lot of people in the Rust community (yours truly including) are trying to work out how to build UI frameworks in this paradigm. It's a really interesting question, if anyone has any good input, I'm alll ears.

I'm not in the Rust community, but it seems like one could have their cake and eat it too, using OOP with DOD storage.

  * Use a special allocator for objects which reserves a vector slot from your structure-of-arrays.
  * Objects records are offsets instead of pointers
  * Object definition includes getter/setters which index the columnar vectors
  * Store fields declared 'columnar' in a value vector. This could even give flexibility to group columns for locality where needed, and allow ancillary data to be stored in a "leftover" struct.

Re: An Introduction to Data Oriented Design with Rust

#38

Post by adamnemecek »

eyesee wrote: post #36
adamnemecek wrote: post #6

A lot of people in the Rust community (yours truly including) are trying to work out how to build UI frameworks in this paradigm. It's a really interesting question, if anyone has any good input, I'm alll ears.

I'm not in the Rust community, but it seems like one could have their cake and eat it too, using OOP with DOD storage. * Use a special allocator for objects which reserves a vector slot from your structure-of-arrays. * Objects records are offsets instead of pointers * Object definition includes getter/setters which index the columnar vectors * Store fields declared 'columnar' in a value vector. This could even give f…

Yes, generational arena allocations are very popular. The larger question is more about the application architecture. Like where does one handle user input? Where does rendering happen? Etc.

Re: An Introduction to Data Oriented Design with Rust

#39

Post by nikki93 »

knowuh wrote: post #16

For a 2x speed up, I am not sure I would be willing to sacrifice legibility as in the example. The OOP method definition reads like english. The article suggests the true benefits of DOP aren't all that great unless you understand the target architecture. I feel like the pendulum is at its new zenith.

I think DoD can be ergonomic, actually, if you're doing it just for the architecture reasons vs. the optimizations reasons, to the point that you choose DoD due to them. At least I personally have found that eg. an ECS architecture can lead to separations and structurings of logic code that were helpful, while still defining data in ways that I could just make accessible to tooling and so on.

In this talk on their architecture for Overwatch: https://youtu.be/W3aieHjyNvw (highly recommend) you can see that the wins / concerns they talk about have to do with architecture more than perf. Big insights at 8:00 in the video.

Post reply on HN