If DOTS performance is mainly tied to the arrangement of data in memory then...

Unity Engine
, ,
1

it could in theory be compiled from OOP code automatically.

OOP code does not care about the arrangement of data most of the time with little to no memory management or structuring of data, leaving it to the built in GC and memory management features of the language.

With a DOTS/BURST compilation pass it should be possible to re-arrange the data in OOP code to run faster and gain in performance especially if the OOP code is written in a data/system friendly manner.

So could a [DOTS] token applied to OOP methods trigger dots-ification of OOP code gaining performance in key areas (generally only 20% of code is underperforming and limiting to your game/app).

And imagine running a DOTS compiler against the Unity code base automatically it could be worth the time and effort just to gain that level of speed up in the engine/editor.

2

No not only. How you imagine making native array work with interfaces? Things like events virtual methods also do not go well with DoD. It is not magic, making limits on what can go to Jobs and native arrays makes it easy easier too do.

3

When you write ECS code, you’re writing OOP code.

4

This would never be possible with existing C# code. C# depends on like a trillion of quirks of the managed runtime. Check out the language spec. Looking forward to seeing your proof of concept.

And if you’re breaking compatibility with existing C#, then you might as well restrict the syntax to something reasonable for DOD, like the current HPC# subset + a couple of convenience features that we’ll probably be getting soon enough.

When you write OOP code, even as decided to use even go want do look more like

5

I have created monobehavior that is using jobs and array of variables instead of local variables.
And then when I do “update” on it , it performs jobified batch update on all the same components.
The problem is that you have to gather all the data that is unity related (Transforms etc) before update and you set all the unity objects after job is completed (again transforms positions etc).

It does speed up things, problem is it is cumbersome to program, and hard to debug.

6

Yeah I think Unity’s working on a gameobject variant of hybrid renderer 2, something like that. Hard to tell because since going public Unity’s just not interested in talking to people who don’t give them enough money. Sad, but evidence-based.

looks around forum

5 Likes
7

Imagine I have an algorithm like this:

for (int i = 0; i < arr.Length; i++)
{
    for (int j = i + 1; j < arr.Length; j++)
    {
        if (math.distancesq(array[i], array[j]) < 100f)
            counts[i]++;
    }
}

Now do you think a compiler will compile this into a BVH traversal algorithm? Maybe an AI-based compiler could, but certainly no compiler that exists today. The optimal data layout is dependent on the algorithms that use the data. The compiler can only do so much. It can’t write your game code for you.

DOTS isn’t the technology that is going to magically make Game Objects and OOP magically faster. But fortunately, there’s a different technology that Unity is also working on which promises just that. They are updating the C# runtime, with the first big changes coming in 21.2.

Anyways, if you want faster OOP code, please stop asking for it here. There’s the experimental scripting forums and the Burst forums which are both better locations to discuss performance.

6 Likes
8

Weird. I haven’t noticed any decrease of communication from the Hybrid Renderer team since they went public. They hang out in DOTS Graphics subforum now, so people who don’t check that don’t see them active. It is really only that Entities team that has been quiet. But yes. The Hybrid Renderer team appears to also be responsible for the BatchRendererGroup API which they are overhauling for 22.1 and have it working in non-DOTS projects. It wasn’t until a couple of months ago that they announced it would be in 22.1, but they have been regularly communicating these plans for over a year now and have stuck with it.

1 Like
9

I’d argue Animation, Editor, DSP/Audio & DOTS Visual Scripting have been fairly silent in addition to the Entities team.

10

With the animation team, they were upfront about going quiet before the Entities team did. With that said, we know they are making DFG fully-Bursted and multi-threading the “simulation” stage. That’s what all the animation tech is built upon.

The Editor team likely doesn’t really have much to talk about that they didn’t already discuss back in July. There wasn’t much activity on that thread either, and it was clear that they can’t share dates because that’s dependent on Entities who are silent for some reason.

DSP/Audio came out about needing to do a re-evaluation. It was brief, but crystal clear communication.

And Visual Scripting has been MIA since before Entities team went silent. So you have a point there.

2 Likes
11

I guess that’s why I never heard anything much about it as I’m using the gameobject pattern right now, and the BatchRendererGroup API works on that, but is still (correctly) located in DOTS subforum. Would be nice to know about it outside that given it is being overhauled for outside that. I’m looking forward to it.

But in general, Unity just doesn’t communicate anything like they used to, which is causing a number of regulars to be a bit antsy, with good reason considering they’re paying Unity.

12

What is the “simulation” stage here?

13

Probably blending animations, IK, and skinning if it will be still done on the CPU side.

1 Like
14

I feel like I’ve seen this thread before.

9 Likes
15

In DFG currently, it is the main-thread non-bursted stage involving a messaging system, rewiring of “rendering” nodes, and setting “rendering” node constants.

2 Likes
16

Only in OOP Monobehaviours your more likely to have an Update() function that then uses local variables but is called for lots of gameobjects.

Which could be turned into a System that updates those variables in a batch memory aligned fashion.

Ideally you would have something like an UpdateAll() function to differentiate it and to and hint that it’s good to be DOTSifited.

You would probably need profiling and maybe a priority system to ensure the optimal balance between memory batching and performance.

17

How about we convert the OOP code to DOTS and then back to OOP again?

Honestly I don’t understand what problem you’re trying to solve or how you’re trying to solve it, and I don’t think you know either.

18

Its yet another “what if” Arowx thread. There is no problem, but someone tries to fix it.

2 Likes
19

Needless to say - perhaps - whatever is going to be sped up in the core product will be in the absolute newest of engine releases first, if not exclusively. So what you can do, today, with that in mind (for anyone still using outdated/service-only versions), is get your codebases upgraded/working in 2022.1 and help us all by filing bug reports on any and every issue that isn’t already known.

20

It’s the same theme I think lots of the performance of DOTS can be pulled into OOP without all the boilerplate.

This time I’m focusing on the memory alignment management feature of DOTS which is built into DOTS and is just handed over the to compiler in OOP and could be a very easy under the hood optimisation that Unity could adopt.