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

21–30 of 83 posts

Re: Introduction to Data-Oriented Design [pdf]

#21

Post by wasmperson »

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…

I feel like DoD is one of those things that only makes sense after you already believe in it. There's a sort of KISS epiphany that you have to go through which I don't think the commonly available info on DoD helps you to reach. It doesn't help that everything about it tends to get hung up on overly-specific C++ optimization advice.

Re: Introduction to Data-Oriented Design [pdf]

#22

Post by ButlerianJihad »

ghosty141 wrote: post #15

I personally love the idea of DoD but from my experience it rarely works well in practice since one of the key assumptions of understanding ur problem is often not given as new requirements pop up and change all the time. At work we are rewriting and reengineering system from scratch and its crazy because the limitations of the old system are now gone we get the most insane feature requests that are even accepted by…

Why do you lowercase "oriented" when "DOD" (and "OOD") is the usage in the slides?

Re: Introduction to Data-Oriented Design [pdf]

#24

Post by slopinthebag »

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…

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.

Re: Introduction to Data-Oriented Design [pdf]

#25

Post by wasmperson »

PessimalDecimal wrote: post #14

This seems like a particular branding on cache-aware data structures and algorithms. Is there more to it?

One good example of DoD which isn't CPU-cache-related is relational databases. When designing a CRUD application, the Data-Oriented way of doing it is to figure out what data you will be storing and how to organize that data to minimize access times, which is what you're doing when you design the DB schema.

An example of failing to follow DoD is the N+1 query problem: a programmer builds an abstraction that operates on individual DB rows, but "where there's one, there's more than one": you will inevitably be running that code in a loop so that you can process multiple rows. If instead the programmer had abstracted over groups of rows, then per-item query overheads suddenly become per-batch overheads.

Re: Introduction to Data-Oriented Design [pdf]

#27

Post by slopinthebag »

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 approach if it solves a problem where those techniques are more appropriate. Advocates tend to be quite dogmatic, ask them about RAII or modern C++\Rust for example and you’ll see what I mean.

And I say this as someone who basically sees programming as data and associated algorithms and always approaches problems by considering state or data first.

Re: Introduction to Data-Oriented Design [pdf]

#28

Post by inigyou »

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.

Often you don't have runtime composition and don't need it. By prematurely generalizing you're venturing close to OOP territory.

Re: Introduction to Data-Oriented Design [pdf]

#29

Post by Quothling »

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 knew OOP had failed when we started getting programmers who solved memory issues with batching instead of thinking about why they were loading that much data into the memory to begin with. For the previous 20-30 years that didn't really matter. Code was the bottleneck and implicity and abstractions helped developers ship changes faster. It turned out that it didn't give us maintainable or safe code bases, and there is a sweet irony to be found in the world of banking. Where the JAVA systems meant to replace the old parallel paradigms are now being replaced with systems that are better links between the COBOL systems and the customers than JAVA ever was.

AI changes that. Especially because it appears that LLM's can't understand the OOP abstractions any better than your hardware can compute it.

That being said. OOP and DOD both have advantages and disadvantages. If you go back to what I said first it wasn't exactly a failing of the OOP paradigm. The biggest issue I have with OOP is actually that it's too easy to do things wrong with it. Which isn't helped by the multimillion dollar industry which thrives on teaching developers everything except core computer science. People know their DRY, SOLID, CLEAN, TDD, Agile and every design pattern in the world, but they don't know how the interface they've just implemented actually handles their data.

Re: Introduction to Data-Oriented Design [pdf]

#30

Post by QuantumNomad_ »

zx8080 wrote: post #26
HexDecOctBin wrote: post #12

Mike Acton (author of this presentation) has released a LLM skill for Data Oriented Programming: https://github.com/macton/nagent/blob/main/context/data-orie...

> You are working for Mike Acton. AI generated skill?

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?

Maybe he found that telling it that it works for him nudges it in a direction that is beneficial to get it to write code like he wants, alongside the specific rules and other instructions in the above linked document?

Post reply on HN