An Introduction to Data Oriented Design with Rust • Hacker News Board

Re: An Introduction to Data Oriented Design with Rust

#21

Post by iherbig » Thu, Sep 17, 2020, 5:58 PM UTC

It seems like a lot of the discussion surrounding DOD that gets popular interest is centered on a small set of patterns that you can apply. And the implication that DOD is the application of these patterns usually follows.

Taking this article as an example, it frames DOD as an optimization technique and explicitly states that these patterns are the main concepts of DOD.

But while these patterns are interesting and often show up in data-oriented designs, they are not themselves foundational to data-oriented design.

This is interesting to me because it seems to obviously be missing something. If the article went through a list of the design patterns present in the GOF book and framed them as the main concepts of OOP, I would imagine people would be a little bit suspect, right?

That's because it's kind of the reverse, isn't it? The main concepts of OOP may result in certain common PATTERNS of code structure and layout -- which have usually been given names like "Strategy" and "Visitor" and "Singleton" -- but those patterns are not themselves the main concepts of OOP.

Likewise, data-oriented design might lead you to convert an array-of-structures into a structure-of-arrays or avoid branching on a hot path but those patterns are not themselves DOD.

Re: An Introduction to Data Oriented Design with Rust

#22

Post by oehtXRwMkIs » Thu, Sep 17, 2020, 6:03 PM UTC

ekidd wrote: post #18

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.

As always, it depends on the problem you're solving. A 2x speedup in the inner loops of a game can be a very big deal. And for business workloads, I occasionally spend time babysitting clusters running batch jobs. A 2x performance increase in the right inner loop might save a couple hundred dollars per run. So certainly, profile before you optimize, as the article demonstrates. But 2x speedups can be worth applying a…

I think the data-oriented version is very appropriate for a game, where performance is king and there's not that much maintenance afterwards once its done. Perhaps I'm wrong but games seem to be very much a finish and toss it over the wall sort of project. Much less iteration than other contexts.

Re: An Introduction to Data Oriented Design with Rust

#23

Post by CyberDildonics » Thu, Sep 17, 2020, 6:06 PM UTC

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…

"OOP" is really three different things that people conflate together.

1. Making data structures as tiny databases with an interface that simplifies storing and retrieving data correctly (no transformations in the class itself to other data types hopefully to minimize dependencies!)

2. The school taught java/old C++ debacle of inheritance. This is where things fall apart. Inheritance means not only dependencies but opaque dependencies. It almost always means pointer chasing and lots of allocations. It used to be necessary because it was the only way to get generic containers. The speed hit to use a chain of pointers was also much smaller. In modern times this destroys performance and is not needed due to templates.

3. Message passing - 'at a certain scale, everything becomes a network problem'. I think the flexibility in having this integrated into the core of a language like smalltalk is not a good trade off, but I do think message passing at a courser architectural level offers large benefits without limiting the speed of more granular and fundamental data structures and functions.

I think OOP will always be debated in a circle because people conflate these three aspects. The first I think is extremely useful and vital. The second I think is obsolete. The third I think should be treated as a higher level architecture approach with large chunks of data passed around to large non-trivial modules/libraries/nodes/plugins etc. The higher level can be more dynamic and flexible because the overhead for a flexible structure is much smaller if it is done with large chunks of data and not integrated into a language and used for vectors / hash maps / one line math functions, etc.

Re: An Introduction to Data Oriented Design with Rust

#24

Post by Jtsummers » Thu, Sep 17, 2020, 6:06 PM UTC

mamcx wrote: post #20

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…

Is more than OOP. Look at this as the difference between OLAP/OLTP databases: DOD is OLAP(Columnar) that make easy to do "query" by columns but awkward to do piece meal updates and OOP/Row-nar(?) code stay because frankly is the default everywhere. And far easier for make updates. Iterate by rows is far more common that by just "a column". Also, constant update of the rows is more common that have a static, full mate…

I was going to write something similar. The example in this article is a comparison between row-oriented and column-oriented approaches, not OOP and DOD. Which you prefer depends on the operations you expect to perform during program execution.

If you generally only add new entities, and generally perform operations on all entities (or large subsets) and specifically only need some columns, then the column-oriented approach is more likely what you want.

If you find you delete entities frequently enough, or operate on individual entities more than groups, then row-oriented may be better. Performance will improve (deletes are expensive in arrays/vectors) and code may be cleaner.

There are lots of other factors, but these are the bigger ones (IME).

Re: An Introduction to Data Oriented Design with Rust

#25

Post by runevault » Thu, Sep 17, 2020, 6:09 PM UTC

mdtusz wrote: post #11

adamnemecek wrote: post #4

Earlier quoted context omitted.

I think oop is easier to understand in small examples but gets really inscrutable as your code base grows so you only start questioning oop if you have worked on large code bases. Also the lack of dod/ecs languages is a problem. I realized the other day that row polymorphism is the type theoretical concept that would make this work. https://en.wikipedia.org/wiki/Row_polymorphism

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.

Re: An Introduction to Data Oriented Design with Rust

#26

Post by estebank » Thu, Sep 17, 2020, 6:10 PM UTC

ekidd wrote: post #18

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.

As always, it depends on the problem you're solving. A 2x speedup in the inner loops of a game can be a very big deal. And for business workloads, I occasionally spend time babysitting clusters running batch jobs. A 2x performance increase in the right inner loop might save a couple hundred dollars per run. So certainly, profile before you optimize, as the article demonstrates. But 2x speedups can be worth applying a…

The interesting thing to me from these patterns is the possibility of using proc_macros to write code in the "array of structs" style while the code gets desugared to "struct of arrays". I don't know how beneficial that would be, but having it as an option would make this pattern more approachable to people that would otherwise not use it, due to verbosity, mental model mismatch or any other reason people might have not to do this.

I don't think Rust itself will ever incorporate this feature into the language, just like it doesn't transparently wrap a `dyn Trait` into a `Box`, but I would expect that it will never put active roadblocks for libraries to extend the language in such a way. (The regular proc_macros caveats would apply, of course.)

Re: An Introduction to Data Oriented Design with Rust

#27

Post by zozbot234 » Thu, Sep 17, 2020, 6:11 PM UTC

hknapp wrote: post #5

When i first started programming and before i had learned of structs, my intuition led me to organize data with arrays of fields. Turns out, i was on to something.

As they say, you can write FORTRAN in any language.

Re: An Introduction to Data Oriented Design with Rust

#28

Post by blovescoffee » Thu, Sep 17, 2020, 6:16 PM UTC

erichocean wrote: post #8

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…

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

Re: An Introduction to Data Oriented Design with Rust

#29

Post by blovescoffee » Thu, Sep 17, 2020, 6:17 PM UTC

jayd16 wrote: post #15

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…

They're not really exclusive concepts and you don't want to bother with DOD if your n is low. I would go as far as to say most DOD implementations are done along side the use of objects.

Sure, although there's room for distinction between programming with objects and OOP.

Re: An Introduction to Data Oriented Design with Rust

#30

Post by zozbot234 » Thu, Sep 17, 2020, 6:17 PM UTC

estebank wrote: post #26

ekidd wrote: post #18

Earlier quoted context omitted.

As always, it depends on the problem you're solving. A 2x speedup in the inner loops of a game can be a very big deal. And for business workloads, I occasionally spend time babysitting clusters running batch jobs. A 2x performance increase in the right inner loop might save a couple hundred dollars per run. So certainly, profile before you optimize, as the article demonstrates. But 2x speedups can be worth applying a…

The interesting thing to me from these patterns is the possibility of using proc_macros to write code in the "array of structs" style while the code gets desugared to "struct of arrays". I don't know how beneficial that would be, but having it as an option would make this pattern more approachable to people that would otherwise not use it, due to verbosity, mental model mismatch or any other reason people might have…

> The interesting thing to me from these patterns is the possibility of using proc_macros to write code in the "array of structs" style while the code gets desugared to "struct of arrays".

This is not possible in the general case, because you can have a general pointer/reference to a single struct in an "array of structs" but a "struct of arrays" can only be accessed by indexing each array separately. So only very simple and self-contained programs can possibly be "desugared" in this way.