General Questions about DOTS

[tame harbor]

Hey,

I have general questions about DOTS just to be sure that I understand the small bit of knowledge I got here and there.

Am I correct at representing each system with these Diagrams I made ? This is how I represent these concepts in my mind even though I never went into looking at the documentation to understand how it works but the most logical way would be this way which would explain why it goes faster.

Here the example is a simple cube with color and size fields and 2 methods, 1 to get its color and 1 to set its color. Here the example use color field and SetColor() method.

By Classical, I mean general use of unity which most of the time uses Monobehaviour but sometimes not. In that diagram, the computer calls the method SetColor() on each instance, which makes that method duplicated in memory (except if I'm wrong on this and every instance points to the same spot in memory for that method).

LEGEND :

• Top elements = Input
• Bottom elements = output
• Right pointing Red arrow = Computer processing a current element (the element on its right)
• Arrows = Processing flow

If it's not correct please let me know why so I can understand better, thank you 🙂

[mighty verge]

1. I want to make sure that you're asking this question about Burst+Job, not ECS? Usually, when we don't mean ECS, we say "Burst+Job". For ECS is also a part of DOTS, along with Burst and Job.
2. I understand your "Classical" diagram as an OOP class diagram. However I don't get the DOTS diagram. Do you mind putting some words explaining them in your own understanding?

[proven warren]

In that diagram, the computer calls the method SetColor() on each instance, which makes that method duplicated in memory (except if I'm wrong on this and every instance points to the same spot in memory for that method).

the code of the method (e.g. SetColor) is never duplicated, only the instance data (e.g. color) is

this is generally the same for virtually all programming languages

[tame harbor]

Thanks for you answer 🙂

1. I'm not sure as I thought Burst + Job are part of ECS. But yeah here I'm interested to know more about the technology that could make heavy games optimized (that are usually really slow because of Monobehaviour or other things that are the defaults in Unity). So if there are differences between ECS, Burst and Job I'm eager to learn about them to understand the differences and their use cases 🙂

2.Like the DOTS diagram, has 2 different classes :

• CubeData: a class containing only data (so only fields and properties but no methods).
• CubeProcessing: a class containing only methods (so no fields or properties) and it behaves like a factory that receives CubeData objects as parameter (those are coming from the top in the diagram) then do stuff on / from that data and return something or modify the object received by setting its fields or properties to the result of that / those method(s) (those are at the bottom greyed out, like they were inside the CubeProcessing factory and the factory did stuff on them then output them).

So this really separates the data from the processing (methods).

Please ping me guys if you answer so I can receive a notification when you answer me 🙂

[tame harbor]

Hmm, so what makes ECS faster than traditionnal way of coding on the methods aspects ? 🤔

[mighty verge]

1. Because Unity Entities (Unity ECS) is built upon Burst+Job, there are 2 options for you:

• Option 1: If you decide to use Unity ECS, it is technically possible to not use Burst+Job. However this is a bad practice since it will cause very very bad performance to Unity ECS.
• Option 2: You can just use Burst+Job without touching ECS at all. Because it takes a great deal of time and effort to learn how code in ECS.

Either if you choose option 1 or option 2, you must adapt to data-oriented mindset to some degree (less for option 2).

And by the data-oriented mindset, you have to make sure:

• You're going to process data in batch rather than individually.
• You understand the dependency requirements between jobs so you can make them run parallel to each other.

[mighty verge]

2. Optimally you should really just see the CubeProcessing as a single function, not a class in OOP sense.
   In ECS we have systems that are essentially just some functions.
   However C# doesn't allow functions to live independently without some overheads, either you declare them as members of a class/struct or use delegates. So systems in Unity ECS might give out a false sense of an OOP class.

In that diagram, the computer calls the method SetColor() on each instance, which makes that method duplicated in memory (except if I'm wrong on this and every instance points to the same spot in memory for that method).

There will be no code duplication in memory for the same function/method. This is a how programming languages work in general.

You have in memory a unique definition for a type and its members, but multiple instances for the same type. The instances then use the same code from that definition. Yes, as you said "points to the same spot in memory for that method".

[mighty verge]

What make ECS faster than OOP are:

1. It's friendly to the hardware, intimately knows how hardware should handle data in raw bytes.
2. Most of the time, it processes data in batch rather than individually. This also complements point (1).
3. It provides a clear methodology to author parallel code, and best practices to avoid race conditions or other issues in parallelism. So you can have much more code runs in parallel, and be confident about that.
4. It has a rigid execution order (which code must always run before/after which code), consequentially makes your code highly deterministic, and also complements point (1).

Though, good performance isn't free, to achieve this you have to pay a price: You have to abandon the human-friendly code.

It's true even if you only use Burst+Job because they impose the same restrictions upon your code.

Techincally there are built-in tools to bypass them, but you would then be on your own with risky code. And the worst are bad performance and unknown crashes.

Remember that using only Burst+Job requires less technical hurdles compared to using ECS, you can limit their usage to only places that actually matter. But for some kinds of game, it won't give you the highest performance possible.

Though I can argue that ECS gives me not just the best performance but also the maintainability I really need for projects of some size.

[mighty verge]

And what do you mean by "ping me", send you a DM?

Because by replying you directly, it also sends you a notification. 🤔

[tame harbor]

It didn't on the first message you sent me 🙂 but yeah ping me = @ me here or enable the notification when you send the message like you did here 🙂

[tame harbor]

Then I still don't understand the difference between ECS, Job & Burst

[mighty verge]

To speak it simply, ECS requires a paradigm shift, where as you can integrate Burst+Job into OOP code with some changes.

[feral gazelle]

ecs is a pattern
jobs are logic you execute on worker threads (not on the main thread)
burst is a compiler that optimizes your unmanaged code

[mighty verge]

I can hardly see ECS as a pattern. We already have a component pattern for OOP, but in my opinion it's not helpful when it isn't equipped with an architecture and extensively supporting tools.

[feral gazelle]

dod is more of a programming paradigm
ecs is definitely an architectural pattern

[proven warren]

• in ecs/dots, component memory is stored in Struct-of-Arrays (SoA) form which leads to more efficient cache usage and less wasted memory transfer bandwidth
• in ecs/dots, pointer traversal is generally discouraged by standard coding patterns, leading to more efficient cache usage and cpu memory prefetching
• the burst compiler produces much better optimized machine code than il2cpp or mono jit
• the job system makes it easier to utilize many cpu cores

here is a short but solid introduction to how cpu cache usage is critical to performance, it's written from the perspective of java but it applies just as well to c# and most other programming languages https://blogs.oracle.com/javamagazine/post/java-and-the-modern-cpu-part-1-memory-and-the-cache-hierarchy

if you want to really understand caches and memory hierarchies at a deeper level, i recommend this hefty document https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

[tame harbor]

Wow that's so complex 😄

[proven warren]

i recommend reading about cpu caches; once you have a decent grasp of those the points i mentioned will start to make a lot more sense

[tame harbor]

Do you have an equilvanet of that but as a youtube video ? Because I don't like readin but prefer watching video explainations if possible 😄

[proven warren]

i doubt you will find a video as deep as the pdf i linked, but this seems like a good introduction https://www.youtube.com/watch?v=zF4VMombo7U