.Net 5 support

As stated on https://forum.unity.com/threads/unity-c-8-support.663757/#post-5331426 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?

 

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.

 

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.

 

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.)

 

Multithreaded engine APIs, in an age where processors can concurrently execute a silly number of threads.

 

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.

 

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.

 

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:

1. Things improve for all my existing and new projects in 6-12 months
2. 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.

 

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.

 

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:
https://forum.unity.com/threads/ben...fibonacci-mandelbrot-nbody-and-others.715133/

.net core shows almost same performance as burst in real world code.

 

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.

 

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.
https://docs.microsoft.com/en-us/dotnet/api/system.numerics?view=netcore-3.1

Or you could write manual SMID if you need it.
https://fiigii.com/2019/03/03/Hardware-intrinsic-in-NET-Core-3-0-Introduction/
https://habr.com/en/post/467689/
https://instil.co/2016/03/21/parallelism-on-a-single-core-simd-with-c/

 

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.

 

Unity's idea here is that what is faster than native interop is native code and having parts of the engine that were C++ before be written in C#. It is a pretty sound idea. It should just be done *as well* as a .NET Core port, rather than instead of.

 

Why would .NET Core 5 port break Unity ecosystem? Would Monobehaviour stop working ?

 

No, it is just that .NET 5 is in preview still, so they will not waste work on something that is still changing. It was already told that they are planning to support .NET 5 once it is fully released, and .NET 5 is only coming out in the end of the year, so we should expect support for next year (however, no official date was mentioned yet).

 

Yes, EXACTLY, Unity always has to re-invent the wheel, and usually worse than the experts in wheel making. Just look at their naming scheme of their math library.
Their reasoning is that HLSL developers can easy port code. You don't make this up.
99.999999999% of the time people use a math library they are not porting HLSL shaders.
Probably more like 100% of the time. .net naming standards exist for a reason......

If there were some things missing for unity in the official Numerics library, they could add to it or supply a helper class or class extension, it would take no real development effort.

The idea to drop C# support in general is unbelievable to me, Forcing us all to drop the whole of C#, to only support a few basic types, and only structs, basically means we loose all of C#, and... why exactly? Burst is not nessisary faster than .net core........ It seems to me Unity made a GIANT mistake investing 3 years of development in burst. That could have been invested in moving the engine to .net core.. and give us a modern .net runtime... for all our projects.. today.

It is still not too late. they should stop everything they are wasting on burst/dots/ecs and invest it in a full engine port to .net core. which can flow into .net 5.0.

I am not the only person that thinks this, every professional I talked to in the Industry that makes actual games, that get released and sold are saying the same thing. they have slowely lost all trust in Unity in the last years, and I've seen many move to Unreal, the only thing holding those companies back is usually C# support in Unreal, and right now Unity is dropping it.. It's unbelievable.

 

.NET CORE and .NET 5 are not compatible with .NET 4.x. In many cases even a pure recompile is not enough. Many old API were removed.

Burst is already out of preview, and ECS target an different Bottleneck.

With an simple .NET CORE/5 upgrade you will never achieve the same performance as full DOTS (Bust/ECS/Jobs)

• With .NET Core you don't have automatically a better memory layout for GameObject and components
• .NET Core don't have auto vectorization.
• Job system suitable better for games then the Task library.
• .NET Core does not solve GC problems

But you get the best performance with DOTS + .NET CORE/5

 

I came from UE3 because I love C# and I decided to give Unity another chance. I fell for Unity's United event in 2018 when they announced DOTS, Kinematica, SRP, and others. I got so excited and I thought Unity is really trying to make some changes. Fast forward two years, and where we are now? DOTS still in its infancy, Kinematica is MIA, and SRP is still in the fluke. The execution has been a big mess. Compounded on the top all that, I never expected that I had to fight clunky Editor every day until I started a largescale project.

Right now I pretty much fed up with Unity and realized that Unity really hasn't changed anything since 2009. They are still Lazy, Stubborn, and Incompetent. Every day, it feels like I have to put up with their excuses and spend more time fighting the Editor and finding workarounds rather than working on the game.

Well, if there is hope, I still love C#. The biggest advantage of C# is its productivity but Unity's implementation does not take the full advantage. Thanks to AppDomain.Reload. Every single time you click on "Play", you will have to wait 10 to 20 seconds. I fought really hard to bring the Fast-Enter-To-Play mode to Unity. It took 20 years to bring the feature. But is that enough? not quite. You still have to reload everything every single time you modify the code and it can take ~30 seconds to a minute. At this rate, it's about the same as Unreal Engine compile c++ code. And you have to deal with the clunky Editor as a bonus. So incredible that they left their own baby in this state for such a long time. Probably because they don't eat their own dog food to realize, otherwise, they should've done something about it a long time ago.

"Just drop everything and fix the Editor" If I were Unity's CEO, I would probably say that. Seriously, Unity needs to sit down and think about what's really important. New features are important but it's like building a skyscraper on top of the sand. It will only slow things down even further. Not enough resources? From what I heard, Unity is trying to go public soon and it's worth a few billion. I'm pretty certain Unity can afford a few talented developers who can do the port, am I wrong? Still afraid of breaking things? Then hire some more at the cost of marketing personal if you have to. I don't think Unity really needs to market anything, instead, Unity really needs to deliver on their promises.

Anyway, my patience (and I'm sure there are many who shares the same) is running out and I'm waiting for Epic to introduce the new Scripting Language. It's no secret Epic is working on it. And from my trusted source, they working very hard right now. If Unity keeps the same attitude like they have shown thus far, I'm pretty certain that Unity will become history. Unreal is already miles better than Unity and it comes with bell-and-whistles. The only thing that keeps Unity going is C# and the community around it. Just don't lose it.

-from the bottom of my heart.

 

You are wrong, do you even know what the .net standard is?

That really depends on your implementation, you can make high performant code with any paradigm.

Nothing stops you from using an unmanaged allocator for that as Unity does.

It is Easy as hell to use hardware-accelerated vector types where you really need them.
Auto vectorization fails usually anyway with normal game code. But there is availability in .net 5.0

Use any scheduler with TPL you like and do pretty much exactly the same.

Yes it does solve it. and if it's not enough you can use an unmanaged memory allocator as already said.

Stop repeating lies you read on forums and know the actual technology, Unity is not making some kind of magic cool-aid. You clearly don't make actual production games in a professional company or you would not post such things.
Burst is nothing more than LLVM with some tweaks on top. Jobs have a big overhead not seen in the .net core TPL. This topic can go on and on.

Unity should stop this circus, focus on .net core, /.net 5.0 today. Not next year.

 

I'm gonna add my two cents to the discussion.

When I first started using Unity like 7 years ago, I got into it as a teenager because it was easy. And I got into C# because it was easy! I thought that was Unity's thing, "make things easy". DOTS is far from easy for a beginner or even intermediate in some cases. The "performance by default" motto is basically "Performance by default... if you really know what you're doing." I'm not saying DOTS is bad in any way. I love the job systems... when I can get it to work and I do believe there are use cases for it. But 95% of the Unity users won't need DOTS because we are not trying to simulate an entire city down to an individual level in real-time, at least not as far as I'm aware.

Hell, I wouldn't say Unity is bad in performance from the get-go. Sure, it could be better and that's where I believe .NET Core/5 could come in. This will truly give us "performance by default" and not strip away everything that makes C# great. The Mono backend is quickly aging and if Unity doesn't act, we'll have another story where we are stuck with an old framework again for years. Like others have said, branch of a group of people to start the porting now. .NET 5 is in preview because you're supposed to be able to start adopting it already. With the argument "we won't use it because it's in preview" in mind, like 80% of Unity's features wouldn't be used right now.
Yes, old projects will most likely break! You have to break something for a better future. But you need to break it elegantly. The .NET Core/5 version has to be released AFTER an LTS version and make it clear that this version breaks a lot and no new projects should be upgraded to this version. It's a harsh but necessary reality.

So to summarize, there's basically no reason to sit and wait. The editor is slowing down for each release and people are craving for a performance upgrade. As many have stated, .NET Core/5 will give those important improvements people are craving. Even if you just said "We will start working on this now but it won't be ready for a year", people would be extremely happy. We need it now and not later. .NET 5 is already fast approaching, even if it's at the end of the year. If you don't start now, and with the pace of other very important features in mind, we will have that .NET 5 version in Unity 2024.

 

I said .NET 4.x, a large number of assemblies are not compiled with standard, especially if you use API that are not covered with standard.

But not with the current GameObject and MonoBehaviour

I said GameObject and components (MonoBehaviour), they are reference types. An .NET upgrade do not change the behaviour and memorylayout.

Source?

With TPL you don't have much control over which core the tasks are processed. So it can happen that tasks have to share the same core as the mainthread. The job system avoid this if possible. Don't get me wrong, I like TPL and i use it in some cases, but TPL and async/await are designed for GUI business applications, not for games.

.NET core also has a GC, a better one, but it's still there. There will still be GC spikes there, smaller, but still there. (Especially with inexperienced programmers)

You right, i am an web developer, not a game developer, its only an hobby.
I think i will test the performance between TPL and Job system when i have time, but I have already experience that the context switch is very expensive at TPL. I would also be interested in the difference.
What is wrong about Burst is using LLVM/Clang? Is a grad compiler.

.NET core is not magic either, it make a lot better, but it doesn't solve everything. .NET is not designed for games, what is fast for console/GUI/website applications, can be very slow in games.

 

With a simple test:
medium time of 10x 200 Jobs/Tasks Fibonacci (35)

• .NET CORE 3.1, Task.Run and WaitAll: 3137ms
• JobSystem CompleteAll: 1399ms
• JobSystem CompleteAll with burst: 796ms

 

Care to clarify? If having to recompile is the biggest of your worries when updating a dependency (it shouldn't be an issue at all), you're doing something seriously wrong.

 

https://docs.microsoft.com/en-us/dotnet/core/compatibility/fx-core
https://docs.microsoft.com/en-us/dotnet/core/compatibility/unsupported-apis

 

He mentioned recompilation, not API changes.

 

I suspect what he is referring to is an ecosystem problem. Specifically that loads of third party assets ship as precompiled assemblies and those will need to be updated and re-shipped to customers.

I would personally question how much of a problem that is, considering compatibility has been broken between engine versions a good number of times now.

 

If the library target .NET standard, you only need recompiling in some cases.
If the library target .NET 4.x it depends on the API used. Some can simple recompile, other needs deep changes in the code.

I also waiting for .NET CORE in Unity, but better they do it slowly and safely than quickly and with lots of bugs, there is already enough.

 

That doesn't make sense.
• Build your application.
• New engine version: .NET 5 update.
• Update the engine and upgrade the project, deal with API changes, new bugs, that stuff.
• Update assets: they're supposed to deal with the update too.
• Build your application.
What does having to recompile complicate here? If a closed-source asset doesn't update, there's nothing you can do unless you're willing to mess with decompilation and legality, that's invariably the case with breaking changes of any size, and the only thing that the amount of necessary changes affects is how willing the developers are to update — maybe that's what you're actually talking about here. You shouldn't depend on 300 assets anyway.

Goodness. Compilation is an unavoidable part of software development, it's not a hard or lengthy thing to do. I never understood this "recompile bad" thing, it's just stupid. I swear I keep hearing "If you don't use this shiny principle, then you'll have to recompile your program when you make a change" — damn right you will! But of course, now that I need a source, I can't find any.

 

That can be the critical parts, for some existing projects in development, the effort could be too expensive in time and money (depends on the project). Asset developers must also update their assets.

But if you look at how often people update their projects blindly during an update and cry that nothing work any more, you can understand Unity well if they take it carefully.
I think .NET 5+ won't be until 2022.1 replace the old .NET in the editor. Maybe as experimental in 2021.x.

 

Isn't that what LTS is for? Not that Unity's has been a big success.

You can't just switch to some parts of the new framework. This is just an unjustified delay at this point, they're simply choosing to break "everything" later (which can be anywhere from a year to a decade or more — it's Unity), not now.

 

Gathered some good news from latest blog: Atleast, they will update their Mono fork "soon", so we'll get nice performance increase and latest features (oh, Span<T>), still better than nothing.

 

Well, yeah, we're not disagreeing here.

That is their reasoning, I didn't say I agree with it.

 

We don't want mono though, On platforms that are supported by .net core we want it, and we don't want a forked mono build with 1000 special tweaks and fixes so it works on the broken unity core engine. instead fix the damn engine so we can keep up to date with every .net release. this is not a solution but more like bandaid.

The latest mono JIT is still around 50% slower than RyuJIT.

Keeping mono on platforms like Windows/Mac/Linux is simply unacceptable!

I ran all the benchmarks from another thread here in the forums, both in current Unity Mono JIT, The latest Mono JIT 6.8.0, and in the latest .net core 3.1 RyuJIT.
The results are obvious. We need .net core. not mono.

Check the results here:
https://ibb.co/album/ksuxLa

For instance:

 

Another Mono?
And it arrives in 2021? WTF!@#! Whoever made that decision should be spanked real hard!
It explains why Unity won't look at .Net port.

I booked marked this site, https://github.com/NegInfinity/ProjectExodus , just in case.
It's time to revisit.

 

Interesting benchmarking. Honestly at this point, it is better than nothing. Even though, I completly agree, still a shame they refuse/take so much time to move to .Net Core while it has been proved it is possible to do so pretty "quickly".
Unity, you're promising us every year that you'll improve performances, but you're always failing to deliver it. No, i don't want to redo my whole code to work with DOTS, I don't care about displaying millions of time. Please, we're waiting since years, we can't wait any more.

 

Every single .dll in every single user Unity project that targets some libraries with new names will have to be recompiled, unless I'm missing something important. Users might not have the sources for those .dll's to rebuild them.

So that'll be a pain.

 

Sure, but why won't you start the sail now? The outlook looks pretty good to me, or are you waiting until the ocean perfectly calm? You know it will never happen.

 

"We are working towards this now" sounds extremely promising. Care to elaborate exactly what you guys are working towards? Is it just a mono upgrade that has mentioned here and there or is it any work on .NET Core/5? We understand that you can't say like "Unity with .NET 5 in 2021.1!" but just something like "this is what we're doing".

 

From gauging Unity's track records, if it's not on the Roadmap, it's as good as it doesn't exist. I hope I don't have to prove it. Even the things on the Roadmap doesn't often get delivered on time and it's hard to take the words as is. Sorry.

Sure, it's too early to make the announcement, but here is what I like to hear in the 2020 slogan.

"Performance by Default everywhere! including the Editor!"

To expand the slogan, "We've focused on the Performance by Default. Thanks to DOTS and you've seen many examples of what it is capable of Runtime. Now we are expanding the Editor as well. Our next highest focus now is on the Editor and you will see the significant increase in performance throughout the year. We will make the development as transparent as possible and by putting it on the independent branch to provide the build as it happens without interfering with the main branch. Please stay tuned for more info."

How about that? If you can't even make that announcement, what you say is probably just a lip-service.