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

131–140 of 190 posts

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

#131

Post by animal531 »

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…

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.

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

#132

Post by debugnik »

torginus wrote: post #106
pjmlp wrote: post #100

Earlier quoted context omitted.

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…

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

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

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

#133

Post by reactordev »

lossyalgo wrote: post #126
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-in…

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.

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

#134

Post by reactordev »

JBits wrote: post #85
reactordev wrote: post #48

Earlier quoted context omitted.

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.

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.

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

#135

Post by animal531 »

iliketrains wrote: post #54
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…

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…

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

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

#136

Post by WorldMaker »

DoctorOW wrote: post #124
Rohansi wrote: post #68

Earlier quoted context omitted.

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

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

#137

Post by WorldMaker »

bloomca wrote: post #128
CyanLite2 wrote: post #73

Earlier quoted context omitted.

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.

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

#138

Post by WorldMaker »

skrebbel wrote: post #98

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?

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.

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

#139

Post by whstl »

reactordev wrote: post #119
whstl wrote: post #110

Earlier quoted context omitted.

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

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.

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

#140

Post by yunnpp »

CodeCompost wrote: post #81
yunnpp wrote: post #53

Earlier quoted context omitted.

It's not AI, here's why: (yup, LLM-style pun intended) 1. Uses "I" 2. Look how many times it switches verb tenses here: "One day I was debugging an issue in map generation and it was time-consuming [...]. To make debugging faster, I’ve written a unit test, hoping to cut down on the turn-around time since Unity takes 15+ seconds just to crunch new DLLs [...]. When I ran the test, it finished in 40 seconds."

It's called a grammar mistake. People make them all the time, that's why editing is a job.

I'm not criticizing their mistakes. I'm saying you can tell the writing is human precisely because of them.
Post reply on HN