Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unity's Mono problem: C# code runs slower than it should

marekfiser.com

Post reply on HN
Print view View original

121–130 of 190 posts

Re: Unity's Mono problem: C# code runs slower than it should

#121

Post by reactordev »

Rohansi wrote: post #96
reactordev wrote: post #31

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 endin…

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

Yes, the last 8 years has seen that little side drawer used for every. single. unity. feature.

Re: Unity's Mono problem: C# code runs slower than it should

#122

Post by Rochus »

to11mtm wrote: post #22
eterm wrote: post #14

Earlier quoted context omitted.

What's going on with the Mandelbrot result in that post? 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.

Re: Unity's Mono problem: C# code runs slower than it should

#123

Post by doctorpangloss »

torginus wrote: post #88
luaKmua wrote: post #46

In general when game development comes up here I tend not to engage as professional gamedev is so different than what other people tend to deal with that it's hard to even get on the same page, but seeing as how this one is very directly dealing with my expertise I'll chime in. 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 a…

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…

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.

Re: Unity's Mono problem: C# code runs slower than it should

#124

Post by DoctorOW »

Rohansi wrote: post #68
LeFantome wrote: post #57

Earlier quoted context omitted.

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?

Re: Unity's Mono problem: C# code runs slower than it should

#125

Post by MindSpunk »

pjmlp wrote: post #103
MindSpunk wrote: post #71

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…

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.

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.

Re: Unity's Mono problem: C# code runs slower than it should

#126

Post by lossyalgo »

reactordev wrote: post #31

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 endin…

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.

Re: Unity's Mono problem: C# code runs slower than it should

#127

Post by lossyalgo »

reactordev wrote: post #121
Rohansi wrote: post #96

Earlier quoted context omitted.

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

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

Re: Unity's Mono problem: C# code runs slower than it should

#128

Post by bloomca »

CyanLite2 wrote: post #73
999900000999 wrote: post #7

Earlier quoted context omitted.

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.

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?

Re: Unity's Mono problem: C# code runs slower than it should

#129

Post by KronisLV »

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

Re: Unity's Mono problem: C# code runs slower than it should

#130

Post by torginus »

doctorpangloss wrote: post #123
torginus wrote: post #88

Earlier quoted context omitted.

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…

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…

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.

Post reply on HN