Hacker News Reader

Comment by andix | Hacker News Reader

Unity is still using Mono?

The CoreCLR should easily perform twice as good as Mono in many cases.

Yes and no, Unity uses its own fork of Mono. When .NET evolved it keeps on using the forked mono and apparently CoreCLR is one of their priorities accordingly to blogpost here https://blog.unity.com/engine-platform/unity-and-net-whats-n...

They use their own heavily optimized Mono runtime that is .Net Standard 2.1 compliant and supports all C# 8 and many C# 9 features.

As a C#/.Net developer I'm satisfied with the C# and .Net support in Unity. The pain points are elsewhere.

https://docs.unity3d.com/Manual/dotnetProfileSupport.html

https://docs.unity3d.com/Manual/CSharpCompiler.html

> The pain points are elsewhere.

Not sure if this is what you mean but one huge pain point for almost every dev is that code changes necessitate a project reload, which, even with domain reload can be extremely slow and gets worse the larger the project becomes.... which is why I'm extremely exuberant about the new hot-reload plugins which allow editing code while a project is running and changes will be patched in real time! For me it's comparable to when SSDs first came out, finally we were able to ditch slow spinning rust. I've been using it for a couple days now and I've probably already saved a few hours.

I've been using HotReload.net which is free for Unity Personal Edition but there's also an asset on the store for ~40€ but i haven't looked at it yet.

As a developer on one of larger Unity games - yes, there are paint points elsewhere. There are many pain points. The poor performance of Mono/IL2CPP is a significant one for us. We have a different game built on .NET (Core) and performance is significantly better.

I also wouldn't call Unity's Mono 'heavily optimized' because they definitely trail behind standard Mono. Unity doesn't even support Mono's generational garbage collector but it has been the default in Mono since 2016.

Out of curiosity what engine are you using that leverages .NET (core) ? Stride?

It's an engine written in C++ (not Unreal) that we've added C# scripting to. So it's in the same kind of situation as Unity where their engine calls from C# land need to be marshaled into calls to native code and back, which of course has overhead.

> Unity is still using Mono?

https://docs.unity3d.com/Manual/Mono.html

Seems so. In fact, not just Mono but their own fork of Mono.

They have to use Mono. New .NET Core Runtime does not yet support all platforms that Mono used to support, and won't for a while.

You can use mono for targets that need it and .NET 6 for those that don't

Keeping two implementations side by side would be expensive to maintain and not a good user experience: you start writing nice, "modern" .NET6 code and then need to rewrite things to run on top of .NET4-ish (and the older BCL and C#).

And I think .NET6 supports mobile now?

Mono was largely folded into CoreCLR a couple releases ago and part of that infrastructure is used to support some targets like mobile and WebAssembly.

[disclosure: I work on Mono at Microsoft.]

Yet Godot manages it, with a volunteer team and a better overall user experience.

CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.

Sorry but that makes no sense. Here are quotes from the C#/.NET group director at unity about how the migration to CoreCLR should bring a large perf boost: "One thing that should help in the future is the migration to CoreCLR that should provide a great boost in terms of performance."[1] "What we have seen, outside of Unity, is that performance with CoreCLR compared to Mono should range from 2x to 10x faster." [2]

[1] https://forum.unity.com/threads/performance-optimizations-fo... [2] https://forum.unity.com/threads/expected-performance-of-new-...

"outside of Unity"

Because unity is not yet on CoreCLR. But unity shouldn‘t be much different to other applications. Jetbrains moved Rider only a few years ago to .NET Core, and everything became much snappier (it was on on .NET 4.x on windows and on mono for Linux/Mac before, which was even slower than the windows only full framework)

This claim would make more sense if the Mono was heavily optimized specifically for games, which is not the case. CoreCLR is heavily optimized period

Exactly. For ASP.NET they also optimized latency heavily.

What are the specific requirements for games? C++ is also not built for games. It’s built for anything, including games.

Consistent low latency, perhaps.

I don't see a lot of options how you should optimize that, besides using allocation free code. .NET (Core) did a lot of work into this direction for Kestrel HTTP server already (Span, ref structs). It's still a managed platform with a garbage collector, but I don't think games have such low-latency requirements, that can't be handled with the standard garbage collector. A few milliseconds are usually fine for games, even with 120Hz the time between two frames is still 8ms. And garbage collection can be suspended during critical phases.

Is it also webscale? /s

This is not correct, as can be readily proven to yourself by measuring.

Reply on news.ycombinator.com