Unity Future .NET Development Status

So the takeaway is free runtime performance (with mono) on 2021.2.0b5 and forward?

 

Beta 6 is out with .Net Standard 2.1 it seems: https://unity3d.com/unity/beta/2021.2.0b6

 

A few things of note:

• Despite .NET Standard 2.1 being used, Unity still defines NET_STANDARD_2_0 (and then a new NET_STANDARD define, rather than NET_STANDARD_2_1). This inconsistency is a bit of a pain point for existing code.
  
• There seems to be a conflict with types from the System.Numerics namespace, preventing any code using them from compiling (this previously worked fine under .NET Standard 2.0):

Made a bug report for the second one. Case number 1355608.

 

do you have System.Numerics.Vectors.dll in you project?
System.Numerics.Vectors wasn't part of NET Statdard 2.0 so it should be some extnal dll.
But they are part of NET Standard 2.1. so you just need to remove this dll from your project

 

I don't have System.Numerics.Vectors in my project. This error can be reproduced with a fresh project.

 

b6 breaks projects that use certain features from System.Memory.

For example, we get

Code (CSharp):

1. error CS0570: 'ReadOnlySpan<T>.this[int].get' is not supported by the language

because of this

Code (CSharp):

1. void SomeMethod(ReadOnlySpan<byte> s) {
2.     var x = s[0];
3. }

We also have

Code (CSharp):

1. error CS0570: 'ReadOnlySpan<T>.GetPinnableReference()' is not supported by the language
2. error CS8385: The given expression cannot be used in a fixed statement

when trying to use a span in a fixed context.


Previously, it all worked fine since System.Memory has the indexer for ReadonlySpan.
Now, since we can't use System.Memory.dll because it conflicts with mscorlib, all projects that previously used that will be broken.

Edit: This issue is present when using .NET Framework. On .NET standard it seems fine.

 

Works fine for me but I'm targeting net standard.

 

Yeah, standard seems fine. I'll edit the post with the new info.
On this particular project, I depend on Odin Inspector, which doesn't work on standard, so I need framework on it.

 

Maybe try standard, there's a tiny chance that's what Odin uses is in the standard 2.1 and dll should work as there's compatibility mode:

I guess you'd also have to remove "an error message to the source code for when Odin is compiled as source code in Unity with .NET Standard 2.0 API compatibility level".

 

I might give it a try at some point.
There are more issues on this particular project with domain stuff and probably tons of edge cases, so it's not something I would want to do, if I could avoid.

 

Do you use your own DLL? One with the net framework / standard version mono should actually have System.Memory on board, maybe there is an incompatibility?
I haven't had the time to try it out so far, so it's just a guess.

 

I can reproduce by plain project.
I think this is Unity's bug.
ReadOnlySpan's indexer access only gives an error when netframework is used.

Code (CSharp):

1. ReadOnlySpan<int> foo = new[] { 1, 10, 100 };
2.      
3. // netframework, shows "CS0570: 'ReadOnlySpan<T>.this[int].get' is not supported by the language"
4. Debug.Log(foo[0]);

By the way, net4.8 no support Span.
Does this mean that Unity's netframework is an extension of net4.8?

 

Unity uses mono, and that should support Span. Only the "real" .Net framework 4.8 not support Span out of the box.

 

Now that .NET Standard 2.1 is available, I decided to try a little experiment to see what SDK-style project support could look like in Unity. I did this by creating a NuGet package for UnityEngine and UnityEditor (ideally these would later just contain reference assemblies, rather than the implementation assemblies), and then creating a custom MSBuild SDK.

The result is that a project's csproj can be as simple as:

Code (csproj):

1. <Project Sdk="Unity.NET.Sdk">
2.   <PropertyGroup>
3.     <LangVersion>preview</LangVersion>
4.     <TargetFramework>netstandard2.1</TargetFramework>
5.     <AllowUnsafeBlocks>True</AllowUnsafeBlocks>
6.   </PropertyGroup>
7. </Project>

and for editor code:

Code (csproj):

1. <Project Sdk="Unity.NET.Sdk">
2.   <PropertyGroup>
3.     <LangVersion>preview</LangVersion>
4.     <TargetFramework>netstandard2.1</TargetFramework>
5.     <AllowUnsafeBlocks>True</AllowUnsafeBlocks>
6.     <EditorAssembly>True</EditorAssembly>
7.   </PropertyGroup>
8.  
9.   <ItemGroup>
10.     <ProjectReference Include="..\Runtime\Assembly.CSharp.csproj" Private="False" />
11.   </ItemGroup>
12. </Project>

A nice bonus being that you can make use of NuGet packages.
You can check out the files on my GitHub here. Note that this is only a proof of concept and isn't what I would consider remotely production-ready.

 

Thanks, that clears up the rationale for choosing to name the define NET_STANDARD.

That said, my main concern is that the separate NET_STANDARD_2_0 define is still enabled even under .NET Standard 2.1. This means code intended for earlier versions of Unity that used .NET Standard 2.0 will be mistakenly enabled under .NET Standard 2.1.

As a result, I need to use "#if NET_STANDARD_2_0 && !NET_STANDARD" to make sure I don't hit false positives, which isn't a very intuitive method. NET_STANDARD_2_0 at present behaves more like how NET_STANDARD_2_0_OR_NEWER would, if it existed.

 

Yes, please. Define "NET_STANDARD_2_1" too. In our case we use @xoofx's UnityNuget server to resolve Nuget dependencies.

Right now it defines a NET_STANDARD_2_0 for each *.dll meta file.

https://github.com/xoofx/UnityNuGet/blob/master/src/UnityNuGet/UnityMeta.cs#L41

It would make sense to define a NET_STANDARD_2_1 for netstandard2.1 nuget packages.

EDIT: Here you can see that Microsoft also sets defines for each target framework version:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives

I don't know why you didn't use the same defines. Example NETSTANDARD2_0 (Microsoft) vs NET_STANDARD_2_0 (Unity).

 

To add to my post above about using modern csproj in Unity, I made an interesting discovery that I thought I'd post here in case anyone else is interested in experimenting with this.

It's possible to reference components inside DLLs as if they were regular .cs files in the project, by making use of type forwarders. For example, if I have a DLL in my project that contains a TestComponent class, I can create a TestComponent.cs in my project with the following code:

Code (CSharp):

1. using System.Runtime.CompilerServices;
2. [assembly: TypeForwardedTo(typeof(TestComponent))]

...and then the GUID in the meta file associated with it can be used for the class in the DLL.

This can theoretically be used to automatically migrate a project to the modern csproj system I experimented with above, without losing component references due to them being moved to an external DLL.

Using some trickery, it should also be possible to hook into IDE renaming of classes in the DLL project to automatically update these "stub" .cs files.

 

Just did. Case #1355919
Thanks for looking into it.

Edit: @Baawk reported this before I did (case #1355846).

 

Burst does not work with Span. It still fails to compile.

Code (CSharp):

1. using System;
2. using System.Collections;
3. using System.Collections.Generic;
4. using Unity.Burst;
5. using Unity.Collections;
6. using Unity.Jobs;
7. using UnityEngine;
8.  
9. public class BurstSpan : MonoBehaviour
10. {
11.     [BurstCompile]
12.     private struct SpanJob : IJob
13.     {
14.         public NativeReference<int> result;
15.  
16.         public void Execute()
17.         {
18.             Span<int> list = stackalloc int[10];
19.             result.Value = Sum(list);
20.         }
21.  
22.         private int Sum(Span<int> list)
23.         {
24.             var sum = 0;
25.             for (var i = 0; i < list.Length; i++)
26.             {
27.                 list[i] = i;
28.                 sum += list[i];
29.             }
30.  
31.             return sum;
32.         }
33.     }
34.  
35.     void Start()
36.     {
37.         var result = new NativeReference<int>(Allocator.Temp);
38.         new SpanJob
39.         {
40.             result = result,
41.         }.Execute();
42.         Debug.Log(result.Value);
43.         result.Dispose();
44.     }
45. }
46.  

Code (csharp):

1.  
2. (0,0): Burst error BC1025: Accessing the type `int` (e.g. using `typeof`) is not supported
3.  
4.  at System.Span`1<System.Int32>..ctor(System.Span`1<int>* this, void* pointer, int length)
5.  

If you uncomment [BurstCompile] it works fine.

Bug reported: 1355928

 

When Unity moves to .Net 6 will we be able to make a native executable with crossgen2?

 

Just to automatically be able to build to all .Net supported platforms, like Linux on ARM.

 

I have few cents for crossgen2:
- believe that unity will/can use cross gen for platform that will be supported by scrossgen2 itself.
- use crossgen in place of IL2CPP because the latter dont cover all .net possibilities but the former do
- IL2CPP is slow. only 10-20% faster than mono and 2x slower than native C++ while .Net 5 almost as fast as C++ and in some tests even slightly faster.
- IL2CPP very slow to compile and produce runtime bugs for many generic methods
- IL2CPP generate more than 1000 GB of unreadable cpp sources and than fail to compile it on some platforms (iOS)
- Just want native .Net on platforms that it supports because of stability ease of use perf and full C# support guarantee.

For server builds I actually want to have not IL2CPP but managed .Net App (or Unity native App that will host .net5 ) that can run burst in some places. So server will not just crash because of C++ code inside, but raise exception.

.Net servers just way more stable than C++.
Some time ago Joachim Ante sad that unity will provide DOTS only managed .net Server build target Waiting for it a lot

Dont actually know is it possible at all and dont know how fast crossgen will generate native code but believe that it will be order of magnitude faster than IL2CPP

 

Sometimes 3x slower than mono:

 

I would have to concur with the above info about crossgen2.

.net 6 with crossgen2 would give Unity one unified build path, be way more performant, and less work for you guys to maintain in the long run. It would also give the ability to build all targets on one platform unlike what is possible if for example you were targeting IOS on Windows with IL2CPP.

Hopefully one day we can say goodbye to Mono and IL2CPP. Can't say I will miss them

edit: As for benchmarks the one I can think of this one: https://github.com/nxrighthere/BurstBenchmarks

 

https://github.com/nxrighthere/BurstBenchmarks/blob/master/.NET/Benchmarks.cs

Il2cpp is the winner but I don't like these tests as it's just math and in real scenarios it can be slower than mono.

 

So far i know, crossgen2 is a (not fully) AOT compiler, to reduce the startup time, not the perfomance in general. Is not generate full machine code, but platform spezific bytcode, tho reducte JIT compile time. The generated files are still managed .NET assemblies.
That said, it should actually be possible for unity to use this and thus improve startup times. That would be interesting for servers, for example.

 

Il2cpp improves runtime performance, the docs don’t say anything about startup time (although that 3x slower example was quite sad).
But, ya know… Unity has il2cpp, it doesn’t require any further upkeep from their end, so it will probably stay for the foreseeable future.
Seeing those benchmarks however, I get excited about the future just knowing a .NET 6 build will be more than adequate.

 

Yes, I guess. Whatever is used in NET 6 Preview 6 to run console application.

 

Here's gc allocations test where mono/il2cpp is 10-40x times slower.

Code: https://gist.github.com/kamyker/851696cfed9c2cd725b496e2ef2d1900

Now I understand why .NET developers don't care about gc as much as we do.

 

I'm late to the party, but obviously, Unity doesn't want to be slow. So as there is so much noise in the thread, could I have an onboarding on what Unity's plans are here?

 

First time we see difference in Cpp vs IL2CPP it was on mesh generation for voxel world chunk
We want to throw out Cpp code from project and hope that IL2CPP help but it is not.
Careful port Cpp to C# was 2-3x slower.

Today I have new name to Believe in BURST but dont work in that company so dont have chance to test chunk mesh generator on burst.

On my PC il2cpp still slower in some computations than .net5 but now not match slower in 2020.1.2

There every thing OK our build times about 17 min for 1.3 GB APK and 1GB Generated Cpp Code

Code (CSharp):

1.  
2.  
3.     private SArray<SBuff8<Byte>,Byte> _counters;
4.     _counters[i] = enything
5.  
6.     [Serializable]
7.     public struct SArray<Tb, Tv> where Tv : unmanaged where Tb : ISBuff<Tv>
8.     {
9.         private Tb _buffer;
10.  
11.         public SArray( IEnumerable<Tv> source ) : this()
12.         {
13.             Byte counter = 0;
14.             foreach ( var item in source )
15.             {
16.                 this[counter] = item;
17.                 if ( ++counter >= _buffer.Capacity )
18.                     break;
19.             }
20.         }
21.  
22.         public ref Tv this[Byte index] => ref _buffer.GetElement(index);
23.         public Byte        Length => _buffer.Capacity;
24.  
25.         public SBuffEnumerator<Tv> GetEnumerator() => _buffer.GetEnumerator( _buffer.Capacity );
26.     }
27. [Serializable]
28. [StructLayout(LayoutKind.Sequential)]
29. public unsafe struct SBuff8<T> : ISBuff<T> where T : unmanaged
30. {
31.    public const Byte Length = 8;
32.  
33.    private T m_Element0;
34.    private T m_Element1;
35.    private T m_Element2;
36.    private T m_Element3;
37.    private T m_Element4;
38.    private T m_Element5;
39.    private T m_Element6;
40.    private T m_Element7;
41.  
42.    public Byte Capacity =>  Length;
43.  
44.    public ref T  GetElement ( Byte index )        
45.    {
46.       if( index >= Length )
47.          throw new IndexOutOfRangeException( $"Index out of Range [0;{Length}) - {index}" );
48.  
49.       fixed (T* elements = &m_Element0)
50.       {
51.          return ref elements[index];
52.       }
53.    }
54.    public void   SetElement ( Byte index, T value )      
55.    {
56.       if( index >= Length )
57.          throw new IndexOutOfRangeException( $"Index out of Range [0;{Length}) - {index}" );
58.  
59.       fixed (T* elements = &m_Element0)
60.       {
61.          elements[index] = value;
62.       }
63.    }
64.  
65.    public SBuffEnumerator<T> GetEnumerator( Byte length ) => new SBuffEnumerator<T>( (T*)Unsafe.AsPointer( ref m_Element0 ), Math.Min(length, Length) );
66. }
67.  
68.  

This code in some cases ignore write to buffer. Dont remember exact case. We remove these classes from our code base.

https://forum.unity.com/threads/xcode-can-not-build-unitywebrequest-o.1096375/#post-7059715

 

Does this new unity version support http/2 in the HttpClient?
HttpVersion.Version20 exists now but when I use it to make a request it appears to simply make a http1.1 request anyway.

 

I don't think that's true. I've tried using Newtonsoft.Json compiled for .NET Framework 4.5 in .NET 6 console project. I had an error that System.Security.Permissions is missing but after adding it everything worked fine. I even added old 4.7 version for NET Framework instead NET 6. Nuget was really helpful to download all dependencies:

• 

All 4.X dlls are for NET Framework, I guess they all work until something is missing in NET 6.

That mscorlib.dll 4.0 is from C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.0-preview.6.21352.12 so there's some kind of compatibility mode.

#Edit
Found more info in: https://docs.microsoft.com/en-us/dotnet/core/porting/

 

I expertimenteet with that test. With an NET 5 console app, a have constantly usage of 17MB RAM. With Unity (2021.2b6) after few seconds 14 GB and then, my PC get out of RAM and Unity freezes.
The bad times probably result from the fact that Unity has to move the memory to the HDD/SDD.

 

.Net optimizes out all but one new ClassTest(); in the class loop

 

True, thanks. Changed and rerun net and corert, now 40 times faster instead of 200.

 

Maybe try one instead of all of them. For me Unity takes 40mb with classes test but there could be memory leak on your machine.

 

Trying to cast an IntPtr/void* into a C#9 function pointer (without any unmanaged constraints so one that doesn't require runtime support) results in IL2CPP erroring out with:

error C2440: "=": cannot convert from "void *" to "intptr_t"
note: There is no context in which this conversion is possible

Reported, case number 1356723.

 

Got a reply saying that it's fixed in b7.