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

Introduction to Data-Oriented Design [pdf]

gamedevs.org

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Introduction to Data-Oriented Design [pdf]

#41

Post by saghm »

parpfish wrote: post #32
QuantumNomad_ wrote: post #30

Earlier quoted context omitted.

Possible, but regardless of whether or not that is the case his name is well known enough and he has been around long enough that his name definitely appears in a lot of the texts the LLMs were trained on, in contexts that relate to his views on programming. Try asking your LLM of choice this in an empty session with no other context: You are working for Mike Acton. What principles do you follow when writing code? Ma…

> Maybe he found that telling it that it works for him nudges it in a direction that is beneficial I think that’s call “spooky Acton at a distance”

I started writing up a giant response to this about how all of LLMs are spooky action at a distance but for better or for worse, that doesn't make them any less useful, and a few paragraphs in I suddenly noticed what you actually wrote. Well played :)

Re: Introduction to Data-Oriented Design [pdf]

#42

Post by [deleted] »

slopinthebag wrote: post #24
inigyou wrote: post #17

Earlier quoted context omitted.

My experience with ECS is that you shouldn't use an "ECS system". You should just do ECS. Have an array of all your particles and then update all the positions according to the velocities. Don't use a framework where you do something like get_all_entities_with (). Just have struct particles {vector positions, velocities;}. Well, managing those parallel arrays gets pretty annoying, but you solve that with a parallel-a…

The problem is that there are a lot of subtleties to an ECS that these frameworks solve, and they perform better than a naive approach too. Your solution of a particles struct doesn’t even support a fundamental feature of ECS’s which is runtime composition. It’s really a different solution altogether, which is fine but it’s not a replacement for an ECS.

[deleted]

Re: Introduction to Data-Oriented Design [pdf]

#43

Post by samiv »

dustbunny wrote: post #6

The real key pillar to this world view is putting the data first in your design of the algorithm. So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written. You start with defining the data, and build from there. Different types of applications all have different shapes…

While the idea is itself not without merit the problem is when people design these data oriented systems without abstractions and in fact it's often difficult to find good abstractions around the data the problem comes when the system, the data and functionality needs to change. There will be problems.

So while it's great to think about the data flow it's also important to think about the abstractions around it,.ie the (system) interfaces that let the system evolve without having to propagate changes everywhere while reaping the benefits of data orientation.

Re: Introduction to Data-Oriented Design [pdf]

#46

Post by sirwhinesalot »

inigyou wrote: post #11
sirwhinesalot wrote: post #7

Earlier quoted context omitted.

Yes. Array programming happens to overlap heavily with DOD in modern hardware because of caching and SIMD, but if you were programming an Atari ST it wouldn't. There are also cases where the optimal data format isn't array oriented because the memory access patterns for the problem in question just require something else. You also have to think of hot vs cold data, which has nothing to do with arrays.

Can I propose renaming it to Hardware Oriented Programming?

Eh, I don't think that's a good renaming. Data-Oriented Design is in opposition to Domain-Driven Design (a software development approach that prioritizes modeling software to match a real-world business domain).

OOP tells you to structure your software as objects exchanging messages, and DDD tells you what those objects (or their classes rather) should be.

Similarly, Procedural programming tells you to structure your software as procedures, and DOD tells you what those procedures should operate on.

The focus on the data is the really important part. What is the actual data I'm operating on (without any fluff on top) and what do I need to transform it into? What subsets of that data need to be operated on at any given point in the program? That's the core of DOD.

Then, as a second step, comes the hardware. Now that I know what data I need to operate on, how do I lay it out to best take advantage of the hardware I'm targeting? If you rename the paradigm to "Hardware Oriented Programming", it shifts the focus from data modeling to code (IMO), which is the wrong frame of mind.

For example, virtual calls are slow compared to direct calls, because they screw up branch prediction and often can't be inlined. In HOP, you'd probably ban virtual calls entirely because virtual calls bad.

But in DOD, they honestly probably don't matter at all! Because if you did the data modeling as instructed, and then you laid out the data to best take advantage of the hardware, your virtual function is going to be operating on a pile of data in bulk, making the virtual call cost pure noise.

Re: Introduction to Data-Oriented Design [pdf]

#47

Post by nextaccountic »

inigyou wrote: post #17
dustbunny wrote: post #6

The real key pillar to this world view is putting the data first in your design of the algorithm. So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written. You start with defining the data, and build from there. Different types of applications all have different shapes…

My experience with ECS is that you shouldn't use an "ECS system". You should just do ECS. Have an array of all your particles and then update all the positions according to the velocities. Don't use a framework where you do something like get_all_entities_with (). Just have struct particles {vector positions, velocities;}. Well, managing those parallel arrays gets pretty annoying, but you solve that with a parallel-a…

But why? This looks like the mother of all boilerplates. And for what purpose?

Also: just having stuff in an array or vector invites you to the ABA problem. You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index. But that's yet another boilerplate that would easily be overlooked if you had to do everything manually.

Also: you seem to be saying this with C++ in mind. Do you think that applies to bevy_ecs too?

Modern Bevy has relationships to make sure that if an entity has a component that refers to another, it doesn't become dangling. It works a bit like foreign keys in databases. I think this makes ecs much more usable

(as an aside, there is a whole host of analogies between ecs and relational databases. entity archetypes are tables, entities are rows, components are columns, and systems are queries). Nobody tells people to just write their database from scratch though)

Re: Introduction to Data-Oriented Design [pdf]

#48

Post by crabmusket »

slopinthebag wrote: post #27

I wish people weren’t so dogmatic about DOD. It’s applicable mainly when you have extremely large amounts of data which can be processed in parallel, which seems mostly the case with video games (eg. look at most DOD examples) and other niche cases. It’s called “Data-Oriented Design” but it really should be called “parallel-processing design” because the average DOD advocate will never advocate for a different OOP ap…

I think this is broadly true, but there's also a subset of DOD design advice (e.g. see Richard Fabian's book) that has a lot to say about relational database design. In our team it's provided us with some very practical motivation for more normalised table designs. Doing 1+n requests to the database due to poor implementation feels similar now to pointer chasing.

The connection is that ORMs convince you to have an object-oriented view of the world, which maps nicely to object classes. But highly normalised designs don't map as cleanly to classes and objects, so you need to approach with a different style of programming on the application side.

Instead of seeing a User instance, you start to see a more complex bundle of login methods, profile events, etc.

Re: Introduction to Data-Oriented Design [pdf]

#49

Post by spider-mario »

dustbunny wrote: post #6

The real key pillar to this world view is putting the data first in your design of the algorithm. So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written. You start with defining the data, and build from there. Different types of applications all have different shapes…

> ECS

“Entity Component System”, for those like me who didn’t immediately think of it.

Re: Introduction to Data-Oriented Design [pdf]

#50

Post by inigyou »

groundzeros2015 wrote: post #37
inigyou wrote: post #18

Earlier quoted context omitted.

I consider it generally the ideology of anti-OOP. While OOP ideology teaches you to structure the program after the problem it solves, DOD ideology explicitly teaches you to throw all that away and think about what runs fastest on the computer. Maybe it should be called Computer-Oriented Programming or Hardware-Oriented Programming. The specifics very a lot but the top-level ideology of "fuck OOP" is consistent. Peop…

> While OOP ideology teaches you to structure the program after the problem it solves I completely disagree with this characterization. OOP teaches you a synthetic set of concepts (go4) and then asks you to solve problems in terms of that. And the reason why the canonical bird as a subclass of animal doesn’t work, is it’s extremely difficult to divide the world into strict categories (are you Aristotle). So the solut…

OOP is not Singleton, it is "class Car extends Vehicle {Tyre tyres[4]}" etc
Post reply on HN