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

151–160 of 190 posts

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

#151

Post by eterm »

Rochus wrote: post #122
to11mtm wrote: post #22

Earlier quoted context omitted.

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

Can we reproduce your results for Mandelbrot?

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

#152

Post by dustbunny »

pjmlp wrote: post #102
dustbunny wrote: post #28

Earlier quoted context omitted.

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.

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.

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

#153

Post by Rohansi »

jayd16 wrote: post #83
Rohansi wrote: post #5

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

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

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

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

#154

Post by et1337 »

joha4270 wrote: post #150
et1337 wrote: post #142

Earlier quoted context omitted.

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

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.

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

#155

Post by mrsmrtss »

animal531 wrote: post #135
iliketrains wrote: post #54

Earlier quoted context omitted.

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

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

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

#156

Post by gr4vityWall »

Rohansi wrote: post #70
luaKmua wrote: post #59

Earlier quoted context omitted.

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…

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

I wonder what those benchmarks would look like with .NET 10 and an AVX512-capable CPU.

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

#157

Post by joha4270 »

et1337 wrote: post #154
joha4270 wrote: post #150

Earlier quoted context omitted.

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

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

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?

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

#158

Post by lossyalgo »

reactordev wrote: post #144
lossyalgo wrote: post #127

Earlier quoted context omitted.

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

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

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.

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

#159

Post by et1337 »

joha4270 wrote: post #157
et1337 wrote: post #154

Earlier quoted context omitted.

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

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

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.
Post reply on HN