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

11–20 of 83 posts

Re: Introduction to Data-Oriented Design [pdf]

#11

Post by inigyou »

sirwhinesalot wrote: post #7
inigyou wrote: post #2

Serious question. Does DOD mean anything more than array programming, in practice?

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?

Re: Introduction to Data-Oriented Design [pdf]

#15

Post by ghosty141 »

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 the team lead et al. This makes such an approach impossible since DoD is exactly the opposite of flexible design in my opinion.

Im curious has anybody really followed this in a big long living commercial project?

Re: Introduction to Data-Oriented Design [pdf]

#16

Post by hecreto »

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…

Based on your description the only prescriptive thing one can say is lean into composition and avoid inheritance. While there are some pitfalls with composition it is easier to unpack and restructure than inheritance is. Changing requirements will of course incur changing data structures etc. but hopefully this can be avoided a bit by using LUT/indexes and other things to minimize impact.

Re: Introduction to Data-Oriented Design [pdf]

#17

Post by inigyou »

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-array class template rather than a whole framework that promises to do everything. (You might not actually need parallel arrays anyway - AoS might work just fine here because you usually touch each field of each particle once per frame and exactly in order.)

Re: Introduction to Data-Oriented Design [pdf]

#18

Post by inigyou »

PessimalDecimal wrote: post #14

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

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.

People posted a wide variety of specific ideas under my other comment: https://news.ycombinator.com/item?id=49061421

Re: Introduction to Data-Oriented Design [pdf]

#19

Post by shoo »

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…

DoD may be a good idea for a business context where one of your main priorities is getting the most efficient use out of memory bandwidth & cache.

E.g. if your job is writing game engines or middleware used by AAA games with fancy graphics to run on consumer hardware, getting the most efficient use out of the players' limited memory bandwidth may be very important.

For many (most?) arbitrary commercial software projects in other contexts, performance isn't high priority & memory bandwidth isn't a bottleneck. Performance just has to be 'good enough' & 'good enough' performance may be easily attained by writing typical OO code that uses cache & memory very inefficiently - so in those cases DoD is an engineering trade off that solves a problem that doesn't need to be solved & may create new problems if introduced.

Re: Introduction to Data-Oriented Design [pdf]

#20

Post by corysama »

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?

That would be https://martinfowler.com/articles/mechanical-sympathy-princi...
Post reply on HN