An Introduction to Data Oriented Design with Rust

Post by tgb » Thu, Sep 17, 2020, 9:50 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…

Post by narwally » Thu, Sep 17, 2020, 9:52 PM UTC

Jtsummers wrote: post #86

narwally wrote: post #77

I find it interesting, and somewhat amusing, that we're seeing Data-Oriented-Design becoming popular in C++ and Rust while Data-Oriented-Programming/Data-Driven-Design[1] is being promoted in languages like Clojure and Elm. Both have similar names, and seem to have arisen out of frustrations with OOP. However, their solutions went in completely opposite, though not unrelated, directions. Seems like DOD is about impro…

"Data-driven programming" tends to give more results than "data-driven design" which mostly (on my Google search) turned up content about usage data driving interface design. https://en.wikipedia.org/wiki/Data-driven_programming

Post by renewiltord » Thu, Sep 17, 2020, 9:57 PM UTC

yumaikas wrote: post #89

renewiltord wrote: post #73

Earlier quoted context omitted.

Fascinating. Isn't reflection in these VM languages pretty slow usually? Won't you pay that cost on access each time? Still, C# seems to be capable of a lot if you can do this ergonomically. Very cool.

That really depends which reflection APIs are being used. For C#, you can use type reflection to get the data or shape of a piece of code or a type (GetType and friends). That isn't super fast, and isn't intended to be. The other major C# reflection API is Reflection.Emit, which allows you emit IL at runtime. The Emit->IL->JIT process is slower than executing the code outright the first time, but once you've done it,…

Post by Jtsummers » Thu, Sep 17, 2020, 9:58 PM UTC

narwally wrote: post #93

Jtsummers wrote: post #86

Earlier quoted context omitted.

"Data-driven programming" tends to give more results than "data-driven design" which mostly (on my Google search) turned up content about usage data driving interface design. https://en.wikipedia.org/wiki/Data-driven_programming

Thanks, I knew it was some permutation of those words.

Post by barrkel » Thu, Sep 17, 2020, 10:07 PM UTC

munificent wrote: post #88

bfrydl wrote: post #64

Earlier quoted context omitted.

I think this is because of Rust. In my opinion the Rust game dev community is overly fixated on ECS. On the bright side, Rust has some damn good ECS libraries.

> the Rust game dev community is overly fixated on ECS. Not just Rust. The game dev community everywhere is infatuated with ECS. It's basically cargo culting. There is a large base of amateur or indie game developers who want to feel like they are doing game development the "right" way. One big aspect of that is performance. ECS has a reputation for efficiency (which is true, when used well in a context where your pe…