Does the very design/architecture of Unity prevent maximum performance for DOTS?

DOTS or ECS is based on maximising cache utilisation for processing lots of data fast.

Within the Unity game Engine there are lots of external libraries that all game engines use for features like rendering, sound, lighting, input etc. These tend to be in DLL files external to the main codebase that have to be loaded into memory and have data passed to them.

Just check your Build folder Managed e.g. 80 dll files weighting in at 17.7 MB of code.

But they are not DOTS based systems utilising the same optimised memory processing approach, so surely they will slow down DOTS based games.

For a truly DOTS based game engine would Unity need a 100% DOTS based ecosystem minimizing data transitions/handling and passing within the entire ecosystem (can't say System as that's just one method in DOTS).

And what if Unity could compile multiple interactive DOTS system to maximise both data throughput and code throughput e.g. combining systems to reduce data handling e.g.

System A uses DataType d1 and sends d2 to System B, however the compiler notes that the OP code size of A and B could fit into the cache and allow for in-lining of System B code into System A.

Assuming the interim d2 is not used by other systems.

 

Project Tiny is the answer to the most minimalistic stripped version of the engine (DOTS only).

I think its just a matter of time and perspective. Drastic changes to the large codebase cannot be done in an instant.


Premature optimization is the root of all evil. (c)

As for the build size:
Even for mobile its fine to have minimum 30MB game size with max unbound.
So build size is pretty much irrelevant. Most of the build space isn't the code though in most cases.

 

Arrows, looking at your post history, pretty much all posts are thread starters and start with “Could…Unity…DOTS…”, and are a weird mix of deep technical insight and lack thereof. While you are amazingly successful to trigger a discussion, your recent salve of new threads made me curious: what are you trying to accomplish? Is this for entertainment of yourself or of the community craving for official news? Philosophizing for the fun of it? Or are you on a quest to nudge Unity into a certain strategic direction?

 

It's more of a love hate thing I was on the forums when there was a community push for batch based vectorisation to improve the performance of Unity. And Unity has improved with BURST and Jobs then instead of creating a batch based vectorised multi-threaded version of the API they went and created DOTS this weird Data Driven architecture that is constantly changing adds all this complexity to what used to be a method call.

This is me trying to get my head around DOTS and also nudge Unity into meeting me halfway with an easier to use and adopt version of DOTS that could be easily refactored from an OOP code base.

Ideally the additions of a simple [DOTS] tag on a BatchUpdate() method would trigger the compiler to DOTSify and boost the performance of that part of the code base.

 

I think Project Tiny is in limbo right now but it could be the ideal candidate for reducing game code down to cache size.

 

Unity has already done everything you say you want. You can Burst-ify any Burst-compatible function just with the attribute. There are custom jobs API for transforms, physics queries, particle systems, and animation. There's native APIs for networking, navmeshes, uploading/download, sprites, meshes, textures, compute buffers, and lightmapping. There's stuff for XR and neural networks. Draw call dispatch is coming in 22.1. All of this is exactly for your use case.

If something is missing in those APIs where you are having performance problems, let Unity know!

The Entities ecosystem is for people who want to move away from the OOP paradigm with a new API that has been built from the ground up with Burst and the job system in mind.

 

Then you must realise that it's in it's own performance bubble and as soon as external none DOTS systems are used you are losing performance and being limited by those systems lack of performance.

Without a fully DOTS based Unity engine and DOTS friendly external API's (e.g. DirectX, Input, Sound) and even OS features part of your super fast DOTS games will be be waiting for and slowed down by none DOTS systems.

It's like your F1 DOTS racing car in a long distance race where the only refuelling Truck has to follow you and catch up before you can continue.

Or just look at the 1:2 - 1:3 frame time ratio of CPU ms timings vs GPU ms timings. Even a 1ms DOTS CPU frame time could still be frame rate limited by GPU time.

 

So what are you proposing ? that Unity aims to align it own performances on the performances of the extrenal API it uses ? for what ?
When one is running, sometimes one get in a more crowded environment where one has to slow down to the speed of other people (who are just jogging, for example). Should one just train to match the speed of the slowest of the other runners ? I think not. When I was running, I was always trying to run faster than myself, no matter the exhaustion.

I think there are people around here trying to achieve games that have particular technical challenges, and that it is a place where the DOTS ecosystem shines.

You're talking about being GPU bound, but it seems to me that this is precisely where you could use DOTS to implement clever and efficient algorithms, aiming to offload the GPU of some work. There again, you don't care about the speed of this or that external API.

Lastly, while you're waiting for the refuelling Truck, you have time to enjoy yourself
(meaning: you can do extra CPU work, add extra juice to your game, use more precise algorithm, etc...).

And just to be clear for others that could be enrolling in your way of thinking: imo it is never a bad thing to have more performance. But the reality is that we usually maintain a tradeoff between the time it takes to complete a task (as a programmer) and the performance of the code we produce. It is not because we don't like performance that much, it's just that we're forced to do so because time is money and we usually don't have that much of it.

 

Unity would have to go fully DOTSy to take full advantage of available CPU bandwidth and to minimise internal and external API bottlenecks.

And take it further than that to partner with hardware vendors so that their API's and Drivers have DOTS compatibility and maintain performance throughout the software stack.

 

I think Unity is working toward that, yes. They are on several platforms with a voice on the direction - both on the driver side and on the software side.

But try not to mix question/answer post with theoretical things in a subforum dedicated to Q/A unless there's code to back up the theory as I'd have to move it to general.

 

Ok, my bad, I thought the post was aimed at the community.