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

141–150 of 190 posts

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

#141

Post by WorldMaker »

to11mtm wrote: post #20
Rochus wrote: post #3

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…

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

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

#142

Post by et1337 »

joha4270 wrote: post #108
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.

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.

Performance is one issue with C#: https://sampruden.github.io/posts/godot-is-not-the-new-unity...

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

#143

Post by [deleted] »

torginus wrote: post #130
doctorpangloss wrote: post #123

Earlier quoted context omitted.

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…

[deleted]

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

#144

Post by reactordev »

lossyalgo wrote: post #127
reactordev wrote: post #121

Earlier quoted context omitted.

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

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

#145

Post by LeFantome »

Rochus wrote: post #3

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

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

#146

Post by dustbunny »

enbugger wrote: post #105
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.

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.

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

#147

Post by dustbunny »

atraac wrote: post #89
chris_wot wrote: post #38

Earlier quoted context omitted.

If you can code in C#, how is C++ difficult? Are pointers and the stl that difficult? Not denigrating, genuine question.

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

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.

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

#148

Post by reactordev »

whstl wrote: post #139
reactordev wrote: post #119

Earlier quoted context omitted.

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.

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.

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

#149

Post by Rohansi »

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?

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.

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

#150

Post by joha4270 »

et1337 wrote: post #142
joha4270 wrote: post #108

Earlier quoted context omitted.

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.

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

Post reply on HN