Compilers tend to keep code close to the intent of the programmer so that any bugs are the programmers fault.
But what if there was a DOTS compiler that could take any code analyse it and break apart the functions and data into ECS systems and compile it with Burst SIMD optimisations with a two simple compiler arguments
-DOTS
-BURST
Or could Unity take Rosyln compiler technology and add DOTS and BURST to it so that any developer could take advantage of the performance boost of DOTS.
The thing is if Unity do not create the compiler version of DOTS how long before someone else does?
I don’t think you read any of my posts on the topic, a cross multiple threads. You just repeating same thing over, you already posted, with just different words
What’s the point?
I think the quicker solution is to properly provide support and learning materials for programmers to correctly develop with DOTS. It’s not hard but is a huge f-ing mystery to most people, and that’s understandable this early in development.
I’d say in a couple of years the docs might be catching up. Best practises and perhaps a snippets library will go a long way.
The rest of the way has to be an improved set of calls on Unity’s side. It’s still a bit of a mess, and it’s still easy to make performance mistakes.
It’s not however, hard to code in DOTS! It is just very hard to make the right decisions with so little information to go around on a changing target at present. Another great reason for Unity to step back a little and get some good beefy work done in 2021 (which they are doing).
There will always be corner cases where DOTS will have its usage. However the boiler plate code and the overall development requirements will make DOTS less appealing in general.
I’m pretty sure future compiler improvements will close the performance gap and make DOTS a niche thing within the Unity environment.
When we are at this point the human brain will be worthless and we probably live in some form of simulation. Till that happens, we have to make our own choices which data format is best for the machine.
Seriously, if you’ve ever translated OOP code into proper DOTS code you would answer the question for yourself. It’s next to impossible for any software to analyse code that is not running and change data structures AND code to be more performant, multi threaded and still work. If we can be hopeful Entities will, at some point be able to re-arrange chunks for more performance. The groundwork, which means, great data structure, still has to be done.
We’re at the first steps where we turn code (sometimes) into SIMD code, what you’re asking is like 100 steps in the future.
Remember it’s just tokens, your code is just ascii and your data is just binary information. Your current compiler is jumping through hoops and doing backflips to convert your code into assembly.
GPU developers re-write their drivers every couple of months to ensure games run fast on their GPU hardware.
To say that a compiler could not take Jobified and Batch based Burst enabled OOP code and wrangle the data to follow the ECS/DOTS approach sounds silly to me. Maybe we might not be able to get 100% of what a dedicated DOTS version would hit but I’m guessing we could hit 80-90% of the performance without writing one line of DOTS code.
And IMHO with a dedicated OOP - DOTS API I think we could have 100% of the performance without the 90% of the hassle. After all a System is just a Methods call dressed up as a class.
There is much Unity can apply to make regular C# feel as a fast as a pure DOTS program, from underlying engine work to everything else, but have game logic high level C#.
That can be achieved, but what you are suggesting would cost billions. Because there are endless ways to create OOP memory access patterns that may not work when converted to DOTS. Because when you have a class with data and code together, accessing another class with data and code together, you would need to first separate the data from the code for both classes. Then you would need to parallelise that too. Chicken and egg problems begin. And this is long before anything actually compiles.
I think as a practical reply to your topic two realistic options:
Can make Unity DOTS driven entirely, with a thin layer between OOP game logic and the underlying DOTS (a better hybrid) - treat high level C# as a scripting layer. This is basically the mono of today, but talking to C++ instead of DOTS.
Can just keep building on DOTS, making it easier to program in, with more snippets, more support, better catch-you-at-the-editor compilation checks and even Rider-style advisories. Better docs, examples, tuts and making it hard to write bad DOTS code.
I believe these are the only realistic options for the next 5 years.
But seriously, can you provide some sample code of what an input to this “compiler” would be and what the output would be? It will provide a more concrete foundation to the viability of such a thing, so that we can stop with the “I think that’s impossible, but you think it is stupid that it isn’t being worked on” dialogue.
So basically people are saying that a compiler could not convert our data and code from Array of Structs to Struct of Arrays to get maximum SIMD and cache performance optimisations.
You underestimate how difficult it is to create such compiler. Do you know how many permutations there are of different kinds of reference ownership and access? If it were that easy, Unity might have gone that route a long time ago as they did with IL2CPP.
To me, making a new language that’s ECS aware that compiles down to DOTS is I think more realistic. However, that strategy is untenable as it loses out the huge ecosystem of C#.
Yep, ECS doesn’t really care what the language is, only that you can have a clearly described pattern. Unity picked C# because they’re used to it, their customers are used to it and they learned the mistakes of having Boo and JS to support at the same time, and in software development, every decision made is years of support costs.
