4 ms·

„ we now use the .NET SDK to embed the .NET runtime. This means we use the CoreCLR runtime for desktop platforms” Wow this is huge! Seems like Unity is lagging

by wnzl 4y ago

„ we now use the .NET SDK to embed the .NET runtime. This means we use the CoreCLR runtime for desktop platforms” Wow this is huge! Seems like Unity is lagging behind and their journey for CoreCLR just started.

andix 4y ago
Unity is still using Mono? The CoreCLR should easily perform twice as good as Mono in many cases.
- wnzl 4y ago
  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-next https://blog.unity.com/engine-platform/unity-and-net-whats-n...
- codetrotter 4y ago
  > Unity is still using Mono? https://docs.unity3d.com/Manual/Mono.html https://docs.unity3d.com/Manual/Mono.html Seems so. In fact, not just Mono but their own fork of Mono.
- 0xDEF 4y ago
  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/dotnetProfileSupport.html https://docs.unity3d.com/Manual/CSharpCompiler.html https://docs.unity3d.com/Manual/CSharpCompiler.html
  - glenneroo 4y ago
    > 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.
  - Rohansi 4y ago
    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.
    - Mikushi 4y ago
      Out of curiosity what engine are you using that leverages .NET (core) ? Stride?
      - Rohansi 4y ago
        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.
- konsuko 4y ago
  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.
  - jackmott42 4y ago
    You can use mono for targets that need it and .NET 6 for those that don't
    - Kwpolska 4y ago
      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?
      - kevingadd 4y ago
        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.]
      - deleted 4y ago
        [deleted]
      - jackmott42 4y ago
        Yet Godot manages it, with a volunteer team and a better overall user experience.
- Thaxll 4y ago
  CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.
  - andix 4y ago
    What are the specific requirements for games? C++ is also not built for games. It’s built for anything, including games.
    - mastax 4y ago
      Consistent low latency, perhaps.
      - deleted 4y ago
        [deleted]
      - andix 4y ago
        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.
  - jackmott42 4y ago
    This is not correct, as can be readily proven to yourself by measuring.
  - gcl09 4y ago
    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-for-gameobjects.1403782/#post-8829403 https://forum.unity.com/threads/performance-optimizations-fo... [2] https://forum.unity.com/threads/expected-performance-of-new-coreclr-vs-mono-vs-il2cpp.1403353/#post-8828794 https://forum.unity.com/threads/expected-performance-of-new-...
sovietmudkipz 4y ago
Hobbyist unity dev here. Can anyone explain the mono/coreCLR commentary in this comment thread? I recently learned that mono works kinda like an interpreted language. This makes sense I think because the internals of unity run C++ code; the C# code is just an interface into the C++ parts of the engine. I haven't done a deep dive into .net ecosystem ever. I probably should at some point. Since I only work in unity and since unity doesn't really play well with the .net ecosystem (e.g. one installs nuget pkgs by downloading the nuget file directly from the website, renaming the file extension to "zip" to then extract the files, and then copy DLLs into an "editor" folder in your project files), I haven't had as much of an incentive. Today I work as a cloud engineer largely focusing on infrastructure set up, and writing GO/bash code for various bits of automation. Before I worked in scala/Java, and before that node.
- jackmott 4y ago
  [dead]
- Karliss 4y ago
  Mono and coreCLR are two alternative implementations for .Net runtime. Just like Firefox and Chrome are two implementations for various web formats, or CPython and PyPy for python language and many other examples. Note in this comment I might be slightly imprecise with the use of naming since the specification, standard library, runtime can be separate projects each with its own name. But often multiple of those parts are made by same people so it can be a bit confusing especially with the way Microsoft names them with various capitalization. Mono started as open source implementation of .Net and means to run C# on Linux when the Microsoft implementation of .Net was fully closed source and worked only on Windows. At that point it made sense for Unity to use whatever open source implementation of .Net they had access to which was mono. Years have passed and a lot of things have changed. At some point Microsoft bought Xamarin(the company that is main contributor/maintainer for mono project). On the other side coreCLR is latest implementation of .Net from Microsoft. Unlike earlier versions of .Net from Microsoft it is open source and compatible with Linux and macOS. As with many languages one of the implementations (the one made by inventor in this case Microsoft) is the leader, while others are playing catch up both in terms of new language feature support and also quality and tooling. Such situation is hard to avoid because developers of one implementation are making whatever they want while being sponsored by big company. While the others are trying to implement something that's more or less compatible with leader while having much smaller budget. In the early days mono at least had the benefits of being open source and crossplatform compatible. Now they have lost this advantage. Even worse, the main contributor of mono is owned by Microsoft so there is high chance that they will slowly kill it in favor of their own implementation. Since the coreCLR is the primary implementation made by Microsoft it will more likely have much better integration and compatiblity with all the developer tooling made by Microsoft (Visual Studio, debugger) , better compatiblity with various third party .Net libraries, better support for new language features.
pjmlp 4y ago
Unity has a full toolchain with AOT compilation for many more platforms than Godot supports, plus HPC#, DOTS, rendering jobs and pluggable rendering pipelines.

by wnzl 4y ago

andix 4y ago

Unity is still using Mono? The CoreCLR should easily perform twice as good as Mono in many cases.

wnzl 4y ago
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-next https://blog.unity.com/engine-platform/unity-and-net-whats-n...
codetrotter 4y ago
> Unity is still using Mono? https://docs.unity3d.com/Manual/Mono.html https://docs.unity3d.com/Manual/Mono.html Seems so. In fact, not just Mono but their own fork of Mono.
0xDEF 4y ago
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/dotnetProfileSupport.html https://docs.unity3d.com/Manual/CSharpCompiler.html https://docs.unity3d.com/Manual/CSharpCompiler.html
- glenneroo 4y ago
  > 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.
- Rohansi 4y ago
  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.
  - Mikushi 4y ago
    Out of curiosity what engine are you using that leverages .NET (core) ? Stride?
    - Rohansi 4y ago
      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.
konsuko 4y ago
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.
- jackmott42 4y ago
  You can use mono for targets that need it and .NET 6 for those that don't
  - Kwpolska 4y ago
    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?
    - kevingadd 4y ago
      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.]
    - deleted 4y ago
      [deleted]
    - jackmott42 4y ago
      Yet Godot manages it, with a volunteer team and a better overall user experience.
Thaxll 4y ago
CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.
- andix 4y ago
  What are the specific requirements for games? C++ is also not built for games. It’s built for anything, including games.
  - mastax 4y ago
    Consistent low latency, perhaps.
    - deleted 4y ago
      [deleted]
    - andix 4y ago
      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.
- jackmott42 4y ago
  This is not correct, as can be readily proven to yourself by measuring.
- gcl09 4y ago
  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-for-gameobjects.1403782/#post-8829403 https://forum.unity.com/threads/performance-optimizations-fo... [2] https://forum.unity.com/threads/expected-performance-of-new-coreclr-vs-mono-vs-il2cpp.1403353/#post-8828794 https://forum.unity.com/threads/expected-performance-of-new-...

sovietmudkipz 4y ago

Hobbyist unity dev here. Can anyone explain the mono/coreCLR commentary in this comment thread? I recently learned that mono works kinda like an interpreted language. This makes sense I think because the internals of unity run C++ code; the C# code is just an interface into the C++ parts of the engine. I haven't done a deep dive into .net ecosystem ever. I probably should at some point. Since I only work in unity and since unity doesn't really play well with the .net ecosystem (e.g. one installs nuget pkgs by downloading the nuget file directly from the website, renaming the file extension to "zip" to then extract the files, and then copy DLLs into an "editor" folder in your project files), I haven't had as much of an incentive. Today I work as a cloud engineer largely focusing on infrastructure set up, and writing GO/bash code for various bits of automation. Before I worked in scala/Java, and before that node.

jackmott 4y ago
[dead]
Karliss 4y ago
Mono and coreCLR are two alternative implementations for .Net runtime. Just like Firefox and Chrome are two implementations for various web formats, or CPython and PyPy for python language and many other examples. Note in this comment I might be slightly imprecise with the use of naming since the specification, standard library, runtime can be separate projects each with its own name. But often multiple of those parts are made by same people so it can be a bit confusing especially with the way Microsoft names them with various capitalization. Mono started as open source implementation of .Net and means to run C# on Linux when the Microsoft implementation of .Net was fully closed source and worked only on Windows. At that point it made sense for Unity to use whatever open source implementation of .Net they had access to which was mono. Years have passed and a lot of things have changed. At some point Microsoft bought Xamarin(the company that is main contributor/maintainer for mono project). On the other side coreCLR is latest implementation of .Net from Microsoft. Unlike earlier versions of .Net from Microsoft it is open source and compatible with Linux and macOS. As with many languages one of the implementations (the one made by inventor in this case Microsoft) is the leader, while others are playing catch up both in terms of new language feature support and also quality and tooling. Such situation is hard to avoid because developers of one implementation are making whatever they want while being sponsored by big company. While the others are trying to implement something that's more or less compatible with leader while having much smaller budget. In the early days mono at least had the benefits of being open source and crossplatform compatible. Now they have lost this advantage. Even worse, the main contributor of mono is owned by Microsoft so there is high chance that they will slowly kill it in favor of their own implementation. Since the coreCLR is the primary implementation made by Microsoft it will more likely have much better integration and compatiblity with all the developer tooling made by Microsoft (Visual Studio, debugger) , better compatiblity with various third party .Net libraries, better support for new language features.

pjmlp 4y ago

Unity has a full toolchain with AOT compilation for many more platforms than Godot supports, plus HPC#, DOTS, rendering jobs and pluggable rendering pipelines.