Unity's Mono problem: C# code runs slower than it should(marekfiser.com)
marekfiser.com
Unity's Mono problem: C# code runs slower than it should
https://marekfiser.com/blog/mono-vs-dot-net-in-unity/
189 comments
I think you've unfortunately got suckered in by Unity marketing wholesale, and things would stand to be cleared up a bit.
Unity's whole shtick is that they make something horrible, then improve upon it marginally. The ground reality is that these performance enhancement schemes still fall very much short of just doing the basic sensible thing - using CoreCLR for most code, and writing C++ for the truly perf critical parts.
IL2Cpp is a horror-kludge of generated code, that generates low-quality C++ code from .NET IL, relying on the opitmizing compiler to extract decent performance out of it.
You can check it out: https://unity.com/blog/engine-platform/il2cpp-internals-a-to...
The resulting code gives up every possible convenience of C# (compile speed, convenience, debuggability), while falling well short of even modern .NET on performance.
The Burst compiler/HPC# plays on every meme perpetuated by modern gamedev culture (structure-of-arrays, ECS), but performance wise, generally still falls short of competently, but naively written C++ or even sometimes .NET C#. (Though tbf, most naive CoreCLR C# code is like 70-80% the speed of hyper-optimized Burst)
These technologies needless to say, are entirely proprietary, and require you to architect your code entirely their paradigms, use proprietary non-free libraries that make it unusable outside unity, and other nasty side effects.
This whole snakeoil salesmanship is enabled by these cooked Unity benchmarks that always compare performance to the (very slow) baseline Mono, not modern C# or C++ compilers.
These are well-established facts, benchmarked time and time again, but Unity marketing somehow still manages to spread the narrative of their special sauce compilers somehow being technically superior.
But it seems the truth has been catching up to them, and even they realized they have to embrace CoreCLR - which is coming soonTM in Unity. I think it's going to be a fun conversation when people realize that their regular Unity code using CoreCLR runs just as fast or faster than the kludgey stuff they spent 3 times as much time writing, that Unity has been pushing for more than a decade as the future of the engine.
Unity's whole shtick is that they make something horrible, then improve upon it marginally. The ground reality is that these performance enhancement schemes still fall very much short of just doing the basic sensible thing - using CoreCLR for most code, and writing C++ for the truly perf critical parts.
IL2Cpp is a horror-kludge of generated code, that generates low-quality C++ code from .NET IL, relying on the opitmizing compiler to extract decent performance out of it.
You can check it out: https://unity.com/blog/engine-platform/il2cpp-internals-a-to...
The resulting code gives up every possible convenience of C# (compile speed, convenience, debuggability), while falling well short of even modern .NET on performance.
The Burst compiler/HPC# plays on every meme perpetuated by modern gamedev culture (structure-of-arrays, ECS), but performance wise, generally still falls short of competently, but naively written C++ or even sometimes .NET C#. (Though tbf, most naive CoreCLR C# code is like 70-80% the speed of hyper-optimized Burst)
These technologies needless to say, are entirely proprietary, and require you to architect your code entirely their paradigms, use proprietary non-free libraries that make it unusable outside unity, and other nasty side effects.
This whole snakeoil salesmanship is enabled by these cooked Unity benchmarks that always compare performance to the (very slow) baseline Mono, not modern C# or C++ compilers.
These are well-established facts, benchmarked time and time again, but Unity marketing somehow still manages to spread the narrative of their special sauce compilers somehow being technically superior.
But it seems the truth has been catching up to them, and even they realized they have to embrace CoreCLR - which is coming soonTM in Unity. I think it's going to be a fun conversation when people realize that their regular Unity code using CoreCLR runs just as fast or faster than the kludgey stuff they spent 3 times as much time writing, that Unity has been pushing for more than a decade as the future of the engine.
The biggest issue is that Unity is at the same time, the farol beacon for doing game develpment in C#, that Microsoft refuses to support, see how much effort Apple puts on game kits for Swift, versus DirectX team.
Efforts like Managed DirectX and XNA were driven by highly motivated individuals, and were quickly killed as soon as those individuals changed role.
One could blame them for leaving the project, or see that without them managemenent did not care enough to keep them going.
While at the same time, since Unity relies on such alternative approaches, it also creates a false perception on how good .NET and C# are in reality, for those devs that never learned C# outside Unity.
In a similar way it is like those devs that have learnt Java in Android, and get sold on the Kotlin vs Java marketing from Google, by taking Android Java as their perception of what it is all about.
Going back to game development and .NET, at least Capcom has the resources to have their own fork of modern .NET, e.g. Devil May Cry for the Playstation was done with it.
"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"
https://www.youtube.com/watch?v=tDUY90yIC7U
Efforts like Managed DirectX and XNA were driven by highly motivated individuals, and were quickly killed as soon as those individuals changed role.
One could blame them for leaving the project, or see that without them managemenent did not care enough to keep them going.
While at the same time, since Unity relies on such alternative approaches, it also creates a false perception on how good .NET and C# are in reality, for those devs that never learned C# outside Unity.
In a similar way it is like those devs that have learnt Java in Android, and get sold on the Kotlin vs Java marketing from Google, by taking Android Java as their perception of what it is all about.
Going back to game development and .NET, at least Capcom has the resources to have their own fork of modern .NET, e.g. Devil May Cry for the Playstation was done with it.
"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"
https://www.youtube.com/watch?v=tDUY90yIC7U
Very interesting talk, will definitely watch when I have the time!
XNA was very influential for me as well - when I was in high school, I tried to get into 3D game dev, and I started with Frank. D Luna's otherwise excellent book on DirectX gamedev - man that thing was a tome. However, having to learn DirectX, C++, linear algebra, shaders, WIN32 API, COM etc. at the same time (which to be fair were explained very thoroughly by the book), was just too much for me back then, not to mention the absolute pain of trying to get models and assets in the game.
Later on I discovered XNA, and it was a breath of fresh air for me - a much easier language, good IDE support and a decent way of importing assets, and an much nicer API made it so much easier to get started.
And the truly great thing about it was that it didn't dumb things down or hide stuff from the developer - it merely provided sane defaults, and utility functions so that you didn't have to engage with all that complexity at once.
I think Unity was also great as well, at least in the beginning (the first decade of existence), but it's chief issue is that Unity's 'dialect' of C# was very different from how you programmed in regular C# (or mostly any other engine) - my feeling is that Unity should've spun their own language/runtime rather than trying to make C# into what it wasn't designed to be.
XNA was very influential for me as well - when I was in high school, I tried to get into 3D game dev, and I started with Frank. D Luna's otherwise excellent book on DirectX gamedev - man that thing was a tome. However, having to learn DirectX, C++, linear algebra, shaders, WIN32 API, COM etc. at the same time (which to be fair were explained very thoroughly by the book), was just too much for me back then, not to mention the absolute pain of trying to get models and assets in the game.
Later on I discovered XNA, and it was a breath of fresh air for me - a much easier language, good IDE support and a decent way of importing assets, and an much nicer API made it so much easier to get started.
And the truly great thing about it was that it didn't dumb things down or hide stuff from the developer - it merely provided sane defaults, and utility functions so that you didn't have to engage with all that complexity at once.
I think Unity was also great as well, at least in the beginning (the first decade of existence), but it's chief issue is that Unity's 'dialect' of C# was very different from how you programmed in regular C# (or mostly any other engine) - my feeling is that Unity should've spun their own language/runtime rather than trying to make C# into what it wasn't designed to be.
> Unity should've spun their own language/runtime
They did, and that's why their C# API is such an oddball. Unity used to support 3 .NET languages: UnityScript, Boo, and C#. UnityScript started as the recommended one, but I believe it was just a JS-like syntax for Boo's semantics. Eventually C# users dominated, and UnityScript and Boo got deprecated and removed, but Unity's .NET API was left with all the quirks from their UnityScript era.
They did, and that's why their C# API is such an oddball. Unity used to support 3 .NET languages: UnityScript, Boo, and C#. UnityScript started as the recommended one, but I believe it was just a JS-like syntax for Boo's semantics. Eventually C# users dominated, and UnityScript and Boo got deprecated and removed, but Unity's .NET API was left with all the quirks from their UnityScript era.
They did, hence Boo
https://en.wikipedia.org/wiki/Boo_(programming_language)
I would argue that C# has always been a good alternative for games, starting with Arena Wars, the problem was Microsoft not being serious about AOT or low level programming, because that was left for C++/CLI.
https://en.wikipedia.org/wiki/Arena_Wars
Here is the person responsible for pushing XNA, even though management wasn't into it.
"The billion dollar decision that launched XNA"
https://youtu.be/wJY8RhPHmUQ?si=_3pic4pEiOlqQzvm
When she left Microsoft, XNA was promptly replaced by DirectXTK, because C++ is the only true way for DirectX team,
https://walbourn.github.io/directxtk/
https://en.wikipedia.org/wiki/Boo_(programming_language)
I would argue that C# has always been a good alternative for games, starting with Arena Wars, the problem was Microsoft not being serious about AOT or low level programming, because that was left for C++/CLI.
https://en.wikipedia.org/wiki/Arena_Wars
Here is the person responsible for pushing XNA, even though management wasn't into it.
"The billion dollar decision that launched XNA"
https://youtu.be/wJY8RhPHmUQ?si=_3pic4pEiOlqQzvm
When she left Microsoft, XNA was promptly replaced by DirectXTK, because C++ is the only true way for DirectX team,
https://walbourn.github.io/directxtk/
Capcom doing their own env is still a bit extreme sounding to me in it's own right (with the shitpost comment of, I bet they have a slick dispatcher involved somewhere vs 'trust the threadpool')
But then I remember they have to deal with IL2CPP, because lots of mobile/console platforms do not allow JIT as policy.
.NET does now have 'full AOT' as a thing at least, and Streets of Rage 4 I believe used CoreRT for at least a one of the platforms it was released for.
What's more hopeful about that, is that you can see backers of many different architectures contributing towards the ecosystem.
But then I remember they have to deal with IL2CPP, because lots of mobile/console platforms do not allow JIT as policy.
.NET does now have 'full AOT' as a thing at least, and Streets of Rage 4 I believe used CoreRT for at least a one of the platforms it was released for.
What's more hopeful about that, is that you can see backers of many different architectures contributing towards the ecosystem.
This part of your comment is wrong on many levels:
"The Burst compiler/HPC# plays on every meme perpetuated by modern gamedev culture (structure-of-arrays, ECS), but performance wise, generally still falls short of competently, but naively written C++ or even sometimes .NET C#. (Though tbf, most naive CoreCLR C# code is like 70-80% the speed of hyper-optimized Burst)".
C++ code is much faster than C#, but modern C# has become a lot better with all the time that's been invested into it. But you can't just take a random bit of C code and think that it's going to be better than an optimized bit of C#, those days are long past.
Secondly, the whole point of Burst is that it enables vectorization, which means that if you've converted code to it and it's used properly that its going to support instructions up to 256 wide (from what I remember it doesn't use AVX512). That means that it's going to be significantly faster than standard C# (and C).
If the author is generating for example maps and it takes 80 seconds with Mono, then getting to between 10-30 seconds with Burst is easy to achieve just due to its thread usage. Once you then add in focused optimizations that make use of vectorization you can get that down to probably 4 odd seconds (the actual numbers really depend on what you're doing, if its a numerical calculation you can easily get to 80x improvement, but if there's a lot of logic being applied then you'll be stuck at e.g. 8x.
For the last point, new modern C# can't just magically apply vectorization everywhere, because developers intersperse far too much logic. It has a lot of libraries etc. that have become a lot more performant, but again you can't compare that directly to Burst. To compare to Burst you have to do a comparison with Numerics, etc.
C++ code is much faster than C#, but modern C# has become a lot better with all the time that's been invested into it. But you can't just take a random bit of C code and think that it's going to be better than an optimized bit of C#, those days are long past.
Secondly, the whole point of Burst is that it enables vectorization, which means that if you've converted code to it and it's used properly that its going to support instructions up to 256 wide (from what I remember it doesn't use AVX512). That means that it's going to be significantly faster than standard C# (and C).
If the author is generating for example maps and it takes 80 seconds with Mono, then getting to between 10-30 seconds with Burst is easy to achieve just due to its thread usage. Once you then add in focused optimizations that make use of vectorization you can get that down to probably 4 odd seconds (the actual numbers really depend on what you're doing, if its a numerical calculation you can easily get to 80x improvement, but if there's a lot of logic being applied then you'll be stuck at e.g. 8x.
For the last point, new modern C# can't just magically apply vectorization everywhere, because developers intersperse far too much logic. It has a lot of libraries etc. that have become a lot more performant, but again you can't compare that directly to Burst. To compare to Burst you have to do a comparison with Numerics, etc.
While I get that you’re making a stylized comment, it’s a big drag. It’s one of those, “everyone is an idiot except me” styles. By all means, make a game engine that people will adopt based on CoreCLR (or whatever).
It’s not saying much that everything has tradeoffs. During the “decade” you are talking about, CoreCLR didn’t have a solution for writing anything for iOS, and today, it isn’t a solution for writing games for iOS. What you are calling kludges was ultimately a very creative solution. Usually the “right” solution, the nonexistent one that you are advocating with, ends with Apple saying no.
That is why Unity is a valuable piece of software and a big company: not because of C# runtimes, but because they get Apple and Nintendo to say yes in a world where they usually say no.
It’s not saying much that everything has tradeoffs. During the “decade” you are talking about, CoreCLR didn’t have a solution for writing anything for iOS, and today, it isn’t a solution for writing games for iOS. What you are calling kludges was ultimately a very creative solution. Usually the “right” solution, the nonexistent one that you are advocating with, ends with Apple saying no.
That is why Unity is a valuable piece of software and a big company: not because of C# runtimes, but because they get Apple and Nintendo to say yes in a world where they usually say no.
I am sorry that I came across as abrasive, however the points I raised, are as far as I know, factual (and echoed by others' comments). I don't think ignoring them would be constructive.
During the 'decade' where CoreCLR was not a solution, Mono (Xamarin) still was - in fact their entire commercial appeal (before they were bought out by Microsoft) was that they provided an AOT compiled .NET for mobile devices.
Unity got stuck on an ancient version compared to the more modern Mono implementations (I think this is the case to this day), and Unity's version was much, much slower.
Afair, most of the time, the MS version had them (Xamarin) beat, but the difference wasn't huge, between the two, especially compared to Unity's mono. It was an AOT runtime, not sure about Nintendo, but their entire business model hinged on being able to ship to Apple's app store.
I hate to dig up the past, but Unity's long-standing issue was their ancient GC (which was not incremental then), combined with a simple compiler bug, that made every foreach loop allocate an iterator on the heap. The combination of the two meant that basically every non-trial Unity game that used foreach extensively, stuttered. This simple compiler fix took them years to upstream, with people hacking around the issue by replacing the shipped compiler with a patched one.
And I still stand by my point - if Unity went with an upstream Mono, and made it convenient and easy to link with C++ code, it'd have had the same or better performance out of the box as they had with their exotic stuff.
And I also back up the fact that Unity's marketing was deceptive - HPC#/Burst/DOTS/ECS was marketed as some gateway to previously unheard of performance, but when some people went around benchmarking it, basic sensible C++ had it beat (I can't find the benchmarks rn, but multithreaded DOTS was slower than single threaded c++ in a simulation).
What I said about Burst holds up as well.
These are not tradeoffs, but bad technical deicisions, whose legitimacy can be only defended when you ignore the most sensible alternatives.
During the 'decade' where CoreCLR was not a solution, Mono (Xamarin) still was - in fact their entire commercial appeal (before they were bought out by Microsoft) was that they provided an AOT compiled .NET for mobile devices.
Unity got stuck on an ancient version compared to the more modern Mono implementations (I think this is the case to this day), and Unity's version was much, much slower.
Afair, most of the time, the MS version had them (Xamarin) beat, but the difference wasn't huge, between the two, especially compared to Unity's mono. It was an AOT runtime, not sure about Nintendo, but their entire business model hinged on being able to ship to Apple's app store.
I hate to dig up the past, but Unity's long-standing issue was their ancient GC (which was not incremental then), combined with a simple compiler bug, that made every foreach loop allocate an iterator on the heap. The combination of the two meant that basically every non-trial Unity game that used foreach extensively, stuttered. This simple compiler fix took them years to upstream, with people hacking around the issue by replacing the shipped compiler with a patched one.
And I still stand by my point - if Unity went with an upstream Mono, and made it convenient and easy to link with C++ code, it'd have had the same or better performance out of the box as they had with their exotic stuff.
And I also back up the fact that Unity's marketing was deceptive - HPC#/Burst/DOTS/ECS was marketed as some gateway to previously unheard of performance, but when some people went around benchmarking it, basic sensible C++ had it beat (I can't find the benchmarks rn, but multithreaded DOTS was slower than single threaded c++ in a simulation).
What I said about Burst holds up as well.
These are not tradeoffs, but bad technical deicisions, whose legitimacy can be only defended when you ignore the most sensible alternatives.
I don't think you are off base FWIW. Unity has long both kinda lagged too hard but also just makes things weird at times.
I think the biggest hurdle a unity contender has to overcome, is how to provide both 'similar enough' primitives as well, as a way to easily consistently handle the graphics/sound pipeline (i.e. simple way to handle different platform bindings) while also making sure all of that infrastructure is AOT friendly.
I think the biggest hurdle a unity contender has to overcome, is how to provide both 'similar enough' primitives as well, as a way to easily consistently handle the graphics/sound pipeline (i.e. simple way to handle different platform bindings) while also making sure all of that infrastructure is AOT friendly.
[deleted]
i suppose you could speculate, why do i feel Unity's marketing isn't deceptive; why do I think it's a pretty well written game engine; and why am i ignoring these points about C# performance? because i'm stupid? i can't really say, because i'll be downvoted haha. a lot of smart, wise successful game developers choose unity...
Author here, thanks for your perspective. Here some thoughts:
> approach of separating the simulation and presentation layers isn't all that uncommon
I agree that some level of separation is is not that uncommon, but games usually depend on things from their respective engine, especially on things like datatypes (e.g. Vector3) or math libraries. The reason I mention that our game is unique in this way is that its non-rendering code does not depend on any Unity types or DLLs. And I think that is quite uncommon, especially for a game made in Unity.
> Most games don't ship on the mono backend, but instead on il2cpp
I think this really depends. If we take absolute numbers, roughly 20% of Unity games on Steam use IL2CPP [1]. Of course many simple games won't be using it so the sample is skewed is we want to measure "how many players play games with IL2CPP tech". But there are still many and higher perf of managed code would certainly have an impact.
We don't use IL2CPP because we use many features that are not compatible with it. For example DLC and mods loading at runtime via DLLs, reflection for custom serialization, things like [FieldOffset] for efficient struct packing and for GPU communication, etc.
Also, having managed code makes the game "hackabe". Some modders use IL injection to be able to hook to places where our APIs don't allow. This is good and bad, but so far this allowed modders to progress faster than we expected so it's a net positive.
> In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC#
Yeah, and I really wish we would not need to do that. Burst and HPC# are messy and add a lot of unnecessary complexity and artificial limitations.
The thing is, if Mono and .NET were both equally "slow", then sure, let's do some HPC# tricks to get high performance, but it is not! Modern .NET is fast, but Unity devs cannot take advantage of it, which is frustrating.
By the way, the final trace with parallel workers was just C#'s workers threads and thread pool.
> Profiling the editor is always a fools errand
Maybe, but we (devs) spend 99% of our time in the editor. And perf gains from editor usually translate to the Release build with very similar percentage gains (I know this is generally not true, but in my experience it is). We have done many significant optimizations before and measurements from the editor were always useful indicator.
What is not very useful is Unity's profiler, especially with "deep profile" enabled. It adds constant cost per method, highly exaggerating cost of small methods. So we have our own tracing system that does not do this.
> I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime
Yes, minimizing allocations is key, but there are many cases where they are hard to avoid. Things like strings processing for UI generates a lot of garbage every frame. And there are APIs that simply don't have an allocation-free options. CoreCLR would allow to further cut down on allocations and have better APIs available.
Just the fact that the current GC is non-moving means that the memory consumption goes up over time due to fragmentation. We have had numerous reports of "memory" leaks where players report that after periodic load/quit-to-menu loops, memory consumption goes up over time.
Even if we got fast CoreCLR C# code execution, these issues would prevail, so improved CG would be the next on the list.
[1] https://steamdb.info/stats/releases/?tech=SDK.UnityIL2CPP
> approach of separating the simulation and presentation layers isn't all that uncommon
I agree that some level of separation is is not that uncommon, but games usually depend on things from their respective engine, especially on things like datatypes (e.g. Vector3) or math libraries. The reason I mention that our game is unique in this way is that its non-rendering code does not depend on any Unity types or DLLs. And I think that is quite uncommon, especially for a game made in Unity.
> Most games don't ship on the mono backend, but instead on il2cpp
I think this really depends. If we take absolute numbers, roughly 20% of Unity games on Steam use IL2CPP [1]. Of course many simple games won't be using it so the sample is skewed is we want to measure "how many players play games with IL2CPP tech". But there are still many and higher perf of managed code would certainly have an impact.
We don't use IL2CPP because we use many features that are not compatible with it. For example DLC and mods loading at runtime via DLLs, reflection for custom serialization, things like [FieldOffset] for efficient struct packing and for GPU communication, etc.
Also, having managed code makes the game "hackabe". Some modders use IL injection to be able to hook to places where our APIs don't allow. This is good and bad, but so far this allowed modders to progress faster than we expected so it's a net positive.
> In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC#
Yeah, and I really wish we would not need to do that. Burst and HPC# are messy and add a lot of unnecessary complexity and artificial limitations.
The thing is, if Mono and .NET were both equally "slow", then sure, let's do some HPC# tricks to get high performance, but it is not! Modern .NET is fast, but Unity devs cannot take advantage of it, which is frustrating.
By the way, the final trace with parallel workers was just C#'s workers threads and thread pool.
> Profiling the editor is always a fools errand
Maybe, but we (devs) spend 99% of our time in the editor. And perf gains from editor usually translate to the Release build with very similar percentage gains (I know this is generally not true, but in my experience it is). We have done many significant optimizations before and measurements from the editor were always useful indicator.
What is not very useful is Unity's profiler, especially with "deep profile" enabled. It adds constant cost per method, highly exaggerating cost of small methods. So we have our own tracing system that does not do this.
> I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime
Yes, minimizing allocations is key, but there are many cases where they are hard to avoid. Things like strings processing for UI generates a lot of garbage every frame. And there are APIs that simply don't have an allocation-free options. CoreCLR would allow to further cut down on allocations and have better APIs available.
Just the fact that the current GC is non-moving means that the memory consumption goes up over time due to fragmentation. We have had numerous reports of "memory" leaks where players report that after periodic load/quit-to-menu loops, memory consumption goes up over time.
Even if we got fast CoreCLR C# code execution, these issues would prevail, so improved CG would be the next on the list.
[1] https://steamdb.info/stats/releases/?tech=SDK.UnityIL2CPP
>We don't use IL2CPP because we use many features that are not compatible with it. For example DLC and mods loading at runtime via DLLs, reflection for custom serialization, things like [FieldOffset] for efficient struct packing and for GPU communication, etc.
FieldOffset is supported by IL2CPP at compile time [0]. You can also install new DLLs and force the player to restart if you want downloadable mod support.
It's true that you can't do reflection for serialization, but there are better, more performant alternatives for that use case, in my experience.
[0] https://docs.unity3d.com/Manual/scripting-restrictions.html
FieldOffset is supported by IL2CPP at compile time [0]. You can also install new DLLs and force the player to restart if you want downloadable mod support.
It's true that you can't do reflection for serialization, but there are better, more performant alternatives for that use case, in my experience.
[0] https://docs.unity3d.com/Manual/scripting-restrictions.html
> You can also install new DLLs and force the player to restart if you want downloadable mod support.
I am not aware of an easy way to load (managed) mods as DLLs to IL2CPP-compiled game. I am thinking about `Assembly.LoadFrom("Mod.dll")`.
Can you elaborate how this is done?
> there are better, more performant alternatives for that use case, in my experience.
We actually use reflection to emit optimal code for generic serializers that avoid boxing and increase performance.
There may be alternatives, we explored things like FlatBuffers and their variants, but nothing came close to our system in terms of ease of use, versioning support, and performance.
If you have some suggestions, I'd be interested to see what options are out there for C#.
> FieldOffset is supported by IL2CPP at compile time
You are right, I miss-remembered this one, you cannot get it via reflection, but it works.
I am not aware of an easy way to load (managed) mods as DLLs to IL2CPP-compiled game. I am thinking about `Assembly.LoadFrom("Mod.dll")`.
Can you elaborate how this is done?
> there are better, more performant alternatives for that use case, in my experience.
We actually use reflection to emit optimal code for generic serializers that avoid boxing and increase performance.
There may be alternatives, we explored things like FlatBuffers and their variants, but nothing came close to our system in terms of ease of use, versioning support, and performance.
If you have some suggestions, I'd be interested to see what options are out there for C#.
> FieldOffset is supported by IL2CPP at compile time
You are right, I miss-remembered this one, you cannot get it via reflection, but it works.
>I am not aware of an easy way to load (managed) mods as DLLs to IL2CPP-compiled game. I am thinking about `Assembly.LoadFrom("Mod.dll")`.
Ah, I was thinking native DLLs (which is what we're using on a project I'm working on). I think you're right that it's impossible for an IL2CPP-built player to interoperate with a managed (Mono) DLL.
>If you have some suggestions [re: serialization], I'd be interested to see what options are out there for C#.
We wrote a custom, garbage-free JSON serializer/deserializer that uses a fluent API style. We also explored a custom codegen solution (similar to FlatBuffers or protobuf) but abandoned it because the expected perf (and ergonomic) benefits would have been minor. The trickiest part with Unity codegen is generating code that creates little to no garbage.
Ah, I was thinking native DLLs (which is what we're using on a project I'm working on). I think you're right that it's impossible for an IL2CPP-built player to interoperate with a managed (Mono) DLL.
>If you have some suggestions [re: serialization], I'd be interested to see what options are out there for C#.
We wrote a custom, garbage-free JSON serializer/deserializer that uses a fluent API style. We also explored a custom codegen solution (similar to FlatBuffers or protobuf) but abandoned it because the expected perf (and ergonomic) benefits would have been minor. The trickiest part with Unity codegen is generating code that creates little to no garbage.
Re serialization: We have custom binary serialization that essentially dumps the game state into a binary stream. No allocations, no copies, no conversions. Our saves can be big, >100 MB uncompressed, so there is no room for waste.
The big advantage is that it reads data directly from game's classes, so there is no boilerplate needed, no prorobufs, no schema. And it supports versioning, adding or removing members mostly without limitations.
I think it's a cool system, maybe I should write a blog post about it :)
The big advantage is that it reads data directly from game's classes, so there is no boilerplate needed, no prorobufs, no schema. And it supports versioning, adding or removing members mostly without limitations.
I think it's a cool system, maybe I should write a blog post about it :)
Does unity have source generators support? Could make for a good alternative to reflection.
Yes and it works well IME. https://docs.unity3d.com/6000.3/Documentation/Manual/roslyn-...
Now I think about it, writing SourceGenerators is actually a great fit for AI agents.
Now I think about it, writing SourceGenerators is actually a great fit for AI agents.
What I agree on is that if we had modern .NET available we'd get a free 2-3x improvement, it would definitely be great. BUT having said that, if you're into performance but unwilling to use the tools available then that's on you.
From the article it seems that you're using some form of threading to create things, but you don't really specify which and/or how.
The default C# implementations are usually quite poor performance wise, so if you used for example the default thread pool I can definitively say that I've achieved a 3x speedup over that by using my own thread pool implementation which would yield about the same 30s -> 12s reduction.
Burst threading/scheduling in general is also a lot better than the standard one, in general if I feed it a logic heavy method (so no vectorization) then I can beat it by a bit, but not close to the 3x of the normal thread pool.
But then if your generation is number heavy (vs logic) then having used Burst you could probably drop that calculation time down to 2-3 seconds (in the same as if you used Vector<256> numerics).
Finally you touch on GC, that's definitely a problem. The Mono variant has been upgraded by them over time, but C# remains C# which was never meant for gaming. Even if we had access to the modern one there would still be issues with it. As with all the other C# libraries etc., they never considered gaming a target where what we want is extremely fast access/latency with no hiccups. C# in the business world doesn't really care if it loses 16ms (or 160ms) here and there due to garbage, it's usually not a problem there.
Coding in Unity means having to go over every instance of allocation outside of startup and eliminating them, you mention API's that still need to allocate which I've never run into myself. Again modern isn't going to simply make those go away.
From the article it seems that you're using some form of threading to create things, but you don't really specify which and/or how.
The default C# implementations are usually quite poor performance wise, so if you used for example the default thread pool I can definitively say that I've achieved a 3x speedup over that by using my own thread pool implementation which would yield about the same 30s -> 12s reduction.
Burst threading/scheduling in general is also a lot better than the standard one, in general if I feed it a logic heavy method (so no vectorization) then I can beat it by a bit, but not close to the 3x of the normal thread pool.
But then if your generation is number heavy (vs logic) then having used Burst you could probably drop that calculation time down to 2-3 seconds (in the same as if you used Vector<256> numerics).
Finally you touch on GC, that's definitely a problem. The Mono variant has been upgraded by them over time, but C# remains C# which was never meant for gaming. Even if we had access to the modern one there would still be issues with it. As with all the other C# libraries etc., they never considered gaming a target where what we want is extremely fast access/latency with no hiccups. C# in the business world doesn't really care if it loses 16ms (or 160ms) here and there due to garbage, it's usually not a problem there.
Coding in Unity means having to go over every instance of allocation outside of startup and eliminating them, you mention API's that still need to allocate which I've never run into myself. Again modern isn't going to simply make those go away.
Sure, we could use Burst to speed up some strategic parts, but that would not help with the core of the game.
To give some context, things are very complex in our game, we have fully dynamic terrain with terrain physics (land-slides), advanced path-finding of hundreds of vehicles (each entity has its own width and height clearance), trains, conveyors and pipes carrying tens or even hundreds of thousands of individual products, machines, rockets, ships, automated logistics, etc. There is no one thing that could be bursted to get 3x gain. At this point, we'd have to rewrite the entire game in C++.
So what's the reason we use C#? Productivity, ease of debugging and testing, and resilience to bugs (e.g. null dereference won't kill the program). Messing with C++ or even burst would cost us more time and to be honest, the game would possibly not even exist at that point.
Could you share some details about your custom thread pool that got 3x speedup? What was the speedup from? It is highly unlikely that a custom thread pool would have any significant impact on the benchmark in our case. As you can see from Figure 3, threaded tasks run for about 25% of the total time and even with Mono, all tasks are reasonably well balanced between threads. Threads utilization is surely over 90% (there is always slight inefficiency towards the end as threads are finishing up, but that's 100's of ms). An "oracle" thread pool could speed tings up by 10% of 25%, so that is not it.
Vectorization could help too but majority of the code is not easily vectorizable. It's all kinds of workloads, loading data, deserialization, initialization of entities, map generation, precomputation of various things. I highly doubt that automatic vectorization from code generated by IL2CPP would bring more than 20% speedup here. The speedup from burst would mostly come from elimination of inefficient code generated by Mono's JIT, not from vectorization.
For now, we are accepting the Mono tax to be more productive. But I am hoping that Unity will deliver on the CoreCLR dream. In the meantime, my post was meant raise awareness and stir up some discussion, like this one, which is great. I've read lots of interesting thoughts in this comments section.
To give some context, things are very complex in our game, we have fully dynamic terrain with terrain physics (land-slides), advanced path-finding of hundreds of vehicles (each entity has its own width and height clearance), trains, conveyors and pipes carrying tens or even hundreds of thousands of individual products, machines, rockets, ships, automated logistics, etc. There is no one thing that could be bursted to get 3x gain. At this point, we'd have to rewrite the entire game in C++.
So what's the reason we use C#? Productivity, ease of debugging and testing, and resilience to bugs (e.g. null dereference won't kill the program). Messing with C++ or even burst would cost us more time and to be honest, the game would possibly not even exist at that point.
Could you share some details about your custom thread pool that got 3x speedup? What was the speedup from? It is highly unlikely that a custom thread pool would have any significant impact on the benchmark in our case. As you can see from Figure 3, threaded tasks run for about 25% of the total time and even with Mono, all tasks are reasonably well balanced between threads. Threads utilization is surely over 90% (there is always slight inefficiency towards the end as threads are finishing up, but that's 100's of ms). An "oracle" thread pool could speed tings up by 10% of 25%, so that is not it.
Vectorization could help too but majority of the code is not easily vectorizable. It's all kinds of workloads, loading data, deserialization, initialization of entities, map generation, precomputation of various things. I highly doubt that automatic vectorization from code generated by IL2CPP would bring more than 20% speedup here. The speedup from burst would mostly come from elimination of inefficient code generated by Mono's JIT, not from vectorization.
For now, we are accepting the Mono tax to be more productive. But I am hoping that Unity will deliver on the CoreCLR dream. In the meantime, my post was meant raise awareness and stir up some discussion, like this one, which is great. I've read lots of interesting thoughts in this comments section.
>Sure, we could use Burst to speed up some strategic parts... the game would possibly not even exist at that point.
Yeah, the thing with Burst is that its a lot easier to work with if you start with it than having to replace/upgrade code later, especially if you're not familiar with it. A big issue is usually that you create structs with data and they're referencing other structs etc., all those need to be untangled to really make use of Burst. I myself am also a big C# fan, it is a lot easier than using C. Unity has a lot of issues but there's a reason its so widely adopted and used. (I myself am currently working on a Unity C# tool that I believe will speed up code development significantly).
Your game does sound as if its a VERY ripe target for Burst usage based on the elements that you describe, but the real question should be if you need it. For example if you're already running at 60 fps on whatever your mid target hardware is at whatever max + N% load/size for a game instance then you don't need it. But if you're only hitting 40fps and design-wise want to increase e.g. your map size by 2x then it might be something to look into. Also if you look at e.g. Factorio, they spend a LOT of time optimizing systems, but of course you first need to launch the game (which is and should be the priority).
If you have for example 25 systems (e.g. pathfinding, trains, pipes, etc.) and they're evenly balanced then as you say then you won't increase your game speed by 2x by just converting one of those. BUT if for example your pipes are being processed in 4ms per frame, so you instead adopt other strategies like only processing them every Nth frame or doing M pipes per frame; at that point using Burst to just get that 4ms down to 0.5ms might be a really worthwhile target to make your game play better. The same goes for all your systems where the upgrade will have a cumulative effect.
I highly suggest learning just the basics of Burst in your spare time and trying it out on something basic to get the feel of it. As with all code/libraries it'll unfortunately take some time to figure out how to effectively use it. Roughly speaking: - You don't have to have SOA data, but it helps. At the start just convert methods over 1 to 1. - You have to convert most C# container types to Burst ones, for example in struct Vehicle { Wheel[] wheels } you need to change Wheel[] over to NativeArray<Wheel>, and the Wheel struct itself also need to not use complex types etc. Other types such as NativeSpan are also very useful, instead of storing the wheels just use a ref Span to them instead. - After you have basics going you can try out SOA along with more math/less logic so that the code can be vectorized, once you see that big speedup for certain types of code it's hard to go back.
>Could you share some details about your custom thread pool that got 3x speedup? What was the speedup from? It is highly unlikely that a custom thread pool would have any significant impact on the benchmark in our case. As you can see from Figure 3, threaded tasks run for about 25% of the total time and even with Mono, all tasks are reasonably well balanced between threads. Threads utilization is surely over 90% (there is always slight inefficiency towards the end as threads are finishing up, but that's 100's of ms). An "oracle" thread pool could speed tings up by 10% of 25%, so that is not it.
My thread pool itself is pretty standard, it spins up some heavy threads and uses ManualResetEvent to trigger them. Its advantage lies in pre-registering simple Action (with/without parameters) calls to set methods that'll be called when the thread runs; and with more gaming related options for whether we're waiting on thread completion, interleaving them with other threads etc. A big plus is that it has a self-optimization function, so it'll self-adjust the thread count vs the total time runs take, the total # of amounts of items being processed for the given workload etc. so as to automatically find very good sizes for all those elements to use for the target computer, vs just assuming e.g. 32, 64 or 128 inner elements and launching the max available threads on the PC (as thread pools usually do).
>Vectorization could help too but majority of the code is not easily vectorizable. It's all kinds of workloads, loading data, deserialization, initialization of entities, map generation, precomputation of various things. I highly doubt that automatic vectorization from code generated by IL2CPP would bring more than 20% speedup here. The speedup from burst would mostly come from elimination of inefficient code generated by Mono's JIT, not from vectorization.
Yeah, if its startup/generating code that's mostly bypassed by loading a game then its not worth switching over. Do note that code compiled by Burst will in general be more optimized than Mono just due to better tooling, but in general its not worth moving over just for that due to the amount of work you need to do so. The real wins come in if some generating element that's done often is taking too long, or during gameplay where you can replace elements in the game that take e.g. N milliseconds to calculate every frame and drop those down to 1/10th - 1/100th of the time it used to take.
Good luck!
Yeah, the thing with Burst is that its a lot easier to work with if you start with it than having to replace/upgrade code later, especially if you're not familiar with it. A big issue is usually that you create structs with data and they're referencing other structs etc., all those need to be untangled to really make use of Burst. I myself am also a big C# fan, it is a lot easier than using C. Unity has a lot of issues but there's a reason its so widely adopted and used. (I myself am currently working on a Unity C# tool that I believe will speed up code development significantly).
Your game does sound as if its a VERY ripe target for Burst usage based on the elements that you describe, but the real question should be if you need it. For example if you're already running at 60 fps on whatever your mid target hardware is at whatever max + N% load/size for a game instance then you don't need it. But if you're only hitting 40fps and design-wise want to increase e.g. your map size by 2x then it might be something to look into. Also if you look at e.g. Factorio, they spend a LOT of time optimizing systems, but of course you first need to launch the game (which is and should be the priority).
If you have for example 25 systems (e.g. pathfinding, trains, pipes, etc.) and they're evenly balanced then as you say then you won't increase your game speed by 2x by just converting one of those. BUT if for example your pipes are being processed in 4ms per frame, so you instead adopt other strategies like only processing them every Nth frame or doing M pipes per frame; at that point using Burst to just get that 4ms down to 0.5ms might be a really worthwhile target to make your game play better. The same goes for all your systems where the upgrade will have a cumulative effect.
I highly suggest learning just the basics of Burst in your spare time and trying it out on something basic to get the feel of it. As with all code/libraries it'll unfortunately take some time to figure out how to effectively use it. Roughly speaking: - You don't have to have SOA data, but it helps. At the start just convert methods over 1 to 1. - You have to convert most C# container types to Burst ones, for example in struct Vehicle { Wheel[] wheels } you need to change Wheel[] over to NativeArray<Wheel>, and the Wheel struct itself also need to not use complex types etc. Other types such as NativeSpan are also very useful, instead of storing the wheels just use a ref Span to them instead. - After you have basics going you can try out SOA along with more math/less logic so that the code can be vectorized, once you see that big speedup for certain types of code it's hard to go back.
>Could you share some details about your custom thread pool that got 3x speedup? What was the speedup from? It is highly unlikely that a custom thread pool would have any significant impact on the benchmark in our case. As you can see from Figure 3, threaded tasks run for about 25% of the total time and even with Mono, all tasks are reasonably well balanced between threads. Threads utilization is surely over 90% (there is always slight inefficiency towards the end as threads are finishing up, but that's 100's of ms). An "oracle" thread pool could speed tings up by 10% of 25%, so that is not it.
My thread pool itself is pretty standard, it spins up some heavy threads and uses ManualResetEvent to trigger them. Its advantage lies in pre-registering simple Action (with/without parameters) calls to set methods that'll be called when the thread runs; and with more gaming related options for whether we're waiting on thread completion, interleaving them with other threads etc. A big plus is that it has a self-optimization function, so it'll self-adjust the thread count vs the total time runs take, the total # of amounts of items being processed for the given workload etc. so as to automatically find very good sizes for all those elements to use for the target computer, vs just assuming e.g. 32, 64 or 128 inner elements and launching the max available threads on the PC (as thread pools usually do).
>Vectorization could help too but majority of the code is not easily vectorizable. It's all kinds of workloads, loading data, deserialization, initialization of entities, map generation, precomputation of various things. I highly doubt that automatic vectorization from code generated by IL2CPP would bring more than 20% speedup here. The speedup from burst would mostly come from elimination of inefficient code generated by Mono's JIT, not from vectorization.
Yeah, if its startup/generating code that's mostly bypassed by loading a game then its not worth switching over. Do note that code compiled by Burst will in general be more optimized than Mono just due to better tooling, but in general its not worth moving over just for that due to the amount of work you need to do so. The real wins come in if some generating element that's done often is taking too long, or during gameplay where you can replace elements in the game that take e.g. N milliseconds to calculate every frame and drop those down to 1/10th - 1/100th of the time it used to take.
Good luck!
Regarding GC pauses, there is an interesting alternative GC with ultra low pauses for .NET called Satori. It's primarly discussed here
https://github.com/dotnet/runtime/discussions/115627, and the GC itself can be found here https://github.com/VSadov/Satori
Hey there, always appreciate a dialog
Per the separation, I think this was far more common both in older unity games, and also professional settings.
For games shipping on mono on steam, that statistic isn't surprising to me given the amount of indie games on there and Unity's prevalence in that environment. My post in general can be read in a professional setting (ie, career game devs). The IL injection is a totally reasonable consideration, but does (currently) lock you out of platforms where AoT is a requirement. You can also support mods/DLC via addressables, and there has been improvement of modding tools for il2cpp, however you're correct it's not nearly as easy.
Going to completely disagree that Burst and HPC# are unnecessary and messy. This is for a few reasons. The restrictions that HPC# enforce essentially are the same you already have if you want to write performant C# code as you just simply use Unity's allocators for your memory up front and then operate on those. Depending on how you do this, you either can eliminate your per frame allocations, or likely eliminate some of the fragmentation you were referring to. Modern .Net is fast, of course, but it's not burst compiled HPC# fast. There are so many things that the compiler and LLVM can do based on those assumptions. Agreed C# strings are always a pain if you actually need to interpolate things at runtime. We always try to avoid these as much as we can, and intern common ones.
The fragmentation you mention on after large operations is (in my experience) indicative of save/load systems, or possibly level init code that do tons of allocations causing that to froth up. That or tons of reflection stuff, which is also usually nono for runtime perf code. The memory profiler used to have a helpful fragmentation view for that, but Unity removed it unfortunately.
Per the separation, I think this was far more common both in older unity games, and also professional settings.
For games shipping on mono on steam, that statistic isn't surprising to me given the amount of indie games on there and Unity's prevalence in that environment. My post in general can be read in a professional setting (ie, career game devs). The IL injection is a totally reasonable consideration, but does (currently) lock you out of platforms where AoT is a requirement. You can also support mods/DLC via addressables, and there has been improvement of modding tools for il2cpp, however you're correct it's not nearly as easy.
Going to completely disagree that Burst and HPC# are unnecessary and messy. This is for a few reasons. The restrictions that HPC# enforce essentially are the same you already have if you want to write performant C# code as you just simply use Unity's allocators for your memory up front and then operate on those. Depending on how you do this, you either can eliminate your per frame allocations, or likely eliminate some of the fragmentation you were referring to. Modern .Net is fast, of course, but it's not burst compiled HPC# fast. There are so many things that the compiler and LLVM can do based on those assumptions. Agreed C# strings are always a pain if you actually need to interpolate things at runtime. We always try to avoid these as much as we can, and intern common ones.
The fragmentation you mention on after large operations is (in my experience) indicative of save/load systems, or possibly level init code that do tons of allocations causing that to froth up. That or tons of reflection stuff, which is also usually nono for runtime perf code. The memory profiler used to have a helpful fragmentation view for that, but Unity removed it unfortunately.
> Modern .Net is fast, of course, but it's not burst compiled HPC# fast.
Sure, but the fact that it is competitive with Burst makes it disappointing. If I'm going to go through the trouble of writing code in a different (and not portable!) way then it better be significantly faster. Especially when most code cannot be written as Burst jobs unless you use their (new) ECS.
https://github.com/tbg10101/dotnet-burst-comparison
Sure, but the fact that it is competitive with Burst makes it disappointing. If I'm going to go through the trouble of writing code in a different (and not portable!) way then it better be significantly faster. Especially when most code cannot be written as Burst jobs unless you use their (new) ECS.
https://github.com/tbg10101/dotnet-burst-comparison
I wonder what those benchmarks would look like with .NET 10 and an AVX512-capable CPU.
Yeah to me, Burst+Jobs and Compute shaders are so easy to work with in Unity, I haven't felt the need to squeeze more perf out of C# in a long time.
For modding and OTA stuff I just use a scripting language with good interop (I made OneJS partially for this purpose). No more AOT issue and no more waiting for domain reload, etc.
For modding and OTA stuff I just use a scripting language with good interop (I made OneJS partially for this purpose). No more AOT issue and no more waiting for domain reload, etc.
> Going to completely disagree that Burst and HPC# are unnecessary and messy.
Making a managed code burst-compatible comes with real constraints that go beyond "write performant C#". In Burstable code, you generally can't interact with managed objects/GC-dependent APIs, so the design is pushed towards unmanaged structs in native collections. And this design spreads. The more logic is to be covered by Burst, the more things has to be broken down to native containers of unmanaged structs.
I agree that designing things in data-oriented way is good, but why to force this additional boundary and special types on devs instead of just letting them write it in C#? Writing burstable code can increase complexity, one has to manage memory/lifetimes, data layout, and job-friendly boundaries, copying data between native and managed collections, etc., not just "writing fast C#".
In a complex simulation game, my experience is that there are definitely things that fit the "raw data, batch processing" model, but not all gameplay/simulation logic does. Things like inheritance, events, graphs, AI (the dumb "game" version, no NN), UI, exceptions, etc. And on top of it all, debugging complications.
Wouldn't you be relieved with announcement: "C# is now as fast as Burst, have fun!"? You'd be able to do the same data-oriented design where necessary, but keep all the other tings handy standing by when needed. It's so close, yet, so far!
> The fragmentation you mention
What you say makes sense. I've actually spent a lot of time debugging this and I did find some "leaks" where references to "dead objects" were keeping them from being GC'd. But after sorting all these out, Unity's memory profiler was showing that "Empty Heap Space" was the culprit, that one kept increasing after every iteration. My running theory is that the heap is just more and more fragmented, and some static objects randomly scattered around it are keeping it from being shrunk. ¯\_(ツ)_/¯
Making a managed code burst-compatible comes with real constraints that go beyond "write performant C#". In Burstable code, you generally can't interact with managed objects/GC-dependent APIs, so the design is pushed towards unmanaged structs in native collections. And this design spreads. The more logic is to be covered by Burst, the more things has to be broken down to native containers of unmanaged structs.
I agree that designing things in data-oriented way is good, but why to force this additional boundary and special types on devs instead of just letting them write it in C#? Writing burstable code can increase complexity, one has to manage memory/lifetimes, data layout, and job-friendly boundaries, copying data between native and managed collections, etc., not just "writing fast C#".
In a complex simulation game, my experience is that there are definitely things that fit the "raw data, batch processing" model, but not all gameplay/simulation logic does. Things like inheritance, events, graphs, AI (the dumb "game" version, no NN), UI, exceptions, etc. And on top of it all, debugging complications.
Wouldn't you be relieved with announcement: "C# is now as fast as Burst, have fun!"? You'd be able to do the same data-oriented design where necessary, but keep all the other tings handy standing by when needed. It's so close, yet, so far!
> The fragmentation you mention
What you say makes sense. I've actually spent a lot of time debugging this and I did find some "leaks" where references to "dead objects" were keeping them from being GC'd. But after sorting all these out, Unity's memory profiler was showing that "Empty Heap Space" was the culprit, that one kept increasing after every iteration. My running theory is that the heap is just more and more fragmented, and some static objects randomly scattered around it are keeping it from being shrunk. ¯\_(ツ)_/¯
Unity has a unity problem.
While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt).
The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications.
There is the problem. The scripting ending designed around mono doesn’t translate as well to CoreCLR and using the same Behavior interface gets a little more complicated.
There are times (even with my own engine) that one must let go of the old and begin a new. Dx7->dx9, dx9->opengl, opengl->vulkan, vulkan->webgpu.
EDIT I was just thinking, returning to this a couple of minute later, that if Unity wanted to prove they really care about their Core, they would introduce a complete revamp of the editor like Blender did for 3.X. Give more thought to the level editors and prefab makers. Give different workflow views. Editing / Animation / Scripting / Rendering / Post
As it stands now, it’s all just a menu item that spawns a thing in a single view with a 1999 style property window on the side like Visual Studio was ever cool.
While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt).
The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications.
There is the problem. The scripting ending designed around mono doesn’t translate as well to CoreCLR and using the same Behavior interface gets a little more complicated.
There are times (even with my own engine) that one must let go of the old and begin a new. Dx7->dx9, dx9->opengl, opengl->vulkan, vulkan->webgpu.
EDIT I was just thinking, returning to this a couple of minute later, that if Unity wanted to prove they really care about their Core, they would introduce a complete revamp of the editor like Blender did for 3.X. Give more thought to the level editors and prefab makers. Give different workflow views. Editing / Animation / Scripting / Rendering / Post
As it stands now, it’s all just a menu item that spawns a thing in a single view with a 1999 style property window on the side like Visual Studio was ever cool.
I think the major problem with Unity is they're just rudderless. They just continue to buy plugins and slap in random features but it's really just in service of more stickers on the box and not a wholistic plan.
They've tried and failed to make their own games and they just can't do it. That means they don't have the internal drive to push a new design forward. They don't know what it takes to make a game. They just listen to what people ask for in a vacuum and ship that.
A lot of talented people at Unity but I don't expect a big change any time soon.
They've tried and failed to make their own games and they just can't do it. That means they don't have the internal drive to push a new design forward. They don't know what it takes to make a game. They just listen to what people ask for in a vacuum and ship that.
A lot of talented people at Unity but I don't expect a big change any time soon.
The talent left ship years ago. The core engine’s graphics team is all that’s really left.
They also hired Jim Whitehurst as CEO after the previous CEO crapped the bed. Then Jim left as he just didn’t understand the business (he’s probably the one responsible for the “just grab it from the store” attitude). Now they have this stinking pile of legacy they can’t get rid of.
They also hired Jim Whitehurst as CEO after the previous CEO crapped the bed. Then Jim left as he just didn’t understand the business (he’s probably the one responsible for the “just grab it from the store” attitude). Now they have this stinking pile of legacy they can’t get rid of.
Has the talent moved to anywhere in particular?
Nicholas Francis manages a fund for AgTech after a decade making games with Unity (the engine he made). He left in 2013 so I don't associate him with Unity today but it was his product.
2018 We get the new HDRP and Shader Graph.
2019 there were sexual harassment lawsuits.
The other co-founders left after they announced runtime fees in 2023 and the community fled.
2024 the URP team basically imploded. Leaving everything basically flat.
2018 We get the new HDRP and Shader Graph.
2019 there were sexual harassment lawsuits.
The other co-founders left after they announced runtime fees in 2023 and the community fled.
2024 the URP team basically imploded. Leaving everything basically flat.
I've seen it happening time and time again in similar companies, and this is a symptom of a problem at the upper levels, which means it won't change.
C-level set goals are abstract and generic, or sometimes plain naive, and this is often coming from generic requests from the board or VCs.
"Hire as many developers as you can, even if there's no work right now", a Softbank request.
"Don't build, just acquire similar products", from a Brazilian capital management that ended up killing that company.
"Kill this team, their product doesn't sell. I don't care if all our other product depends on theirs", from Francisco Partners.
Employees who stay can't really rock the boat, so it self-selects for non-boat-rocking people. Rockstars who stay must adapt or suffer. Eventually you get so many bad people that you do layoffs.
C-level set goals are abstract and generic, or sometimes plain naive, and this is often coming from generic requests from the board or VCs.
"Hire as many developers as you can, even if there's no work right now", a Softbank request.
"Don't build, just acquire similar products", from a Brazilian capital management that ended up killing that company.
"Kill this team, their product doesn't sell. I don't care if all our other product depends on theirs", from Francisco Partners.
Employees who stay can't really rock the boat, so it self-selects for non-boat-rocking people. Rockstars who stay must adapt or suffer. Eventually you get so many bad people that you do layoffs.
The thread in all of them is that the CEO listened to other people’s advice instead of leading themselves. When a ship loses its captain…
That's a good point.
If the CEO is just a parrot repeating what the board says, you get a company full of parrots too. No pirate to guide the ship.
If the CEO is just a parrot repeating what the board says, you get a company full of parrots too. No pirate to guide the ship.
The best CEOs I’ve seen balance board requests with what they themselves want to do and where they see their market going. Standing on the shoreline when the armada of prospects come sailing in for provisions.
When there’s a gold rush, sell pickaxes and shovels.
When there’s a gold rush, sell pickaxes and shovels.
The biggest problem IMO is that they never finish new features. They start the work on implementing new tech/assets/plugins, then abandon them halfway through just as they are becoming useful for prod. There are tons of would-be-amazing tools but they are all stuck at "0.x-preview" versions, and eventually after 5-10 years either stop working completely or are over-shadowed by newer, shinier assets, which often re-invent the wheel and/or do things worse than the previous attempt. I stopped trying out new tech until its 1.0 (or preferably later, 2.0+ is safer) because I'm afraid to be bitten (again) becoming dependent on abandoned plugins and have to at some point update to something else. It's a lose-lose-lose proposition: Unity throws away time and money re-inventing plugins, we throw away time and money having to port to functioning tools, customers lose time because they get to discover bugs caused by outdated plugins/assets that cause weird errors that are hard to track down.
I think what you're describing is a symptom of the issue. The issue is talent churn. Bright folks who start a feature get poached and leave and the feature dies on the vine. Or that the feature, which started off great in it's own little corner of the engine, was a mess to integrate with the rest of Unity due to it's architecture and the fear of breaking backward compatibility.
The problem now comes not from tech-previews but from the quarterly forced releases because it's now a subscription. The entire business model is flawed and outdated. Same with Unreal. The difference is Unreal tech is exponentially better than Unity architecturally and they know their audience very well so they were able to get in with virtual stage production, games, movies, you name it. They were successful in expanding beyond their core. Unity, can't. They don't know how.
It's a tough spot to be in. I knew my place when I shut mine down and open sourced it. I couldn't compete. For Unity, they have a loyal fanbase that wants them to succeed but I'm afraid it's going to take breaking everything they know in order to do it.
The problem now comes not from tech-previews but from the quarterly forced releases because it's now a subscription. The entire business model is flawed and outdated. Same with Unreal. The difference is Unreal tech is exponentially better than Unity architecturally and they know their audience very well so they were able to get in with virtual stage production, games, movies, you name it. They were successful in expanding beyond their core. Unity, can't. They don't know how.
It's a tough spot to be in. I knew my place when I shut mine down and open sourced it. I couldn't compete. For Unity, they have a loyal fanbase that wants them to succeed but I'm afraid it's going to take breaking everything they know in order to do it.
That last step is nonsensical: WebGPU is a shim layer that Vulkan-like layer (in the sense that WebGL is GLES-like) that allows you to use the native GPGPU-era APIs of your OS.
On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases where the performance should be identical to DX12; AMD does not suffer from this bug.
If you care about performance, you will call Vulkan directly and not pay for the overhead. If you care about portability and/or are compiling to a WASM target, you're pretty much restricted to WebGPU and you have to pay that penalty.
Side note: Nothing stops Windows drivers or Mesa on Linux from providing a WebGPU impl, thus browsers would not need their own shim impl on such drivers and there would be no inherent translation overhead. They just don't.
On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases where the performance should be identical to DX12; AMD does not suffer from this bug.
If you care about performance, you will call Vulkan directly and not pay for the overhead. If you care about portability and/or are compiling to a WASM target, you're pretty much restricted to WebGPU and you have to pay that penalty.
Side note: Nothing stops Windows drivers or Mesa on Linux from providing a WebGPU impl, thus browsers would not need their own shim impl on such drivers and there would be no inherent translation overhead. They just don't.
WebGPU is far from cheap and has to do a substantial amount of extra work to translate to the underlying API in a safe manner. It's not 1:1 with Vulkan and diverges in a few places. WebGPU uses automatic synchronization and must spend a decent amount of CPU time resolving barriers.
You can't just ship a WebGPU implementation in the driver because the last-mile of getting the <canvas> on screen is handled by the browser in entirely browser specific ways. You'd require very tight coordination between the driver and browsers, and you still wouldn't be saving much because the overhead you get from WebGPU isn't because of API translation, rather it's the cost to make the API safe to expose in a browser.
You can't just ship a WebGPU implementation in the driver because the last-mile of getting the <canvas> on screen is handled by the browser in entirely browser specific ways. You'd require very tight coordination between the driver and browsers, and you still wouldn't be saving much because the overhead you get from WebGPU isn't because of API translation, rather it's the cost to make the API safe to expose in a browser.
We already do this by exposing the canvas surface with a semaphore lock. The browser can flip the surface to the canvas (or your app can flip it onto a window surface).
It’s just a HINSTANCE pointer.
You’re right about the waiting, but that’s entirely app driven. Browsers don’t want to render at 144fps but rather wait until drawing has occurred in order to update the view.
wgpu, dawn, already support drawing to arbitrary surfaces (not just a canvas but any window surface).
It’s just a HINSTANCE pointer.
You’re right about the waiting, but that’s entirely app driven. Browsers don’t want to render at 144fps but rather wait until drawing has occurred in order to update the view.
wgpu, dawn, already support drawing to arbitrary surfaces (not just a canvas but any window surface).
You've mentioned dawn more than once, but isn't dawn dead since the team at Google that was working on it isn't part of either the Android nor Chrome teams, and Android and Chrome both have their own (and incompatible with each other) preferred API manglers?
WebGL and WebGPU must robustly defend against malicious web content making the API calls, just like other browser JavaScript APIs, which makes for some overhead and resulted in leaving out some features of the underlying APIs.
Vulkan has also evolved a lot and WebGPU doesn't want to require new Vulkan features, lacking for example bindless textures, ray tracing etc.
Vulkan has also evolved a lot and WebGPU doesn't want to require new Vulkan features, lacking for example bindless textures, ray tracing etc.
All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.
Programs can use Vulkan, D3D, OpenGL, OpenCL, etc, to ex: read memory that isn't in your program's space via the GPU/driver/OS not properly handling pointer provenience. Also, IOMMUs are not always setup correctly, and they are also not bug free, ex: Intel's 8 series.
Using hardware to attack hardware is not new, and not a uniquely web issue.
Programs can use Vulkan, D3D, OpenGL, OpenCL, etc, to ex: read memory that isn't in your program's space via the GPU/driver/OS not properly handling pointer provenience. Also, IOMMUs are not always setup correctly, and they are also not bug free, ex: Intel's 8 series.
Using hardware to attack hardware is not new, and not a uniquely web issue.
> All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.
This is not the case for C/C++ APIs. A native code application using your API can already execute arbitrary code on your computer, so the library implementing eg OpenGL is not expected to be a security boundary and does not need to defend against for example memory safety bugs to get RCE, info leakage, etc by for example sending in booby trapped pointers or sending in crafted inputs designed to trigger bugs in your API internals.
The kernel side stuff is of course supposed to be more robust but also contains a much smaller amount of code than the user facing graphics API. And robustness there is not taken as seriously because they're not directly internet-facing interfaces so browsers can't rely on correctness any protections there.
Which brings us to: drivers throughout the stack are generally very buggy, and WebGL/WebGPU implementations also have to take responsibility for preventing exploitation of those bugs by web content, sometimes at rather big performance cost.
To see what it's like you might browse https://chromereleases.googleblog.com/ and search for WebGPU and WebGL mentions and bug bounty payouts in the vulnerabilities such as
[$10000.0] [448294721] High CVE-2025-14765 Use after free in WebGPU.
[TBD][443906252] High CVE-2025-12725: Out of bounds write in WebGPU.
[$25000.0] [442444724] High CVE-2025-11205 Heap buffer overflow in WebGPU.
[$15000][1464038] High CVE-2023-4072: Out of bounds read and write in WebGL.
[$TBD][1506923] WebGPU High CVE-2024-0225
etc.
C/C++ memory safety is hard, even when you're the biggest browser vendor trying your hardest to expose C APIs to JS bindings safely.
There were a lot of WebGL vulnerabilities in a constant stream as well earlier, before WebGPU became more lucrative for bug bounties.
This is not the case for C/C++ APIs. A native code application using your API can already execute arbitrary code on your computer, so the library implementing eg OpenGL is not expected to be a security boundary and does not need to defend against for example memory safety bugs to get RCE, info leakage, etc by for example sending in booby trapped pointers or sending in crafted inputs designed to trigger bugs in your API internals.
The kernel side stuff is of course supposed to be more robust but also contains a much smaller amount of code than the user facing graphics API. And robustness there is not taken as seriously because they're not directly internet-facing interfaces so browsers can't rely on correctness any protections there.
Which brings us to: drivers throughout the stack are generally very buggy, and WebGL/WebGPU implementations also have to take responsibility for preventing exploitation of those bugs by web content, sometimes at rather big performance cost.
To see what it's like you might browse https://chromereleases.googleblog.com/ and search for WebGPU and WebGL mentions and bug bounty payouts in the vulnerabilities such as
[$10000.0] [448294721] High CVE-2025-14765 Use after free in WebGPU.
[TBD][443906252] High CVE-2025-12725: Out of bounds write in WebGPU.
[$25000.0] [442444724] High CVE-2025-11205 Heap buffer overflow in WebGPU.
[$15000][1464038] High CVE-2023-4072: Out of bounds read and write in WebGL.
[$TBD][1506923] WebGPU High CVE-2024-0225
etc.
C/C++ memory safety is hard, even when you're the biggest browser vendor trying your hardest to expose C APIs to JS bindings safely.
There were a lot of WebGL vulnerabilities in a constant stream as well earlier, before WebGPU became more lucrative for bug bounties.
I wouldn't call it nonsensical to target WebGPU. If you aren't on the bleeding edge for features, its overhead is pretty low and there's value in having one perfectly-consistent API that works pretty well everywhere. (Similar to OpenGL)
I’m foreshadowing a future where they do. Please don’t kill the dream.
I'm not killing it, but there is no C API written verbatim. WebGL was fucky because it was a specific version of GLES that never changed and you couldn't actually do GL extensions; it was a hybrid of 2.0 and 3.0 and some extra non-core/ARB extensions.
WebGPU is trying to not repeat this mistake, but it isn't a 100% 1:1 translation for Vulkan, so everyone is going to need to agree to how the C API looks, and you know damned well Google is going to fuck this up for everyone and any attempt is going to die.
Chrome is the cancer killing desktop computing.
WebGPU is trying to not repeat this mistake, but it isn't a 100% 1:1 translation for Vulkan, so everyone is going to need to agree to how the C API looks, and you know damned well Google is going to fuck this up for everyone and any attempt is going to die.
Chrome is the cancer killing desktop computing.
And Web, because nowadays when people complain about standards, they mean something that only Chrome or Electron crap does.
So use dawn.
The problem is the same as it was 20 years ago. There’s 2 proprietary API’s and then there’s the “open” one.
I’m sick of having to write code that needs to know the difference. There’s only a need for a Render Pass, a Texture handle, a Shader program, and Buffer memory. The rest is implementation spaghetti.
I know the point you’re making but you’re talking to the wrong person about it. I know all the history. I wish for a simpler world where a WebGPU like API exists for all platforms. I’m working on making that happen. Don’t distract.
The problem is the same as it was 20 years ago. There’s 2 proprietary API’s and then there’s the “open” one.
I’m sick of having to write code that needs to know the difference. There’s only a need for a Render Pass, a Texture handle, a Shader program, and Buffer memory. The rest is implementation spaghetti.
I know the point you’re making but you’re talking to the wrong person about it. I know all the history. I wish for a simpler world where a WebGPU like API exists for all platforms. I’m working on making that happen. Don’t distract.
Yeah, I started a project in Unity a while ago, and tried out Godot in the meantime.
Unity really feels like there should be a single correct way to do any specific thing you want, but actually it misses <thing> for your use case so you have to work around it, (and repeat this for every unity feature basically)
Godot on the other hand, really feels like you are being handed meaningful simple building blocks to make whatever you want.
Unity really feels like there should be a single correct way to do any specific thing you want, but actually it misses <thing> for your use case so you have to work around it, (and repeat this for every unity feature basically)
Godot on the other hand, really feels like you are being handed meaningful simple building blocks to make whatever you want.
Bingo. They don’t actually understand their users. Instead they’re the Roblox of game making, just provide the ability and let devs figure it out (and then sell it as a script).
Unity somehow manages to break the API of their own features so bad every year or so that their own tutorials don't work. You have a solid baseline API that has existed since forever (with known limitations), with stuff like the legacy render pipeline. Every attempt to reform it has only introduced confusion, complexity, and is at some point between experimental and no longer supported.
I don't agree with you on the Asset Store, for the same reasons - the rate of breakage means that things that are not constantly updated no longer work - and multple versions need to be maintained for parallel engine versions. That combined with the dubious economics of Asset Store (I don't think it makes financial sense to even make these things, let alone maintain them), they mostly end up as abandonware.
And on the Asset Store if you make something indispensable (which is more often than not something the engine should'have OOTB, like competent text rendering), one of the following things will happen:
- Unity will buy you out, and plop your asset in the engine, without doing any integration work, and will stick out like a sore thumb (TextMeshPro). Good for you, bad for consumers, and sucks if you were making a competitor
- They build an in-house solution, that you obviously can't compete with, and will have a huge leg up on you because they have engine access (sucks to be you)
- The engine will never have that feature, because 'you can just buy it', meaning you have to either spends hundreds of dollars/euros on dubious quality assets or hunt for open-source versions with generally even more varying usability. UE4/5 has a lot of these built in, and AAA quality.
I don't agree with you on the Asset Store, for the same reasons - the rate of breakage means that things that are not constantly updated no longer work - and multple versions need to be maintained for parallel engine versions. That combined with the dubious economics of Asset Store (I don't think it makes financial sense to even make these things, let alone maintain them), they mostly end up as abandonware.
And on the Asset Store if you make something indispensable (which is more often than not something the engine should'have OOTB, like competent text rendering), one of the following things will happen:
- Unity will buy you out, and plop your asset in the engine, without doing any integration work, and will stick out like a sore thumb (TextMeshPro). Good for you, bad for consumers, and sucks if you were making a competitor
- They build an in-house solution, that you obviously can't compete with, and will have a huge leg up on you because they have engine access (sucks to be you)
- The engine will never have that feature, because 'you can just buy it', meaning you have to either spends hundreds of dollars/euros on dubious quality assets or hunt for open-source versions with generally even more varying usability. UE4/5 has a lot of these built in, and AAA quality.
> with a 1999 style property window on the side like Visual Studio was ever cool.
I don't think this is fair. I'd say Unity's inspector window is one of the good parts of Unity because it not just a property window. It's an immediate mode UI that things can hook into to do a lot more than just property editing.
I don't think this is fair. I'd say Unity's inspector window is one of the good parts of Unity because it not just a property window. It's an immediate mode UI that things can hook into to do a lot more than just property editing.
Yes, the last 8 years has seen that little side drawer used for every. single. unity. feature.
Thankfully there are tons of assets you can buy or download from github that will extend the functionality of the inspector windows, which IMO need a LOT of love. The last update I saw was where you can do math inside e.g. transform properties e.g. scale is 1, you can type in 1+2 and it will show in game/scene views immediately your changes, and if you press ENTER it will commit those changes. It's not really well-known (I discovered it by accident reading some changelogs at some point a couple years ago).
Not thankfully. The whole point of this thread is that Unity is barebones without community support. What you’re describing is that community support. Glad you like it. I find these kind of lack of attention to your product a huge turn off. Unity Community is naive in the fact that they allow this company to walk all over them because they lack the willpower to steamroll them. There are plenty of Unity community members that are capable of making a better Unity. Unity itself relies on their community otherwise who would pay for an engine? So by saying “just use this plugin” is basically just reinforcing my perspective.
I agree, hence "need a lot of love".
On the other hand, the lack of "love" from Unity's side (at least regarding Inspector) allows a thriving ecosystem for devs to build their own version of what an ideal Inspector drawer should look like, as well as potentially make a living from it. And to boot, who is to say what the ideal Inspector should look like? Do you trust Unity to make an Inspector that fits everyone's wants/needs? I definitely don't - so I'm glad they have a "bare-bones" version that allows us to customize it to our heart's content. Do you want them to be like Apple and "steamroll" everyone and make bad decisions for arbitrary reasons? I definitely don't and I personally HATE a ton of Apple's constant changes and lack of ability to change simple things, such as the inability to disable a lot of animations, which murders my VNC sessions, but I digress.
Regarding non-Inspector things: you already replied to my other rant about unfinished features, so yeah, also in agreement.
On the other hand, the lack of "love" from Unity's side (at least regarding Inspector) allows a thriving ecosystem for devs to build their own version of what an ideal Inspector drawer should look like, as well as potentially make a living from it. And to boot, who is to say what the ideal Inspector should look like? Do you trust Unity to make an Inspector that fits everyone's wants/needs? I definitely don't - so I'm glad they have a "bare-bones" version that allows us to customize it to our heart's content. Do you want them to be like Apple and "steamroll" everyone and make bad decisions for arbitrary reasons? I definitely don't and I personally HATE a ton of Apple's constant changes and lack of ability to change simple things, such as the inability to disable a lot of animations, which murders my VNC sessions, but I digress.
Regarding non-Inspector things: you already replied to my other rant about unfinished features, so yeah, also in agreement.
The article doesn't cover it but the GC being used by Unity also performs very poorly vs. .NET, and even vs. standalone Mono, because it is using the Boehm GC. Last I heard Unity has no plans to switch IL2CPP to a better GC [1].
It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP build.
[1] https://discussions.unity.com/t/coreclr-and-net-modernizatio...
It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP build.
[1] https://discussions.unity.com/t/coreclr-and-net-modernizatio...
On the one hand, better GC is better but on the other, it doesn't matter all that much.
You tend to want zero per frame allocation as it is and that would probably not change.
As long as your less frequent garbage doesn't overtake the incremental GC, that's not really an issue either. If it's working incrementally as intended stutter shouldn't be an issue.
In a game there's no endless benefit from raw GC throughput like you might see on a server instance that could always push more requests per second.
You tend to want zero per frame allocation as it is and that would probably not change.
As long as your less frequent garbage doesn't overtake the incremental GC, that's not really an issue either. If it's working incrementally as intended stutter shouldn't be an issue.
In a game there's no endless benefit from raw GC throughput like you might see on a server instance that could always push more requests per second.
The entire point of the incremental GC is to preserve frame latency budget at the expense of raw throughput. If you can guarantee <16ms frames, I'll work with whatever you can give me.
If your game is allocating so quickly that the incremental GC can't keep up, I would argue that solving this with a "faster" GC is just taking you further into hell.
If your game is allocating so quickly that the incremental GC can't keep up, I would argue that solving this with a "faster" GC is just taking you further into hell.
> On the one hand, better GC is better but on the other, it doesn't matter all that much.
It shouldn't but it does. Boehm is a conservative GC so when it triggers it needs to scan a lot more memory for pointers than .NET's GC because it has to assume anything in memory could be a pointer.
It shouldn't but it does. Boehm is a conservative GC so when it triggers it needs to scan a lot more memory for pointers than .NET's GC because it has to assume anything in memory could be a pointer.
> because it is using the Boehm GC
For what reason? Mono has a pretty good precise GC since many years.
For what reason? Mono has a pretty good precise GC since many years.
Yes, SGen should be a lot better, but Unity cannot use it because they hold and pass raw pointers around everywhere. That's fine for Boehm but not possible with SGen. They're working on fixing this already but not sure why they aren't planning a move to a better GC.
Well, if they port to .NET (CoreCLR), that will move them to the MS GC.
Yes, but it also puts them in an awkward situation! They recommend (or even require, for some platforms) using IL2CPP for release builds which will still use Boehm GC and not run as quick as CoreCLR.
Do they still need IL2CPP if they have AOT? The goal was always to be able to have cross-platform native binaries right?
In theory yes, IL2CPP doesn't need to exist with modern .NET AOT support. In practice, per quotes in the article Unity may have a bit of a sunk cost issue and has no plans to support .NET AOT, only IL2CPP.
Some of that sunk cost may be the above mentioned pointer issue and not enough current plans for a smarter FFI interface between C++ and C#.
Some of that sunk cost may be the above mentioned pointer issue and not enough current plans for a smarter FFI interface between C++ and C#.
Unfortunately they do still need IL2CPP because Unity took a different direction than .NET: most reflection still works with IL2CPP but does not with .NET AOT. Switching would be a huge breaking change for everyone, including Unity.
Platform support is also still better with IL2CPP but .NET is catching up.
Platform support is also still better with IL2CPP but .NET is catching up.
Re. the editor speedup, it should outright eliminate the "domain reload" thingy that happens because all of the C# needs to be unloaded and reloaded in response to a change.
Pretty sure that will still be there? It'll be different because CoreCLR doesn't really have AppDomains but it will still need to unload old assemblies and reload them all again. That's the only reliable way to reset everything into a clean state.
AssemblyLoadContext.Unload https://learn.microsoft.com/en-us/dotnet/api/system.runtime....
Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out.
Might I suggest https://github.com/stride3d/stride, which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.
Might I suggest https://github.com/stride3d/stride, which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.
Progress has been painfully slow, but Unity does seem to be moving forward.
Unity updates on their plans and progress:
2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-n...
2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-core...
Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.com/2025/11/26/unitys-2026-roadmap...
Unity updates on their plans and progress:
2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-n...
2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-core...
Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.com/2025/11/26/unitys-2026-roadmap...
Maybe they are making progress. But given that they first started talking about this in 2018, and then in 2022 they announced that they were planning to release a version with CoreCLR in 2023, and then in 2024 they said it would be in beta in 2025, and now in 2025 they're planning to release it as a technical preview in 2026, but they're still talking about an "internal proof-of-concept" as though it's something coming in the future...
As an outsider, it certainly seems like there's reason for skepticism.
As an outsider, it certainly seems like there's reason for skepticism.
I've seen similar things from the inside in other companies. Even existential threats (like lack of Apple Silicon support for performance-critical software), getting heavily delayed because the feature treadmill won't stop and the actually important thing is a pet project of some engineer. It is basically death by a thousand papercuts, where nobody can say what the focus is.
People complain about web development but working with native apps can be depressing sometimes.
People complain about web development but working with native apps can be depressing sometimes.
Well they made some business decisions in the middle of that timeline that cut their funds quite a bit, not to mention probably scared off some good talent.
Not just probably scared off some good talent, they had xoofx leave over disagreements with higher management. xoofx was one of their most senior devs, the guy who started the CoreCLR migration and was leading it.
They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev who doesn't care about mobile (which is Unity's real market), competing engines have gotten much more attractive in the last couple years and that seems set to continue.
They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev who doesn't care about mobile (which is Unity's real market), competing engines have gotten much more attractive in the last couple years and that seems set to continue.
The funny thing about his resignation is that xoofx had a CoreCLR prototype already working around 2016-ish, but the company had "other priorities" and only took it seriously until recently.
The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight.
I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space who didn't do his job and will blame xoofx for “not fighting harder” or some other bullshit. Fuck companies, and fuck loser managers.
The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight.
I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space who didn't do his job and will blame xoofx for “not fighting harder” or some other bullshit. Fuck companies, and fuck loser managers.
I think 2016 is a bit too early but yeah, xoofx first wrote about CoreCLR in 2018 and said he'd made considerable progress with something like himself and two other engineers doing it as a side project. That is four years before Unity as a company announced the migration as a priority, which in turn is another four years before the current estimate for when they may ship it.
From my perspective, Unity seems very poorly managed in recent years. The editor experience isn't improving while they continue the usual pattern of shipping features in a poor state where they need another couple versions to become properly usable, and of course they make terrible decisions like the runtime fee, a total insanity that caused a huge loss of trust and boosted Godot development enormously.
Of course my perspective is biased by me not being Unity's main target market. I work on PC strategy games, which are on Steam. At our studio, we don't do mobile, advanced graphics features aren't very relevant, and we may have the most complex UI that ever shipped in a Unity game.
From my perspective, Unity seems very poorly managed in recent years. The editor experience isn't improving while they continue the usual pattern of shipping features in a poor state where they need another couple versions to become properly usable, and of course they make terrible decisions like the runtime fee, a total insanity that caused a huge loss of trust and boosted Godot development enormously.
Of course my perspective is biased by me not being Unity's main target market. I work on PC strategy games, which are on Steam. At our studio, we don't do mobile, advanced graphics features aren't very relevant, and we may have the most complex UI that ever shipped in a Unity game.
Scared off a lot of customers, too.
Nice link, thanks.
Stride has a fraction of the features as unity.
Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries.
A real sandbox solution with actual GPU support is needed.
Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries.
A real sandbox solution with actual GPU support is needed.
Writing C# in godot is a bad choice. Use GDScript and directly write c++ as a module. Skip "HD extension" completely. Godots build system is easy enough to use. Just add new classes to the engine using c++ if you don't want to use GDScript. The GDScript workflow is honestly great. Using C# is like the worst of all worlds.
GDScript is not very maintainable as the code base grows. It lacks proper refactoring tools (e.g. the ones from Jetbrains Rider), static type checking, flexible object system and many 3rd party libraries which might be needed
My main point is: if GDScript isn't good enough, go straight to c++ directly in the Engine.
I won't even get into how big of projects I've written in GDScript successfully.
I won't even get into how big of projects I've written in GDScript successfully.
I don't want to do manual memory management and pointer handling
I don't want to have any sort of undefined behavior
I want to have quick code reload button in the editor
I want to still rely of the engine official documentation with examples like it is with GDScript and C#
I don't want to have any sort of undefined behavior
I want to have quick code reload button in the editor
I want to still rely of the engine official documentation with examples like it is with GDScript and C#
You likely won't need to do manual memory management nor think about undefined behavior. If your writing basic c++ to handle the simulation in a game, it's going to be pretty orthodox and these problems likely won't manifest.
The purpose of recommending c++ here is:
If GDScript is too slow, reach directly for C++.
I'm specifically recommending GDScript over C# for ease of use and c++ over C# for performance.
The purpose of recommending c++ here is:
If GDScript is too slow, reach directly for C++.
I'm specifically recommending GDScript over C# for ease of use and c++ over C# for performance.
[deleted]
I don't like C++.
It's very difficult to me, I generally stick to high level stuff , C#, JavaScript, Python, Dart, etc.
It's very difficult to me, I generally stick to high level stuff , C#, JavaScript, Python, Dart, etc.
If you can code in C#, how is C++ difficult? Are pointers and the stl that difficult?
Not denigrating, genuine question.
Not denigrating, genuine question.
One word.
Headers.
That's just the start. The C++ build system and package managers are the stuff if nightmares. Modern languages are significantly easier to use.
Don't get me wrong, if you offer a job with a 200k base salary and give me 6 months to learn C++ I'll do it. But I won't enjoy it, and I definitely won't do it as a hobby.
Headers.
That's just the start. The C++ build system and package managers are the stuff if nightmares. Modern languages are significantly easier to use.
Don't get me wrong, if you offer a job with a 200k base salary and give me 6 months to learn C++ I'll do it. But I won't enjoy it, and I definitely won't do it as a hobby.
If you use an existing template (and are willing to use scons) GDExtension doesn't really have the standard build problems of rigging everything up with CMake/etc in my experience. The template is set up to handle the "set up the build" problem for you. Still have the header problem though cannot deny that one.
You're asking if going from a high level language to a low level language on steroids is difficult?
Pointers, manual memory management, and the design by committee standard library are not fun.
Pointers, manual memory management, and the design by committee standard library are not fun.
I write mostly backend stuff for a living, big chunk of it in Node/TS but also C# with modern .NET. I also have to dabble with Unity and Unreal both for work and a hobby project. I technically learned C++ in uni but really, I hate every single second I have to spend doing Unreal Engine work. I genuinely despise how obsolete and hard to write C++ is compared to modern languages. It didn't bother me in university because that was all I knew at the time but it's hard to justify existence of header files today. Add macros everywhere, really bad compilation errors, really hard to read syntax with a lot of unnecessary bloat and you get something that is just not likable. I'm sure you can get used to it given enough time spent in that ecosystem, but I can tell you as someone writing 4 different languages on day to day basis, C++ is difficult, and it's not because of pointers.
Yeah that's why GDScript is great.
You only dabble in the c++ for the sliver of the project that needs it. 90% of game development is animating stuff and user interface development. GDScript is great for that.
You only dabble in the c++ for the sliver of the project that needs it. 90% of game development is animating stuff and user interface development. GDScript is great for that.
Java was designed to make fun of C++, then C# was designed to make fun of Java, so you're missing two layers of fun.
I can tolerate Java. I've worked a Java dev role recently.
I think it's overly verbose and probably has a lot of unneeded legacy stuff, but in terms of making money so I can afford donuts, it's not bad.
My personal favorite language is probably Dart, but it's basically useless outside of Flutter and I don't have faith in Google to keep Flutter going.
I don't like low level programming. My dream language is literally an LLM that processes a markdown document where I sorta just describe what I want to happen. With options to call defined functions in a normal programing language
If I had money ( VC money) I'd be working on this.
I think it's overly verbose and probably has a lot of unneeded legacy stuff, but in terms of making money so I can afford donuts, it's not bad.
My personal favorite language is probably Dart, but it's basically useless outside of Flutter and I don't have faith in Google to keep Flutter going.
I don't like low level programming. My dream language is literally an LLM that processes a markdown document where I sorta just describe what I want to happen. With options to call defined functions in a normal programing language
If I had money ( VC money) I'd be working on this.
Problem is, GDScript still doesn't have at least a JIT, and the whole GDextensions boilerplate seems more complicated than it needs to be.
"not having a JIT" is not a problem, it's you speculating that a JIT will improve performance, the real problem is "GDScript has poor performance", which in this context (me saying C# in godot sucks) is you speculating that C#'s performance is better than GDScripts. Do you have any data to back that claim up? Like real world data from a real product? Or are you just speculating with vibes?
If performance is a concern, skip C# and go straight to c++. Now your ripping at max speed with the smallest binary! That's my whole point. GDScript + c++ is my point. Ditch C# it's not worth the squeeze.
If performance is a concern, skip C# and go straight to c++. Now your ripping at max speed with the smallest binary! That's my whole point. GDScript + c++ is my point. Ditch C# it's not worth the squeeze.
Some people like nice tooling with performance.
Interpreter code is never faster than a dynamic compiler, otherwise what about doing games in Python?
As mentioned on my comment, GDextension experience kind of sucks.
Interpreter code is never faster than a dynamic compiler, otherwise what about doing games in Python?
As mentioned on my comment, GDextension experience kind of sucks.
Lots of excellent games are written in Python, Lua, JavaScript and GDScript. These abstract criticisms are just that, abstract.
I'm offering real practical advice from experience of having worked on real projects.
I'll make it real clear:
GDScript & c++ > C#
I'm offering real practical advice from experience of having worked on real projects.
I'll make it real clear:
GDScript & c++ > C#
[deleted]
Are there technical reasons to prefer GDScript over C#?
GDScript is undoubtedly better integrated in the engine, but I would have expected C# compare more favorably in larger projects than the game jam sized projects I have made.
GDScript is undoubtedly better integrated in the engine, but I would have expected C# compare more favorably in larger projects than the game jam sized projects I have made.
Performance is one issue with C#: https://sampruden.github.io/posts/godot-is-not-the-new-unity...
I don't see how this article could possibly support the argument that C# is slower than GDScript
It compares several C# implementations of raycasts, never directly compares with GDScript, blames the C# performance on GDScript compatibility and has an strike-out'ed section advocating dropping of GDScript to improve C# performance!
Meanwhile, Godot's official documentation[1] actually does explicitly compare C# and GDScript, unlike the the article which just blames GDScript for C#'s numbers, claiming that C# wins in raw compute while having higher overhead calling into the engine
[1]: https://docs.godotengine.org/en/stable/about/faq.html#doc-fa...
It compares several C# implementations of raycasts, never directly compares with GDScript, blames the C# performance on GDScript compatibility and has an strike-out'ed section advocating dropping of GDScript to improve C# performance!
Meanwhile, Godot's official documentation[1] actually does explicitly compare C# and GDScript, unlike the the article which just blames GDScript for C#'s numbers, claiming that C# wins in raw compute while having higher overhead calling into the engine
[1]: https://docs.godotengine.org/en/stable/about/faq.html#doc-fa...
My post could have been a bit longer. It seems to have been misunderstood.
I use GDScript because it’s currently the best supported language in Godot. Most of the ecosystem is GDScript. C# feels a bit bolted-on. (See: binding overhead) If the situation were reversed, I’d be using C#. That’s one technical reason to prefer GDScript. But you’re free to choose C# for any number of reasons, I’m just trying to answer the question.
I use GDScript because it’s currently the best supported language in Godot. Most of the ecosystem is GDScript. C# feels a bit bolted-on. (See: binding overhead) If the situation were reversed, I’d be using C#. That’s one technical reason to prefer GDScript. But you’re free to choose C# for any number of reasons, I’m just trying to answer the question.
At least in my case, I got curious about the strength of /u/dustbunny's denouncement of Godot+C#.
I would have have put it as a matter of preference/right tool with GDScripts tighter engine integration contrasted with C#'s stronger tooling and available ecosystem.
But with how it was phrased, it didn't sound like expressing a preference for GDScript+C++ over C# or C#++, it sounded like C# had some fatal flaw. And that of course makes me curious. Was it a slightly awkward phrasing, or does C# Godot have some serious footgun I'm unaware of?
I would have have put it as a matter of preference/right tool with GDScripts tighter engine integration contrasted with C#'s stronger tooling and available ecosystem.
But with how it was phrased, it didn't sound like expressing a preference for GDScript+C++ over C# or C#++, it sounded like C# had some fatal flaw. And that of course makes me curious. Was it a slightly awkward phrasing, or does C# Godot have some serious footgun I'm unaware of?
Makes sense! I think dustbunny said it best: C# is “not worth the squeeze” specifically in Godot, and specifically if you’re going for performance. But maybe that’ll change soon, who knows. The engine is still improving at a good clip.
I think WebAssembly could become that sandboxed solution. .NET Blazor WASM is moving away from mono to CoreCLR (just like Unity, with an early preview in late 2026). WASM now has really good SIMD support, native GC, large memory support, and with WebGPU we could finally see some native WASM games running at native speeds.
Wait, what, WASM has native GC now?
It's still not JS-level/JS-compatible GC (yet?) and it is still quite low level (more about corralling buffers of bytes than objects, a bit closer to OS-level page management than JS or C# level GC), as it is intended to be lower level than most languages need so that different languages can build different things with it. It is also a tiny stepping stone to better memory sharing with JS APIs (and the eventual goal of WASM "direct DOM"), but still not quite finished on that front as more steps remain.
Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125
We'll see when it actually ships.
I've seen this issue before, they're making progress but theirs no firm release date.
Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.
I've seen this issue before, they're making progress but theirs no firm release date.
Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.
Naive question but why not use GDscript? I haven't had any issues with it
I'll vibe code stuff in GDscript, and I guess I more or less understand some of it.
But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language.
Plus a lot of C# assets/libraries don't really have GDScript counterparts.
But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language.
Plus a lot of C# assets/libraries don't really have GDScript counterparts.
I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.
I'd caveat this slightly as "it depends"
For mathy stuff, 100% c# is going to be better. But if you need to round trip to the engine a lot getting stuff in and out of the dotnet heap can actually hurt performance. You also have to be _really_ careful because there are a lot of cases you generate accidental garbage (biggest one is when you use strings that are getting implicitly converted to StringNames every time you run a function, you can avoid this by pre-generating them as consts but I've run into a fair few people who never ran dotmemory or the like to see the issues).
For mathy stuff, 100% c# is going to be better. But if you need to round trip to the engine a lot getting stuff in and out of the dotnet heap can actually hurt performance. You also have to be _really_ careful because there are a lot of cases you generate accidental garbage (biggest one is when you use strings that are getting implicitly converted to StringNames every time you run a function, you can avoid this by pre-generating them as consts but I've run into a fair few people who never ran dotmemory or the like to see the issues).
Yes, it tooks me 2 years to see how much garbage strings conversion to String Names generates and how a fool I was calling something like Input.IsActionPressed("move_right") every frame (sadly it's the example given in the input documentation).
Yup. I remember running dotmemory on a whim and being confused by all the stringnames until I noticed what was in them. They really should put that in the docs to just make a const stringname somewhere. I use a global static class for anything I want in multiple files. But I also tend to just use statics instead of autoloads if I'm doing everything in c#.
> Yeah I think Unity just doesn't have the technical skillset anymore
It's not a technical skillset issue, it's a case of lacking resources, leadership changing priorities and changing requirements mid-development, causing a lot of work to be redone.
We still have highly skilled developers working in this area, if we can just actually be allowed to do (and keep) we work we have.
It's not a technical skillset issue, it's a case of lacking resources, leadership changing priorities and changing requirements mid-development, causing a lot of work to be redone.
We still have highly skilled developers working in this area, if we can just actually be allowed to do (and keep) we work we have.
Imagine you have to communicate that rewrite and drop of support for bought "addons" to the people who went on that shopping spree. Who then would have to explain the "wecan"-value drop + cost of recovery of the same abilities to the shareholders and customers. The magpiesnest of bought companies tech is a tarbaby for any tech lead, the rewrite a career ender for the CEOs office.
> In 2018, Unity engineers discussed that they are working on porting the engine to .NET CoreCLR
Hard task, no doubt. Unity needs to throw everything at this problem. C# in general has gotten insanely fast by default. It's very much worth taking the time to upgrade/update.
Whilst we don't compare in size and api surface, it took us a few months to get off 472 and onto dotnet6. But once we were on dotnet6, moving to the LTS after that was relatively painless; usually a few hours of work.
Hard task, no doubt. Unity needs to throw everything at this problem. C# in general has gotten insanely fast by default. It's very much worth taking the time to upgrade/update.
Whilst we don't compare in size and api surface, it took us a few months to get off 472 and onto dotnet6. But once we were on dotnet6, moving to the LTS after that was relatively painless; usually a few hours of work.
I wrote the Circuits programming system for Rec Room, and we took a similar approach: keeping the core logic free of Unity dependencies so it could run and be tested on CoreCLR.
The results were similar as well with significantly better performance outside of Unity. There are also secondary benefits. Unity’s API surface is huge, and it’s easy for code to accidentally entangle itself with engine details in ways that confuse or constrain other developers.
By isolating the core in a separate DLL, we only expose Unity concepts where they’re actually needed, and we enforce that boundary with tests. That logic constraint ended up being just as valuable as the performance gain
The results were similar as well with significantly better performance outside of Unity. There are also secondary benefits. Unity’s API surface is huge, and it’s easy for code to accidentally entangle itself with engine details in ways that confuse or constrain other developers.
By isolating the core in a separate DLL, we only expose Unity concepts where they’re actually needed, and we enforce that boundary with tests. That logic constraint ended up being just as valuable as the performance gain
It blows my mind that Unity has not been able to migrate to .NET (CoreCLR) after starting back in 2018.
I would have estimated a year, or two tops, for that project.
I would have estimated a year, or two tops, for that project.
I recently started learning Godot and learning that they use .NET for the C# runtime is a nice touch. I write a lot of code that targets .NET in my day job, so having to learn the unity way of doing things would be frustrating.
My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android. Simple console apps first, then the rest. Google should open their platform up a little bit more. Allow us to enable root access via adb. Let us unleash our pocket computer's full potentials. Would love to have portable low powered servers, running stacks of my choice. They are super efficient already, have large storages, I can already plug in a usb-c hub into my phone to get more storage, LAN network, keyboard/mouse, external mic if needed. Running my phone with wireguard/tailscale + some lightweight containers = awesome!
Unity really do need to catch up though. .Net 8/10 is really amazing and FAST. With the new garbage collector changes for .Net 10, game stutter would be nearly gone gone.
Unrelated point: I basically stream most of my games with Sunlight + Moonlight from my main rig to my phone with a controller attached, so I can play Diablo 2 remastered, Hades, Grim Dawn and basically any game with Xbox controller support, directly on my phone. Works amazingly well. Phones has high dpi screen + 120hz OLED panel and since all rendering happens on my headless gaming server, at highest settings, the phone's battery doesn't really drain at all, can play for hours. Playing a Mono based game from the play store can drain the battery within 2 hours, and the games are usually so badly built for android, even paid games that have equivalents on steam.
Unity really do need to catch up though. .Net 8/10 is really amazing and FAST. With the new garbage collector changes for .Net 10, game stutter would be nearly gone gone.
Unrelated point: I basically stream most of my games with Sunlight + Moonlight from my main rig to my phone with a controller attached, so I can play Diablo 2 remastered, Hades, Grim Dawn and basically any game with Xbox controller support, directly on my phone. Works amazingly well. Phones has high dpi screen + 120hz OLED panel and since all rendering happens on my headless gaming server, at highest settings, the phone's battery doesn't really drain at all, can play for hours. Playing a Mono based game from the play store can drain the battery within 2 hours, and the games are usually so badly built for android, even paid games that have equivalents on steam.
I believe the root constraints are a security thing. They don't want you to charge your phone in a dodgy USB outlet in a public space (e.g. an airport) and be compromised. Making you flash your phone to get root is meant to prevent people accidentally exposing themselves.
Google can provide a non-rooted system image out of the box for safety, but nothing stops them from providing a clean & rooted image for download that I can flash onto device if needed.
The security model should already be tight enough so that a dodgy usb outlet does not compromise the core system (rewriting system images).
The security model should already be tight enough so that a dodgy usb outlet does not compromise the core system (rewriting system images).
> My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android
My understanding is that you can (almost) do that using MAUI (formerly known as Xamarin). You will not get a .Net SDK or Runtime, but the mono runtime. Since it is bundled in your app, you won't actually notice.
My understanding is that you can (almost) do that using MAUI (formerly known as Xamarin). You will not get a .Net SDK or Runtime, but the mono runtime. Since it is bundled in your app, you won't actually notice.
No, we need one level lower & zero mono. I want the sdk or runtime to be installed in the same way (and executable) the same way on android as on other linux distro's. .Net has ARM builds so it will work fine. This is without any specific framework dependencies (like aspnet, maui, avalonia etc) - just plain .net 8/10. It would actually be nice if android just bundled the runtime to begin with so we don't have to. They can just pin it to latest LTS versions and let it auto update now & then, same way as WebView/Google play services etc.
So for whatever reason you want the .NET runtime over Mono - not sure why that is a hard requirement, but AFAIK that is also the goal for microsoft. As in, merging those runtimes and have a single codebase that works for all platforms (including android). There are technical obstacles and historic codebases, but I would expect this unified runtime soon.
Cause since .Net Core 3 (first real production ready cross platformness) to .Net 10 (current LTS) is light years ahead of .Net Framework 4.8 / Mono (which is like half the performance of old .Net 4.8..). Not to be crude, but mono is pretty much trash. Should just be deprecated and the engine bro's should just stick to .Net LTS version (8 or 10, but 8 will be dead in a year). .Net 8/10 also has much better build tools, cleaner & smaller executables, better packaging tools to make deployments a breeze over the old system. The compiler is also much faster in general. You can tree-shake the hell out of your builds to get very lean artifacts. And then there is the garbage collector. And all of the low level optimizations in the CLR that just makes everything fast & less memory hungry.
Unity should really create a version of their engine on .Net 10, make the core as platform-agnostic as possible. It's fine if this variant is not backwards compatible. .Net 10 is also already on Xbox.
Unity should really create a version of their engine on .Net 10, make the core as platform-agnostic as possible. It's fine if this variant is not backwards compatible. .Net 10 is also already on Xbox.
You can create Android apps in plain .NET, building Android UIs directly with C#
Its a pain though. We tried last year at work to build something a little bit more complex than their examples, and it was a pain. Gave up after a month and built our apps in Flutter instead. Works like a charm.
I’ve been building this way since 2018 using MvvmCross[0] and it's become much less painful with LLMs where you can simply ask to recreate an iOS UI on Android. I even managed to implement experimental hot reload[1] for native UIs on Android from .NET, but ended up not using it because, again, nowadays it's faster to iterate with Claude Code – it just one-shot things most of the time.
Currently I'm building an app with Uno Platform[2], which is basically .NET Flutter, and while it's cool to get things working across five different platforms at once, you can note the difference, especially on scroll. No automatic Liquid Glass / Material 3 for it either.
So it's a choose your poison situation: either building native interfaces on each platform separately, or fighting later with an additional layer of abstraction and a canvas-based UI wheel reinvention.
[0]: https://github.com/MvvmCross/MvvmCross
[1]: https://github.com/ivmirx/HotDemo
[2]: https://platform.uno/
Currently I'm building an app with Uno Platform[2], which is basically .NET Flutter, and while it's cool to get things working across five different platforms at once, you can note the difference, especially on scroll. No automatic Liquid Glass / Material 3 for it either.
So it's a choose your poison situation: either building native interfaces on each platform separately, or fighting later with an additional layer of abstraction and a canvas-based UI wheel reinvention.
[0]: https://github.com/MvvmCross/MvvmCross
[1]: https://github.com/ivmirx/HotDemo
[2]: https://platform.uno/
Does anyone on here know why it is that Unity doesn't just run on .NET? The cross-platform benefits of Mono have disappeared a decade ago or something like that.
Like, why would Unity invest in hacks like il2cpp rather than just port over to modern .NET? Is there some licensing thing going on?
Like, why would Unity invest in hacks like il2cpp rather than just port over to modern .NET? Is there some licensing thing going on?
The article touches on it - assuming it's correct, it's because they did a bunch of proprietary modifying on Mono, so it's not "just" Mono any more, it's Mono and a decade or more of the most exciting layer violating crimes you can imagine.
I would assume, if someone Meta scale had an app that had to be built on Unity for whatever reason, we'd see similar blogposts to the ones they did about finding bespoke optimizations for their Android app to be performant with how enormous it became, probably involving either some bespoke alternative to IL2CPP, or writing a bunch of bespoke optimizations onto a bastard descendant of whatever version of Mono Unity originally derives from and so supports...or just paying Unity so much money they get to do whatever they want to the underlying source.
I would assume, if someone Meta scale had an app that had to be built on Unity for whatever reason, we'd see similar blogposts to the ones they did about finding bespoke optimizations for their Android app to be performant with how enormous it became, probably involving either some bespoke alternative to IL2CPP, or writing a bunch of bespoke optimizations onto a bastard descendant of whatever version of Mono Unity originally derives from and so supports...or just paying Unity so much money they get to do whatever they want to the underlying source.
I’ve heard (but don’t have an inside source) that Meta’s Horizon was built on Unity and then ported to a custom engine implementation.
Sunk cost fallacy will be a big factor. They already invested a lot of money/time into customizing Mono and hacks like Burst and IL2CPP, so there's momentum to "stay the course" and continue investing in those. Even if some evidence suggests that it is the wrong course.
Good article but seems strange that author benchmarked debug builds first, that’s a huge “no-no” in any perf tweaking and it’s clear that authors knows this well
From my experience, performance gains seen in Debug builds in Unity/C#/Mono nearly always translate in gains in Release mode. I know that this is not always true, but in this context that's my experience.
Setting up release benchmarks is much more complex and we develop the game in Debug mode, so it is very natural to get the first results there, and if promising, validate them in Release.
Also, since our team works in Debug mode, even gains that only speed things up in Debug mode are valuable for us, but I haven't encountered a case where I would see 20%+ perf gain in Debug mode that would not translate to Release mode.
Setting up release benchmarks is much more complex and we develop the game in Debug mode, so it is very natural to get the first results there, and if promising, validate them in Release.
Also, since our team works in Debug mode, even gains that only speed things up in Debug mode are valuable for us, but I haven't encountered a case where I would see 20%+ perf gain in Debug mode that would not translate to Release mode.
I agreed with you initially, but is it really as big of a deal in C#? I'm used to compiled languages where "debug build" means "no compiler optimisations", aka every operation done with a variable is a memory load + store, trivial functions aren't inlined so even trivial accessors called in a loop carry function call overhead, etc etc. But this is C#, so the JIT presumably optimises just as much in a debug build as in a release build?
So in C++ terms, it's really just benchmarking "-O2" instead of "-O2 -DNDEBUG". This seems fine.
So in C++ terms, it's really just benchmarking "-O2" instead of "-O2 -DNDEBUG". This seems fine.
CoreCLR doesn't help on console platforms because you can't ship the JIT runtime. To my knowledge CoreCLR's AOT solution won't work because of SDK and build requirements for shipping builds on consoles. I believe some consoles require that all shipped native code must have been compiled with the SDK compiler. Even if you fork the CoreCLR AOT system so you can build for the consoles (the code can't be open because of NDAs) you wouldn't be allowed to ship the binary. IL2CPP is the only path forward there. CoreCLR is only viable on PC.
Simply not true, this info is outdated by a decade.
CoreCLR NativeAOT is already shipping real games on Nintendo, PS5, and Xbox.
JIT isn't allowed on iPhones either, and this is what NativeAOT solves. Also, .NET is moving WASM support to CoreCLR (rather than mono) in an upcoming version as well.
CoreCLR NativeAOT is already shipping real games on Nintendo, PS5, and Xbox.
JIT isn't allowed on iPhones either, and this is what NativeAOT solves. Also, .NET is moving WASM support to CoreCLR (rather than mono) in an upcoming version as well.
Do you have examples? As far as I'm aware based on current info there's at least one current console vendor that requires all native code to be generated by their SDK.
Just don't ship to PlayStation and discourage others until Sony changes (is forced to) policy.
Capcom does, and they are quite happy with it.
Yes, it does, Capcom is using it for their Playstation 5 games, like Devil May Cry.
"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"
https://www.youtube.com/watch?v=tDUY90yIC7U
As always, it is a matter of having the skill to deliver, instead of GC phobia.
"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"
https://www.youtube.com/watch?v=tDUY90yIC7U
As always, it is a matter of having the skill to deliver, instead of GC phobia.
If I'm interpreting that correctly they're using an IL2CPP compilation system that hooks into Roslyn and not using .NET Core's AOT technology. It's possible to ship C# on consoles, obviously, because Unity already does it with their own IL2CPP backend that's stuck on the old .NET versions. My point is that CoreCLR can't be used because of console certification requirements. I certainly wasn't commenting on C# as language for games. I think C# is, as of late, becoming a very powerful language for games with all the Span and similar tools to minimize GC pressure.
That's interesting. I made measurements with Mono and CoreCLR some years ago, but only with a single thread, and I came to the conclusion that their performance was essentially the same (see https://rochus.hashnode.dev/is-the-mono-clr-really-slower-th...). Can someone explain what benchmarks were actually used? Was it just the "Simple benchmark code" in listing 1?
I think a lot of the devil is in the details, especially when we look at NET8/NET10 and the various other 'boosts' they have added to code.
But also, as far as this article, it's noting a noting a more specific use case that is fairly 'real world'; Reading a file (I/O), doing some form of deserialization (likely with a library unless format is proprietary) and whatever 'generating a map' means.
Again, this all feels pretty realistic for a use case so it's good food for thought.
> Can someone explain what benchmarks were actually used?
This honestly would be useful in the article itself, as well as, per above, some 'deep dives' into where the performance issues were. Was it in file I/O (possibly Interop related?) Was it due to some pattern in the serialization library? Was it the object allocation pattern (When I think of C# code friendly for Mono I think of Cysharp libraries which sometimes do curious things)? Not diving deeper into the profiling doesn't help anyone know where the focus needs to be (unless it's a more general thing, in which case I'd hope for a better deep dive on that aspect.)
Edited to add:
Reading your article again, I wonder whether your compiler is just not doing the right things to take advantage of the performance boosts available via CoreCLR?
E.x. can you do things like stackalloc temp buffers to avoid allocation, and does the stdlib do those things where it is advantageous?
Also, I know I vaguely hit on this above, but also wondering whether the IL being done is just 'not hitting the pattern'. where a lot of CoreCLR will do it's best magic if things are arranged a specific way in IL based on how Roslyn outputs, but even for the 'expected' C# case, deviations can lead to breaking the opt.
But also, as far as this article, it's noting a noting a more specific use case that is fairly 'real world'; Reading a file (I/O), doing some form of deserialization (likely with a library unless format is proprietary) and whatever 'generating a map' means.
Again, this all feels pretty realistic for a use case so it's good food for thought.
> Can someone explain what benchmarks were actually used?
This honestly would be useful in the article itself, as well as, per above, some 'deep dives' into where the performance issues were. Was it in file I/O (possibly Interop related?) Was it due to some pattern in the serialization library? Was it the object allocation pattern (When I think of C# code friendly for Mono I think of Cysharp libraries which sometimes do curious things)? Not diving deeper into the profiling doesn't help anyone know where the focus needs to be (unless it's a more general thing, in which case I'd hope for a better deep dive on that aspect.)
Edited to add:
Reading your article again, I wonder whether your compiler is just not doing the right things to take advantage of the performance boosts available via CoreCLR?
E.x. can you do things like stackalloc temp buffers to avoid allocation, and does the stdlib do those things where it is advantageous?
Also, I know I vaguely hit on this above, but also wondering whether the IL being done is just 'not hitting the pattern'. where a lot of CoreCLR will do it's best magic if things are arranged a specific way in IL based on how Roslyn outputs, but even for the 'expected' C# case, deviations can lead to breaking the opt.
The goal of my compiler is not to get out maximum performance, neither of CoreCLR nor Mono. Just look at it as a random compiler which is not C#, especially not MS's C# which is highly in sync and optimized for specific features of the CoreCLR engine (which might appear in a future ECMA-335 standard). So the test essentially was to see what both, CoreCLR and Mono, do with non-optimized CIL generated by not their own compiler. This is a legal test case because ECMA-335 and its compatible CLR were exactly built for this use-case. Yes, the CIL output of my compiler could be much more improved, and I could even get more performance out of e.g. CoreCLR by using the specific knowledge of the engine (which you cannot find in the standard) which also the MS C# compiler uses. But that was not my goal. Both engine got the same CIL code and I just measured how fast it run on both engines on the same machine.
[deleted]
> Reading your article again, I wonder whether your compiler is just not doing the right things to take advantage of the performance boosts available via CoreCLR?
> E.x. can you do things like stackalloc temp buffers to avoid allocation, and does the stdlib do those things where it is advantageous?
The C# standard lib (often called the base class library or BCL) has seen a ton of Span<T>/Memory<T>/stackalloc internal usage adoption in .NET 6+, with each release adding more of them. Things like File IO and serialization/deserialization particularly see a lot of notable performance improvements just from upgrading each .NET version. .NET10 is faster than .NET9 with a lot of the same code, and so forth.
Mono still benefits from some of these BCL improvements (as more of the BCL is shared than not these days, and Blazor WASM for the moment is still more Mono than CoreCLR so some investment has continued), but not all of them and not always in the same ways.
> E.x. can you do things like stackalloc temp buffers to avoid allocation, and does the stdlib do those things where it is advantageous?
The C# standard lib (often called the base class library or BCL) has seen a ton of Span<T>/Memory<T>/stackalloc internal usage adoption in .NET 6+, with each release adding more of them. Things like File IO and serialization/deserialization particularly see a lot of notable performance improvements just from upgrading each .NET version. .NET10 is faster than .NET9 with a lot of the same code, and so forth.
Mono still benefits from some of these BCL improvements (as more of the BCL is shared than not these days, and Blazor WASM for the moment is still more Mono than CoreCLR so some investment has continued), but not all of them and not always in the same ways.
> The C# standard lib (often called the base class library or BCL) has seen a ton of Span<T>/Memory<T>/stackalloc internal usage adoption in .NET 6+, with each release adding more of them. Things like File IO and serialization/deserialization particularly see a lot of notable performance improvements just from upgrading each .NET version. .NET10 is faster than .NET9 with a lot of the same code, and so forth.
I worded my reply poorly, mostly in that I meant 'If Oberon has it's own stdlib, is it doing the modern performant practice' ?
I worded my reply poorly, mostly in that I meant 'If Oberon has it's own stdlib, is it doing the modern performant practice' ?
What's going on with the Mandelbrot result in that post?
I don't beleive such a large regression from .NET framework to CoreCLR.
I don't beleive such a large regression from .NET framework to CoreCLR.
NGL would be nice if there was a clear link to the cases used both for OP as well as who you are replying to... Kinda get it in OP's case tho.
I measured the raw horsepower of the JIT engine itself, not the speed of the standard library (BCL). My results show that the Mono engine is surprisingly capable when executing pure IL code, and that much of the 'slowness' people attribute to Mono actually comes from the libraries, not the runtime itself.
In contrast, the posted article uses a very specific, non-standard, and "apple-to-oranges" benchmark. It is essentially comparing a complete game engine initialization against a minimal console app (as far as I understand), which explains the massive 3x-15x differences reported. The author is actually measuring "Unity Engine Overhead + Mono vs. Raw .NET", not actually "Mono vs. .NET" as advertized. The "15x" figure comes very likely from the specific microbenchmark (struct heavy loop) where Mono's optimizer fails, extrapolated to imply the whole runtime is that much slower.
In contrast, the posted article uses a very specific, non-standard, and "apple-to-oranges" benchmark. It is essentially comparing a complete game engine initialization against a minimal console app (as far as I understand), which explains the massive 3x-15x differences reported. The author is actually measuring "Unity Engine Overhead + Mono vs. Raw .NET", not actually "Mono vs. .NET" as advertized. The "15x" figure comes very likely from the specific microbenchmark (struct heavy loop) where Mono's optimizer fails, extrapolated to imply the whole runtime is that much slower.
Can we reproduce your results for Mandelbrot?
You can find all necessary information/data in the article (see references). Finding the same hardware that I used might be an issue though. Concerning Mandelbrot, I wouldn't spend too much time, because the runtime was so short for some targets that it likely has a big error margin compared to the other results. For my purpose this is not critical because or the geometric mean over all factors.
I think we are trying to find something like 'can we pull this branch/commit/etc and build it to reproduce'.
The Mono and .Net 4 times were too short; the true time is unknown. I only left the Mandelbrot result because I got a decently looking figure for CoreCLR, but the actual factor to Mono is unreliable. If the Mono result was 1, the factor would still be seven. I have no idea why it is that much faster.
I think the “some years ago” is pretty relevant.
.NET has heavily invested in performance. If I understand your article correctly, you tested .NET 5 which will be much slower at this point than .NET 10 is.
I also think it matters what you mean by “Mono”. Mono, the original stand-alone project has not seen meaningful updates in many years. Mono is also one of the two runtimes in the currently shipping .NET though and I suspect this runtime has received a lot of love that may not have flowed back to the original Mono project.
.NET has heavily invested in performance. If I understand your article correctly, you tested .NET 5 which will be much slower at this point than .NET 10 is.
I also think it matters what you mean by “Mono”. Mono, the original stand-alone project has not seen meaningful updates in many years. Mono is also one of the two runtimes in the currently shipping .NET though and I suspect this runtime has received a lot of love that may not have flowed back to the original Mono project.
Will the move to CoreCLR give any speed ups in practice if the release build is complied with IL2CPP anyway? On all the games that I've worked on, IL2CPP is one of the first things that we've enabled, and the performance difference between the editor and release version is very noticeable.
The author (probably unknowingly) glosses over a lot in these sentences of the "How did we get here" section:
> Unity uses the Mono framework to run C# programs and back in 2006 it was one of the only viable multi-platform implementations of .NET. Mono is also open-source, allowing Unity to do some tweaks to better suit game development. [...] An interesting twist happened nearly 10 years later.
Not mentioned is that Mono itself of course improved a lot over the years, and even prior to MS's about-face on open source, it was well known that Unity was hindered by sticking with an old and out-of-date Mono, and they were very successful at deflecting the blame for this by throwing the Mono folks under the bus. Any time complaints about game developers' inability to use newer C# features came up, Mono/Xamarin would invariably receive the ire* because Unity couldn't come to an agreement with them about their license and consulting fees. (Mono was open source under LGPL instead of MIT licensed at the time, and Unity had initially bought a commercial license that allowed them exemptions from even the soft copyleft provisions in the LGPL, but the exemption was limited and not, for example, for any and all future versions, too, indefinitely.) Reportedly, they were trying to charge too much (whatever that means) for Unity's attempts to upgrade to the modern versions.
It's now 10+ years later, and now not only Mono (after being relicensed under MIT) but .NET CoreCLR are both available for Unity at no cost, but despite this it still took Unity years before they'd upgraded their C# language support and to a slightly more modern runtime.
Something else to note: Although, LGPL isn't inherently incompatible with commercial use or even use in closed source software, one sticking point was that some of the platforms Unity wished to be able to deploy have developer/publisher restrictions that are incompatible with the soft copyleft terms in the LGPL that require that users (or in this case game developers) be allowed to relink against other versions of the covered software (including, for example, newer releases). Perversely, it's because Unity sought and obtained exemptions to the LGPL that both end users and game developers were hamstrung and kept from being able to upgrade Mono themselves! (It wouldn't have helped on, say, locked down platforms like Nintendo's for example, but certainly would have been viable on platforms without the first-party restrictions, like PC gaming or Android.)
By now, Unity has gone on to pull a lot of other shenanigans with their own pricing that seems to have sufficiently pissed off the game development community, but it should still not be forgotten when they were willing to pass the blame to an open source project over the development/support that the company felt it was entitled to for a price lower than they were told it would cost, and that they themselves were slow to make progress on even when the price of the exemption literally became $0.
* you can find threads with these sorts of comments from during this period right here on HN, too, but it was everywhere
> Unity uses the Mono framework to run C# programs and back in 2006 it was one of the only viable multi-platform implementations of .NET. Mono is also open-source, allowing Unity to do some tweaks to better suit game development. [...] An interesting twist happened nearly 10 years later.
Not mentioned is that Mono itself of course improved a lot over the years, and even prior to MS's about-face on open source, it was well known that Unity was hindered by sticking with an old and out-of-date Mono, and they were very successful at deflecting the blame for this by throwing the Mono folks under the bus. Any time complaints about game developers' inability to use newer C# features came up, Mono/Xamarin would invariably receive the ire* because Unity couldn't come to an agreement with them about their license and consulting fees. (Mono was open source under LGPL instead of MIT licensed at the time, and Unity had initially bought a commercial license that allowed them exemptions from even the soft copyleft provisions in the LGPL, but the exemption was limited and not, for example, for any and all future versions, too, indefinitely.) Reportedly, they were trying to charge too much (whatever that means) for Unity's attempts to upgrade to the modern versions.
It's now 10+ years later, and now not only Mono (after being relicensed under MIT) but .NET CoreCLR are both available for Unity at no cost, but despite this it still took Unity years before they'd upgraded their C# language support and to a slightly more modern runtime.
Something else to note: Although, LGPL isn't inherently incompatible with commercial use or even use in closed source software, one sticking point was that some of the platforms Unity wished to be able to deploy have developer/publisher restrictions that are incompatible with the soft copyleft terms in the LGPL that require that users (or in this case game developers) be allowed to relink against other versions of the covered software (including, for example, newer releases). Perversely, it's because Unity sought and obtained exemptions to the LGPL that both end users and game developers were hamstrung and kept from being able to upgrade Mono themselves! (It wouldn't have helped on, say, locked down platforms like Nintendo's for example, but certainly would have been viable on platforms without the first-party restrictions, like PC gaming or Android.)
By now, Unity has gone on to pull a lot of other shenanigans with their own pricing that seems to have sufficiently pissed off the game development community, but it should still not be forgotten when they were willing to pass the blame to an open source project over the development/support that the company felt it was entitled to for a price lower than they were told it would cost, and that they themselves were slow to make progress on even when the price of the exemption literally became $0.
* you can find threads with these sorts of comments from during this period right here on HN, too, but it was everywhere
> it was well known that Unity was hindered by sticking with an old and out-of-date Mono, and they were very successful at deflecting the blame
So much this. According to a 2023 blog article from Unity [0], Unity uses Boehm GC. But Mono itself introduced another, generational GC called SGen [1] more than 10 years ago that became the default at some point. It is just Unity stuck on old mono versions, missing out on all the changes and improvements that went into Mono after their fork, essentially.
[0]: https://unity.com/blog/engine-platform/porting-unity-to-core... [1]: https://www.mono-project.com/docs/advanced/garbage-collector...
So much this. According to a 2023 blog article from Unity [0], Unity uses Boehm GC. But Mono itself introduced another, generational GC called SGen [1] more than 10 years ago that became the default at some point. It is just Unity stuck on old mono versions, missing out on all the changes and improvements that went into Mono after their fork, essentially.
[0]: https://unity.com/blog/engine-platform/porting-unity-to-core... [1]: https://www.mono-project.com/docs/advanced/garbage-collector...
A sibling comment [1] remarks that they play games with raw pointers that are incompatible with the newer GC, so it's not "just" an older runtime that's biting them in the ass.
[1] - https://news.ycombinator.com/item?id=46415568
[1] - https://news.ycombinator.com/item?id=46415568
Not to mention the Hot Reload which comes out of the box.
Ah I wonder if this could've saved me countless hours of optimizing my VR game Rogue Stargun for the Quest 2, particularly the final battle in the game
It's cool to see detailed traces and flame graphs be used more often! A lot of different problems could be detected if they were available for pretty much any language, with enough details and tooling to be useful. Heh, I remember also using VisualVM for finding issues with a web app HTTP thread pool and later with the SQL queries being executed (and also the DB pooling solution).
I wonder why the author doesn't use IL2CPP and sticks to Mono. IL2CPP does produce much faster code, making Mono builds obsolete. This should be the very first step you do if you care at all about performance in Unity.
my main problem with Unity games is never the speed - it's the outrageous RAM usage
Wanted to chime in here with some thoughts/clarifications as I'm the Enginnering Manager of the VM team at Unity, aka the team that is leading the charge on .NET Modernization and the CoreCLR transition (and also owns IL2CPP). Also speaking here as myself and obviously not on behalf of the company.
First thing is that CoreCLR is _very_ much an active development effort and we're committed to the roadmap we presented at Unite, with at least a CoreCLR-backed Player (aka, what you "Build" when you build your game with Unity) being delivered as a technical preview around the 6.7 release timing. This would basically mean being able to select "CoreCLR" as a scripting backend option (similar to IL2CPP) and see some of the upside and benefit the author mentions here.
That said, Unity isn't a pure C# environment. As lots of people know, there is a robust native layer underlying a lot of the managed (C#) code operating a pseudo-ECS design (not literally DOTS/Entites but an engine architecture thing). This means that a lot of the load-bearing code Unity-the-engine is running every frame is notably _not_ C# code, but instead native code that is, in a lot of cases, already very fast. This means that for tight loops of certain systems in the engine, moving to modern .NET isn't going to carry an implict performance increase of those systems. Said differently, CoreCLR isn't a magic performance bullet for Unity. What we like to say though is that "CoreCLR will make C# code faster", so if your game (or general scripting architecture like the author brings up, with lots of "loose" C#) is very C# dependent, you _will_ see a lot of benefit.
One thing we starting to investigate is how much performance there is to gain in Unity-the-engine by migrating legacy native C++ code to C# backed by CoreCLR. C# code can be a lot more maintainable and I'd be lying if I said that we really need _every_ managed->native->managed jump we do in the engine, especially with the performance benefit CoreCLR gives us. There are additional things as well like getting intrinsic-backed (or JIT'd) SIMD code for any C# we write with apis like Span<T>, covering for plenty on places in native code where we aren't directly checking for processor arch at runtime or the compiler misses some optimization. This is especially relevant as we also move the editor to CoreCLR, and obviously want it to be as fast as possible, and represents some of the attendant benefits of really focusing on .NET modernization.
Regardless, CoreCLR is very much the future of Unity and we're all very excited about it and the progress we're making. The player in 6.7 is the first step and there are lots of other parts (like modern C# lang versions) that will be major boons to development writ large. I (personally, as a game developer) see a lot of awesome things possible downstream of the shift and am (again, selfishly) very excited about what's possible.
First thing is that CoreCLR is _very_ much an active development effort and we're committed to the roadmap we presented at Unite, with at least a CoreCLR-backed Player (aka, what you "Build" when you build your game with Unity) being delivered as a technical preview around the 6.7 release timing. This would basically mean being able to select "CoreCLR" as a scripting backend option (similar to IL2CPP) and see some of the upside and benefit the author mentions here.
That said, Unity isn't a pure C# environment. As lots of people know, there is a robust native layer underlying a lot of the managed (C#) code operating a pseudo-ECS design (not literally DOTS/Entites but an engine architecture thing). This means that a lot of the load-bearing code Unity-the-engine is running every frame is notably _not_ C# code, but instead native code that is, in a lot of cases, already very fast. This means that for tight loops of certain systems in the engine, moving to modern .NET isn't going to carry an implict performance increase of those systems. Said differently, CoreCLR isn't a magic performance bullet for Unity. What we like to say though is that "CoreCLR will make C# code faster", so if your game (or general scripting architecture like the author brings up, with lots of "loose" C#) is very C# dependent, you _will_ see a lot of benefit.
One thing we starting to investigate is how much performance there is to gain in Unity-the-engine by migrating legacy native C++ code to C# backed by CoreCLR. C# code can be a lot more maintainable and I'd be lying if I said that we really need _every_ managed->native->managed jump we do in the engine, especially with the performance benefit CoreCLR gives us. There are additional things as well like getting intrinsic-backed (or JIT'd) SIMD code for any C# we write with apis like Span<T>, covering for plenty on places in native code where we aren't directly checking for processor arch at runtime or the compiler misses some optimization. This is especially relevant as we also move the editor to CoreCLR, and obviously want it to be as fast as possible, and represents some of the attendant benefits of really focusing on .NET modernization.
Regardless, CoreCLR is very much the future of Unity and we're all very excited about it and the progress we're making. The player in 6.7 is the first step and there are lots of other parts (like modern C# lang versions) that will be major boons to development writ large. I (personally, as a game developer) see a lot of awesome things possible downstream of the shift and am (again, selfishly) very excited about what's possible.
Author here, thanks for your comment. I am glad to hear that things are progressing!
Can you share how large is the team responsible for .NET Modernization?
> migrating legacy native C++ code to C# backed by CoreCLR.
Yes please! Surely things like Quaternion.Lerp don't have to be C++ code under CoreCLR.
Feel free to get in touch in case I could be of any help :)
Can you share how large is the team responsible for .NET Modernization?
> migrating legacy native C++ code to C# backed by CoreCLR.
Yes please! Surely things like Quaternion.Lerp don't have to be C++ code under CoreCLR.
Feel free to get in touch in case I could be of any help :)
Inityx(1)
There are few things off with the this post that essentially sound as someone more green when it comes to Unity development (no problem, we all start somewhere).
1. The stated approach of separating the simulation and presentation layers isn't all that uncommon, in fact it was the primary way of achieving performance in the past (though, you usually used C++, not C#).
2. Most games don't ship on the mono backend, but instead on il2cpp (it's hard to gauge how feasible that'd be from this post as it lacks details).
3. In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC#, especially with what appears to be happening in the in sample here as the job system will help tremendously.
4. Profiling the editor is always a fools errand, it's so much slower than even a debug build for obvious reasons.
Long story short, Unity devs are excited for the mentioned update, but it's for accessing modern language features, not particularly for any performance gains. Also, I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime, or even sidestep entirely with unmanaged memory and DOTS.