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

111–120 of 190 posts

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

#111

Post by whstl »

ACS_Solver wrote: post #35
cheschire wrote: post #24

Earlier quoted context omitted.

Well they made some business decisions in the middle of that timeline that cut their funds quite a bit, not to mention probably scared off some good talent.

Not just probably scared off some good talent, they had xoofx leave over disagreements with higher management. xoofx was one of their most senior devs, the guy who started the CoreCLR migration and was leading it. They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev wh…

The funny thing about his resignation is that xoofx had a CoreCLR prototype already working around 2016-ish, but the company had "other priorities" and only took it seriously until recently.

The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight.

I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space who didn't do his job and will blame xoofx for “not fighting harder” or some other bullshit. Fuck companies, and fuck loser managers.

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

#112

Post by pjmlp »

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…

They did, hence Boo

https://en.wikipedia.org/wiki/Boo_(programming_language)

I would argue that C# has always been a good alternative for games, starting with Arena Wars, the problem was Microsoft not being serious about AOT or low level programming, because that was left for C++/CLI.

https://en.wikipedia.org/wiki/Arena_Wars

Here is the person responsible for pushing XNA, even though management wasn't into it.

"The billion dollar decision that launched XNA"

https://youtu.be/wJY8RhPHmUQ?si=_3pic4pEiOlqQzvm

When she left Microsoft, XNA was promptly replaced by DirectXTK, because C++ is the only true way for DirectX team,

https://walbourn.github.io/directxtk/

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

#113

Post by rincebrain »

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?

The article touches on it - assuming it's correct, it's because they did a bunch of proprietary modifying on Mono, so it's not "just" Mono any more, it's Mono and a decade or more of the most exciting layer violating crimes you can imagine.

I would assume, if someone Meta scale had an app that had to be built on Unity for whatever reason, we'd see similar blogposts to the ones they did about finding bespoke optimizations for their Android app to be performant with how enormous it became, probably involving either some bespoke alternative to IL2CPP, or writing a bunch of bespoke optimizations onto a bastard descendant of whatever version of Mono Unity originally derives from and so supports...or just paying Unity so much money they get to do whatever they want to the underlying source.

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

#114

Post by rincebrain »

littlecranky67 wrote: post #84
pwdisswordfishy wrote: post #36

The author (probably unknowingly) glosses over a lot in these sentences of the "How did we get here" section: > Unity uses the Mono framework to run C# programs and back in 2006 it was one of the only viable multi-platform implementations of .NET. Mono is also open-source, allowing Unity to do some tweaks to better suit game development. [...] An interesting twist happened nearly 10 years later. Not mentioned is that…

> it was well known that Unity was hindered by sticking with an old and out-of-date Mono, and they were very successful at deflecting the blame So much this. According to a 2023 blog article from Unity [0], Unity uses Boehm GC. But Mono itself introduced another, generational GC called SGen [1] more than 10 years ago that became the default at some point. It is just Unity stuck on old mono versions, missing out on al…

A sibling comment [1] remarks that they play games with raw pointers that are incompatible with the newer GC, so it's not "just" an older runtime that's biting them in the ass.

[1] - https://news.ycombinator.com/item?id=46415568

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

#115

Post by linguistics__ »

makotech221 wrote: post #2

Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out. Might I suggest https://github.com/stride3d/stride , which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.

> Yeah I think Unity just doesn't have the technical skillset anymore

It's not a technical skillset issue, it's a case of lacking resources, leadership changing priorities and changing requirements mid-development, causing a lot of work to be redone.

We still have highly skilled developers working in this area, if we can just actually be allowed to do (and keep) we work we have.

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

#116

Post by ACS_Solver »

whstl wrote: post #111
ACS_Solver wrote: post #35

Earlier quoted context omitted.

Not just probably scared off some good talent, they had xoofx leave over disagreements with higher management. xoofx was one of their most senior devs, the guy who started the CoreCLR migration and was leading it. They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev wh…

The funny thing about his resignation is that xoofx had a CoreCLR prototype already working around 2016-ish, but the company had "other priorities" and only took it seriously until recently. The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight. I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space…

I think 2016 is a bit too early but yeah, xoofx first wrote about CoreCLR in 2018 and said he'd made considerable progress with something like himself and two other engineers doing it as a side project. That is four years before Unity as a company announced the migration as a priority, which in turn is another four years before the current estimate for when they may ship it.

From my perspective, Unity seems very poorly managed in recent years. The editor experience isn't improving while they continue the usual pattern of shipping features in a poor state where they need another couple versions to become properly usable, and of course they make terrible decisions like the runtime fee, a total insanity that caused a huge loss of trust and boosted Godot development enormously.

Of course my perspective is biased by me not being Unity's main target market. I work on PC strategy games, which are on Steam. At our studio, we don't do mobile, advanced graphics features aren't very relevant, and we may have the most complex UI that ever shipped in a Unity game.

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

#117

Post by tyleo »

I wrote the Circuits programming system for Rec Room, and we took a similar approach: keeping the core logic free of Unity dependencies so it could run and be tested on CoreCLR.

The results were similar as well with significantly better performance outside of Unity. There are also secondary benefits. Unity’s API surface is huge, and it’s easy for code to accidentally entangle itself with engine details in ways that confuse or constrain other developers.

By isolating the core in a separate DLL, we only expose Unity concepts where they’re actually needed, and we enforce that boundary with tests. That logic constraint ended up being just as valuable as the performance gain

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

#118

Post by tyleo »

rincebrain wrote: post #113
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?

The article touches on it - assuming it's correct, it's because they did a bunch of proprietary modifying on Mono, so it's not "just" Mono any more, it's Mono and a decade or more of the most exciting layer violating crimes you can imagine. I would assume, if someone Meta scale had an app that had to be built on Unity for whatever reason, we'd see similar blogposts to the ones they did about finding bespoke optimizat…

I’ve heard (but don’t have an inside source) that Meta’s Horizon was built on Unity and then ported to a custom engine implementation.

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

#119

Post by reactordev »

whstl wrote: post #110
jayd16 wrote: post #43

Earlier quoted context omitted.

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

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

#120

Post by reactordev »

MindSpunk wrote: post #69
DiabloD3 wrote: post #40

Earlier quoted context omitted.

That last step is nonsensical: WebGPU is a shim layer that Vulkan-like layer (in the sense that WebGL is GLES-like) that allows you to use the native GPGPU-era APIs of your OS. On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases wher…

WebGPU is far from cheap and has to do a substantial amount of extra work to translate to the underlying API in a safe manner. It's not 1:1 with Vulkan and diverges in a few places. WebGPU uses automatic synchronization and must spend a decent amount of CPU time resolving barriers. You can't just ship a WebGPU implementation in the driver because the last-mile of getting the on screen is handled by the browser in ent…

We already do this by exposing the canvas surface with a semaphore lock. The browser can flip the surface to the canvas (or your app can flip it onto a window surface).

It’s just a HINSTANCE pointer.

You’re right about the waiting, but that’s entirely app driven. Browsers don’t want to render at 144fps but rather wait until drawing has occurred in order to update the view.

wgpu, dawn, already support drawing to arbitrary surfaces (not just a canvas but any window surface).

Post reply on HN