Porting the Unity Engine to .NET CoreCLR | Hacker News Reader

Porting the Unity Engine to .NET CoreCLR

xoofx.com

194 pointsbenaadams40 comments

CoreCLR will be nice for Unity with the 2x performance improvement.

I wish Microsoft had moved to it quicker and Unity wouldn't have had that lull on Mono 2.x .NET and had to build IL2CPP.

When IL2CPP was being rolled out it was quite impacting to build size and actually making iOS builds for a while in 2015 from like March to summer was not workable for months. Now they have Android on it and it works well but keeping all that up to date is cumbersome for a smaller tech/engine team.

I still would love a C++ engine/lib like they were going to do back when Apple was forcing AOT instead of JIT languages around 2010 [1], but having a C# engine that can be comparable in performance is killer.

As long as this update is smooth and is truly faster that would be welcome. It was harder to trust Microsoft before during the Mono/.NET disconnected period so Unity treaded carefully but after Microsoft bought Xamarin and went .NET standard/core it seems like they are embracing and not extinguishing. Microsoft's new focus is Azure and .NET core/standard help expand that as well as its use by Unity (always a C# champion) and even Unreal Engine possibly which some have attempted [2]. If Unity switches to .NET core/standard possibly Unreal Engine will be compelled to add it natively.

[1] https://blogs.unity3d.com/2010/07/02/unity-and-ios-4-0-updat...

[2] https://mono-ue.github.io/ or https://github.com/xiongfang/UnrealCS

They put up their editor source code on Github recently (https://github.com/Unity-Technologies/UnityCsReference), and originally it also included the full source to their runtime garbage collector, which ended up being the standard open source C++ boehm collector (https://github.com/ivmai/bdwgc) from the 90s.

Unity should replace it with a reference counting object management system, or update to a newer garbage collection technique to minimize the inadvertent sweeps that cause huge choppy frame rate drops.

They're planning both. Reference counting/bump pointer allocation in-frame for temp stuff & no GC & manual memory management for the upcoming high-performance restricted C# subset data-oriented jobs code, and for full-fat real C# code they're slowly working to clean up their (C++ coded) runtime so that a non-conservative garbage collector can work.

Re. Boehm, that was the garbage collector Mono shipped until they wrote SGen some years back.

I'm quite excited by the work they're doing on performance. It looks great.

I hope they don't use naive reference counting. It would reduce throughput and would not eliminate pauses. A standard incremental or concurrent generational tracing GC would be a better choice. In games you have a lot of knowledge about timing that you can use to help schedule GC: you always know (or should know anyway) how much time there is until the next VBLANK, so you can use that to bound pause times for your major collections.

Large parts of iOS and its ecosystem use automatic reference counting, and it has a reputation for the interface being noticeably smoother than Android, which uses Java's garbage collector.

Android doesn't use the HotSpot garbage collector.

That the divide existed at all is mind-blowing to me. In the middle of the deepest ebb in Microsoft's popularity with developers a group of people were like, "hey we love this tech so much we're going to reverse engineer and reimplement it ourselves from nothing."

And Microsoft was like, "cool, good luck with that."

They even handed out unit tests for the Moonlight team. It was certainly the start of the Microsoft renaissance, which is very strange considering it happened under Balmer.

"reverse engineer and reimplement it ourselves from nothing" :)

Fair enough.

Nothing as in $0. For a lot more than nothing in terms of personal satisfaction.

The other great thing about CoreCLR, though probably a bit niche, is it would allow other languages to be more easily used for Unity dev. F# for example, is part of dotnet core by default.

> is truly faster

With Mike Acton involved you can count on things getting truly faster, and not just because of .NET core.

Oh really? I'm suddenly interested, because the way he generally pushes things to work is the way I like them to work. I've always been uncomfortable with Unity's "pretend to be OO and pretend to be component based" approach, especially since they (IMO) excel at neither.

If Mike Acton is in charge, I'm going to start paying more attention to new developments there now.

Watching the talk at the bottom of the post, and I'm just at job scheduling. This already seems like a good move forward for Unity.

EDIT: Finished watching the talk. I'm floored. I figured there would be some changes but I didn't realize so much was already done to move to an ECS system. ECS fits the way I think better, performs well, and (IMO) lowers the content creation barriers for the kinds of games I like to make and play.

This is great news, as soon as I can download this, I'm in.

There are lots of other C# goodies and known devs joining Unity, there are other GDC 2018 talks with related content.

Also the C# 7.x low level improvements not only had feedback from previous experience on Singularity and Midori, they also got input from Unity's work on HPC#.

What low level improvements in C# 7 do you mean? Ref returns, etc? Anything besides syntactic sugar?

All ref and struct related improvements up to the upcoming 7.3.

The Span, Memory and related structures.

SIMD improvements.

As for syntax sugar, MSIL is expressive enough to fully support C++ semantics due to Managed C++ and C++/CLI, so it is quite nice if more such features get exposed at C# level, instead of forcing us to use C++/CLI.

Some of those like span are more of a library or jit features than language things.

There is still a lot to be done to match C++, in the meantime syntax is getting uglier and uglier (I prefer const& to ref readonly). That's the problem when performance is being surfaced into language so late. In my opinion they should focus much more on being able to create zerocost abstractions than they do now.

I'm waiting for a ref read-only that can be exploited for performance by jit. There are lots of things missing for performance like generics specialization or type classes. You have to go through box unbox inside typeof(T)==typeof(int) even though the type is fixed inside the if statement.

I hope that shapes proposal is going to be worked on, however I doubt it's going to happen any time soon.

I hope that c# and jit teams start working on harder things that will help c# dominate performance oriented software engineering in the future.

> Some of those like span are more of a library or jit features than language things.

Sure, C++ also has got its span and string_view as library.

> There is still a lot to be done to match C++, in the meantime syntax is getting uglier and uglier ...

Actually I find the opposite regarding syntax.

Don't forget C# has roots on the Pascal/Algol family of languages, even if it the syntax is C like.

For example Modula-3 also has the same REF and READONLY, just in caps. :)

Type classes, well kind of nice, not really into them, given interfaces.

Generics specialization is more a matter of improving the compilers (JIT/AOT).

Here .NET Native might be interesting given that it uses the same backend as Visual C++.

As for the rest, I never felt it was that slow and even with the current language semantics, Unity is quite confident that their new AOT compiler is able to take advantage of the HPC# subset (which still is 100% valid C#) to start moving C++ engine parts into C#.

Will regular .NET or .NET core be able to take advantage of HPC#?

No, it is a special AOT compiler (Burst) that is aware of Unity semantics and the C# subset.

https://www.youtube.com/playlist?list=PLX2vGYjWbI0S8ujCJKYT-...

The talk "C# Sharp to Machine Code" contains the details how it works, while the other ones explain all the Unity engine pieces that are being moved from C++ into HPC#.

.NET or .NET core benefit from this work, by the feedback Unity is giving back to Microsoft, as Miguel explained on his interview at Unity's booth.

Maybe these? https://github.com/dotnet/corefxlab/blob/master/docs/specs/s...

CoreCLR so far does not work on either Android or iOS AFAIK.

Correct, right now it's only Windows/Mac/Linux. That leaves the whole mobile & console platforms without it, so it's not like our IL2CPP stuff is "not needed anymore".

I wonder then if CoreRT will be able to play a role then.

Hey Aras you guys are doing a good job.

So I guess CoreCLR will cause more work for Unity engine teams in the interim.

IL2CPP is great right now and gets past all AOT issues as the initial pain is over. Ralph Hauwert and those guys did a good job. It also gets compilation AOT down to C++ so it cannot be messed with by Apple. But I guess CoreCLR will be another standard/lib to manage and suddenly the standard xkcd on standards becomes relevant [1].

I can still dream of Unity Plan B from 2010 though with a fully C++ API that mimics the C# one.

[1] https://xkcd.com/927/

IL2CPP had to be built anyway because of Apple's rules about interpreters in iOS apps. Unity can't just ignore that platform.

Xamarin ships for iOS. It does AOT compilation from CIL to native.

That's what Unity did before IL2CPP as well (not surprising of course since it was Mono). I think they didn't want to have to keep writing new native code generators for the AOT process for different architectures, which is why they went the IL2CPP route. That way they can generate the C++ code without worrying about what platform it's going to be running on and also take advantage of the C++ compiler's optimiser.

IL2CPP will still be needed for IOS as far as I know.

IL2CPP is going to stay for sure, but imo, it should be reserved to platforms where we don't have a more efficient way of having GC aware codegen (because it has not been ported yet, typically for a new platform).

CoreRT could perfectly work at some point on iOS, and more efficiently than IL2CPP. But this will require lots of work, so indeed, this is not going to happen anytime soon, maybe never, but we should be aware of all the options and why they each matter.

Also game consoles and Web Assembly.

> But also, you will notice lots of work related to ARM32 and ARM64, including corporate work from Samsung for the Tizen platform

It's nice to see this recognized. Source: I worked on open source at Samsung.

Hopefully I can use some of the postmarketOS work to run Tizen on some more devices. The ghost of the Nokia N900 lives on!

Actual Tizen has nothing to do with Nokia N900 spirit, other than using a Linux kernel.

I wonder if Unity regrets using Mono / C# as their scripting language, it seems like they have so many workarounds and hoops that they jump through that it must be a nightmare to maintain.

Not at all, actually they are doubling down on C#.

Developed a new compiler for a subset of C# that they call High Performance C#, and are porting engine code from C++ to HPC#.

Unity was also one of the contributors to the new C# 7.x safer low level programming features.

Lots of GDC 2018 talks about how it all works.

I've tried many languages for the last 35 years and C# is, at least of the C-style OO-focused languages, one of the nicer ones if not the nicest one. Microsoft has been doing very nice things with it the last several years, especially.

I, for one, am very happy with C# in Unity. I would still prefer a LISP (Arcadia/Clojure comes to mind) as a first class citizen, and support for a truly functional language (such as F#) would be nice, but I can live with C#, especially with the more-functional C#6 and .NET 4.6/.7 support in the latest Unity versions.

If Unity supported CoreCLR and all CLR languages natively, as well as NuGet, along with Rider (or VS/VSCode) it would be a near-perfect development environment for games, IMO. Not necessarily for everyone and everything, but enough to be good for many things and many people, including amateurs and learners.

I don't think so. The tooling and mindshare one gets with C# should be tremendously valuable. There are not that many options for performant languages which provide all the things C# ecosystem provides out of the box.

I don't think they had any better options available to them at the time. Embedding and integration for an engine like Unity is just a tremendous challenge no matter what stack you use. I've done this sort of integration w/ various languages (python, lua, vbscript, c#, actionscript, javascript, etc) and C# is one of the most reasonable choices, if only because it was designed with native interop scenarios in mind. There are pointers, there are structs, etc.

Also keep in mind Unity did offer multiple scripting solutions - they had Boo for a while (eventually dropped), and there's UnityScript, though I'm not super familiar with how it works... C# is the one that won.

Wasn't UnityScript just Unity-flavoured JS, like ActionScript was for Flash?

Reply on news.ycombinator.com