As stated on Unity C# 8 support - #21 by JoshPeterson it seems you “would like” to bring us .Net 5, which would be a godsend. Do you still “would like” to do it, or do you actually really plan it, and if so, when? 
1 Like
.NET 5 is not scheduled for release until November 2020. We would not be doing any work towards supporting it until that release happens and is supported in Mono. So, sometime in 2021 at the earliest.
9 Likes
Have a read through this to get an idea of what this entails. Note that @xoofx 's prototype was just that, a prototype.
It’s not an either/or. .NET Core does not fix some fundamental issues with Unity, hence why DOTS is prioritised. They’ll get there eventually.
Current in production games are not going to switch to dots, ever, and it’s very questionable if future production games are going to base themselves on dots because of the limiting factor. limits not seen in other game engines.
They could have invested all this time in a solution for all their customers today, a switch to .net core would mean a performance increase for all games right now in the zone of 2 till 10 times faster code.
8 Likes
That is a pretty big assumption. Unity is not a managed code engine. It is a native engine with a managed component. The big bottleneck is the interface between the two, not execution of managed code by itself. With DOTS the interface is not there, it’s executing native code.
What’s the guarantee that the interface between the CoreCLR and managed code is not going to be slower than in the rather heavily customised version of Mono they use?
Do you know anything about .net core? the last years all they have been doing is improving native interop and unsafe code performant code… for instance Span… read about the calli opcode. Using blitable types only where possible… So much could be done. and it would perform tremendously faster than anything in mono. Mono is actually VERY slow with native interop.
As example in the current .net core any native interop is 6-8 nanoseconds per call, plus a bit of cost for the conversion of managed non-blittable types (if any is used like strings, for example).
And actual C# code is being run natively with instrincts… in .net core… I mean… they would have saved so much time.
If they invested their workforce in a .net core port, with a new interop layer, yes it would take some time and no it won’t be always easy. Some things have to be rethought, Native shoulden’t access managed objects too much. etc. so we can also get rid of the bad GC. and go to a generational GC.
But they could manage, and give great performant code for everybody. without forcing people to use a very small subset of the C# language… The reason people went for Unity instead of Unreal is often the C# support, but what they offer in their “new” way is not C#, it has less functionality than C99.
As a professional I’ve talked to many other professionals in the industry, and non are planning to switch to DOTS any time soon, also because of the Alpha status of the project.
7 Likes
If .NET Core doesn’t fix some fundamental issues with Unity, which ones does DOTS fix? Both have only one result: much better performance. The difference is that DOTS has an insanely high barrier to entry while .NET Core wouldn’t require much from the user.
We could have .NET Core, but nope! Visual Scripting for DOTS! To make it more approachable! There’s ways in which DOTS is approachable!
…right? (No.)
6 Likes
I think there are two different things being discussed here. One is the .NET Core 3.1 (or the upcoming .NET 5) class libraries. Another is the CoreCLR runtime.
We’re not planning to switch to .NET Core 3.1 class libraries, as that would be a breaking change for the Unity ecosystem. Any assemblies compiled against .NET Framework 4.7.1 won’t run against .NET Core 3.1. We do plan to start using .NET 5 after it is released, so we want to only break the ecosystem once.
Regarding the runtime, both Mono and IL2CPP will support .NET 5 class libraries. We’re also continuing research on using CoreCLR as the runtime for some platforms. We don’t have anything to report about that yet though.
9 Likes
Multithreaded engine APIs, in an age where processors can concurrently execute a silly number of threads.
1 Like
Are you sure you’re quoting the right bit? I fail to see how visual scripting helps multithreading. It’s good for teaching programming concepts, but you should probably learn how to program instead of making a whole game with visual scripting. It’s C#, not C; not, I don’t know, SPARC assembly. Not Python, if you can’t stand the idea of spaces having any use other than separating identifiers. Eh, I’m definitely biased here on my little crusade against visual scripting and Python.
@JoshPeterson , that is pretty a lame reply. What keep you from starting now? It will take a year for the port with testing and by the time you finish the port, Net 6 LTS will come out and the cycle repeats.
Have you done some research on what changed in .Net5 from .NetCore 3.1? It’s pretty much a superset with some optimizations. I don’t know there will be breaking changes that you will have to redo all your work. As noted from MS blog post, they suggest you to start porting to .NetCore 3.1 and they will try to help make 3.1->5 transition. I’m not a MS fanboy but I trust them that they will deliver on their promises. So forget about .Net 5. Just start with 3.1 and it’s very capable already.
Why all this fuss? Besides all the aging Mono performance issues, Mono fundamentally has problems dealing with native codes. There are well known AppDomain.Reload fiasco and freezing problems. If you pInvoke a native code, it cannot be unloaded until you restart the Editor. Thus, we cannot use many native dlls out there. Try to search Editor freezing issue and you will see many related posts.
Anyway, we all know Unity has to move to .Net soon or later and I don’t know what keeps from doing it now. Yeah, it will break the existing ecosystem, so what? Aren’t you already doing it with DOTS, URP, and pretty much at every release? To save yourself many troubles, just put DOTS on a separate branch, likewise, put .Net Editor on a separate branch and let users decide to adopt it or not. You will not be bogged down by regression bugs supporting the existing users.
If you are afraid of breaking things, you shouldn’t be in the Engine business. I only see it as an excuse.
Sure, the porting will not be easy but it has to be done. There was a guy who did it years ago in a few days. It’s a good barometer that it’s doable. If you put 1/10 of the efforts you put on DOTS, I believe we should already have the working version. And it will help everyone, not just the few who would adopt DOTS.
Let’s be honest here. Not everyone needs DOTS nor we should use it for every project. 90% of projects out there will be fine without DOTS and it will be faster/easier to make it out the door without DOTS. Why we all have to wait and pay for all kinds of regression bugs?
I hope 2020 is not another year we continue to wait for DOTS. I love DOTS but it will not be relevant to the many until it’s PRODUCTION ready. Unity has no idea what’s production-ready because Unity is doesn’t have anything in productions. It’s up to users to say it when it’s productions ready and I’m sure it will take at least a year or two.
If you agree with any of the above, please reconsider putting your highest priority for the .Net port. I don’t think there is anything more important than fixing the clunky Editor right now.
My two cents.
26 Likes
Yeah, sorry, not quoting the right bit at all. I am referring to DOTS, not visual scripting. I personally couldn’t care less about the latter and feel it should be a bought add on. A couple of years ago, when I stated my opinion on this, it was pointed out in no uncertain terms that it is apparently the most requested feature and it does make me wonder who the people requesting it actually are that do not have access to it via third parties already.
4 Likes
Yep.
Most projects at my work are technically not that demanding that it would justify to throw away all existing code and start over with DOTS. The additional complexity introduced by DOTS wouldn’t pay off for these types of games, I guess.
If replacing Mono gets us a great benefit, it would affect all projects at my work “immediately”. DOTS would affect zero projects here, at least for several years. I have to maintain several existing games that are all MonoBehaviour style.
If I could choose between:
- Things improve for all my existing and new projects in 6-12 months
- Things improve for new projects in 2-3 years
I would pick option 1. Not only because of the improved performance, but because of new possibilities such as partial domain reload, which would make working in the editor a whole lot better as a programmer. I would even choose 1 if DOTS was finished yesterday.
Investing time in replacing Mono doesn’t have to mean to stop DOTS. It would be probably different teams who work on that. It’s probably just a priority juggling act, because for us Unity users, everything is important 
PS: DOTS is great and I want it to happen! But I personally would favor short-term Mono improvements over long-term DOTS.
18 Likes
And not just you @Peter77 , Many many real game developers here are in the same boat.
DOTS is a funny concept, but most games will not profit from it, games are rarely updating 200.000 units in the same parallel way.
Object orientated design is not necessary bad, slower or worse than a ECS approach. It just depends on how you build it and work with it.
But what for sure matters is us stuck on on a terrible old Mono build, which performs like crap, which could have been replaced with something better today, making all our code run 2 till 10 times as fast, without any code changes from us!
And NO il2cpp is NOT a solution, at best it performs about 2 times as fast, most of the time slower, or same. or slightly better. il2cpp is just not a solution for the problem, developer iteration times are horrendous, random weird bugs, crashes, instability, nobody wants to use this in production games. It was meant for iOS to overcome some Apple limitation, keep it there!
.net core outperforms il2cpp, in all cases, in actual games/code.
Were talking here about ACTUAL games, on ACTUAL platforms that sell millions of copies (Windows 10 x64).
Projects like that are not using or probably ever will use DOTS or its limiting runtime.
We need .net core in unity and we need it now. not in 2022.
20 Likes
Alright. Then I agree with your point on multithreading. Theoretically, at least, I haven’t used it. That’s still just the Job System, not all of DOTS. Not sure about Burst, we’d need more benchmarks of CoreCLR vs CoreRT vs Burst, or whatever, as well as combinations of those. Not that it can be accurately done without a .NET Core version of the engine.
More benchmarks you say?
They exist already for instance here:
.net core shows almost same performance as burst in real world code.
6 Likes
Score. So RyuJIT so far destroys Mono (2 to 10 times faster) and often at least matches IL2CPP (0.6 to 2 times speed). For Mono, consider that it will be merged into .NET 5 (or added as a runtime option, that’s unclear); and for IL2CPP, consider that the linked benchmark doesn’t even include CoreRT.
I’d love to add Burst to the obsolete in-house Unity tech list, but as pointed out by Joachim, Burst should be faster for its use-case of SIMD operations.
For Burst, I was thinking that the engine overhead would skew results, but thinking about it, we’re talking about production scenarios, not contrived examples. In any case, good thing I brought it up.
2 Likes
You can write instrincts and SIMD vector math with. Net core too. You don’t need burst for this. And it works on the complete framework.
Just check out the System.Numerics for instance where the vector math is Automatically SMID enabled.
Or you could write manual SMID if you need it.
https://instil.co/2016/03/21/parallelism-on-a-single-core-simd-with-c/
1 Like
Oh boy. Could Burst and a good chunk of the naming mess that is Unity.Mathematics go as well?
Summary: Unity is wasting way too many resources by reinventing the wheel on Mono instead of switching to the official runtime and libraries.
4 Likes