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

101–110 of 190 posts

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

#101

Post by pjmlp »

DiabloD3 wrote: post #52
reactordev wrote: post #47

Earlier quoted context omitted.

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…

And Web, because nowadays when people complain about standards, they mean something that only Chrome or Electron crap does.

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

#102

Post by pjmlp »

dustbunny wrote: post #28
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.

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.

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

#103

Post by pjmlp »

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.

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

#104

Post by pjmlp »

neonsunset wrote: post #77
MindSpunk wrote: post #74

Earlier quoted context omitted.

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.

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

#105

Post by enbugger »

dustbunny wrote: post #28
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.

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

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

#106

Post by torginus »

pjmlp wrote: post #100
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…

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

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

#108

Post by joha4270 »

dustbunny wrote: post #28
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.

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.

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

#109

Post by mort96 »

boguscoder wrote: post #25

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

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.

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

#110

Post by whstl »

jayd16 wrote: post #43
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…

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…

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.

Post reply on HN