Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice

Official Blog post: Porting Unity to CoreCLR

Discussion in 'Experimental Scripting Previews' started by JoshPeterson, Oct 23, 2023.

  1. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    My team and I are still hard at work bringing the latest .NET technology to Unity users. As one person leading this effort, I’m excited to share further progress with you. Part of our work involves making existing Unity code work with the .NET CoreCLR JIT runtime, including a highly performant, more advanced, and more efficient garbage collector (GC).

    A new blog post – published today – covers recent changes we’ve made to allow the CoreCLR GC to work hand in hand with Unity engine native code. Read it here, then please use this thread for discussion of the blog or to ask me questions.
     
    Last edited by a moderator: Oct 24, 2023
  2. boyaregames

    boyaregames

    Joined:
    Jun 23, 2021
    Posts:
    75
    Wish you all the best!!!
    Just one question 2024 or later? :D
     
  3. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Sorry, we're not ready to announce publicly when this will ship.
     
  4. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    1,235
    I am a big fan of these kinds of blog posts. That leaves me torn, though, between wanting to see more posts and wanting the focus to stay on the actual task. Either way. Keep at it, can't wait to see the end result.
     
  5. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    I'm a manager supporting the some of the teams involved in this work - I'm not actually committing code directly for it, most of the time. So the time taken for me to write the blog post is not really taking away focus from the work here, no worries!
     
    mariandev likes this.
  6. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    614
    Amazing blogpost, code landia really crystalized the concept! 2 questions come to mind:

    - Have you already determined every place the code would need to be updated or are you still finding sources of native memory "leaks" as you are progressing? This ties into my next question:

    - May I ask how much code is left? 25%, 50%, 75%? Of course, not all code is created equal and it is understandable that being 80% done doesn't mean the remaining 20% will take 1/4th the time (like a progress bar that hangs). Still, it would be great to get this insight.
     
  7. Trigve

    Trigve

    Joined:
    Mar 17, 2013
    Posts:
    139
    I have some question about
    GCHandle
    performance. In one of my project I've used C++ as "scripting" language and I was using
    GCHandle
    along with
    shared_ptr
    to reference unity managed instances. Back then I was testing (and also reading lot of stuff around interop) and found that at least if you don't use pinned
    GCHandle
    , then the performance was good (In my case, using it also with custom non-mt
    shared_ptr
    , the only bottleneck is alloc and dealloc; I wasn't allocating a lot of managed objects per frame, to be honest). So I'm interesting in what situation you encountered the GCHandle performance problems?
     
  8. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    I think that we have found everything now. Since some of the causes are only detectable at run time, I'm sure their are some we have missed, but we've found thousands of places where were know native code is accessing managed memory in ways we want to avoid.

    I think we have addressed about 95% of the code we know about. Of course that last 5% has some difficult cases, as you suggest. Although we did try to prioritize working on the most difficult cases at the start, to prove that we actually could do this, so many of those were handled about a year ago.

    I want to be careful to not imply that we are 95% done with all of the work to ship the CoreCLR runtime with Unity, by the way. GC safety is one aspect of this work, but there are others.
     
  9. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    The performance issues we have seen with GCHandle objects revolves mostly around creation and freeing those objects. The CoreCLR runtime is really quick to access the managed object from a GCHandle (the cost is the same as a pointer deference in C), so there is really no overhead once the GCHandle object is created.

    Techniques like GCHandle pooling can help performance in places where you must create and free them often, but we're generally working to avoid that as much as possible.

    You are current that pinned GCHandle objects have a larger performance hit, because they place more constraints on the GC.
     
  10. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    614
    Still, 95% must feel pretty good to say out loud :D

    Good luck with the remaining 5% to you and the rest of the team!
     
    mahduum, Kabinet13 and JesOb like this.
  11. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    374
    Nice write up thanks Josh. When you do make the more to CoreCLR will it generally be straight to .NET 8+ and all of its libs or are there yet more large stepping stones under the water to navigate?
     
    JesOb likes this.
  12. Kabinet13

    Kabinet13

    Joined:
    Jun 13, 2019
    Posts:
    118
    Nice! Love the blogpost. I had a bit of a clarifying question with AssemblyLoadContext in the editor. As I understand it, all C# code, including say HDRP and UI toolkit for example (Which is used all across the editor at this point) needs to be reinitialized on each domain reload. If with AssemblyLoadContext, they don't need to be reloaded, they don't have to get reinitialized each time, right? As it stands there is an aditional 2-3 second wait after each domain reload for tasks like repainting the inspector, would that theoretically go away with CoreCLR?
     
  13. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,696
    Great set of info. That was an insightful blog entry to read!
    Makes one excited for the future of Unity (even if I haven't run into GC related problems that much myself).
     
    JoshPeterson and adamgolden like this.
  14. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Yes, we're looking to support .NET 8 now, including all of the base class libraries. There are many libraries out there in the .NET ecosystem, too many to test in fact, so we cannot guarantee support for all of them. But our goal is to make Unity more and more like a "normal" .NET application so that if can interact well with the rest of the .NET ecosystem.
     
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Yes! I don't have exact numbers yet, as we are still working on the implementation. But the idea is to have multiple assembly load contexts, to allow the Unity editor to only unload and reinitialize the code that actually changes. Some of our early tests here should tremendous promise to lower the cost of iteration time in the editor due to code changes. This is one of our primary goals of this entire development effort!
     
  16. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    586
    Does that include managed threads in WebGL?
     
  17. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    That is part of the goal, yes. But it is also orthogonal to some of the other work to ship CoreCLR work, and is proceeding separately. So we may ship managed threads in WebGL without CoreCLR support, or CoreCLR support without managed threads in WebGL, depending on the timing of both.
     
  18. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    614
    Maybe I’m dumb but isn’t that the same thing?
     
  19. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    There is a good bit of complexity for the "WebGL" platform related to managed threads and the garbage collector. The way Unity currently uses the Boehm GC requires the platform allow all threads to be paused and all call stacks to be walked via some kind of API. WebGL does not provide these APIs, so Unity has historically work around that restriction by limiting managed code to the main thread for WebGL. Then the engine can be sure of times when it is safe to allow the GC to run (e.g. before each frame, as there is no managed code executing).

    Many of the change described in this blog post allow the engine code to be more cooperative with the GC, meaning we can start to lift some of the platform restrictions which make multi-threaded managed code on WebGL difficult. So the CoreCLR GC work is a bit of a prerequisite for multi-threaded managed code on WebGL.

    But at the same time, WebGL uses IL2CPP only, and since that is entirely Unity's .NET runtime, we have the ability to modify it some to work better with WebGL, even without the engine code being fully cooperative with the GC.

    So there are multiple ways we can implement multi-threaded managed code for WebGL, and and I'm sure yet which of them will be ready for production first.
     
  20. Kabinet13

    Kabinet13

    Joined:
    Jun 13, 2019
    Posts:
    118
    Great news! I'm even more excited now. Aside from GC work, what else is there left to do? Are you still planning on releasing the player and editor separately? Sorry if I'm being too prying, I understand if you can't really answer these questions. Just keep up the good work.
     
  21. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Unfortunately I cannot answer all of those questions yet. We have options about how and when to release various parts of this. There are plenty of discussions happening about what the best way to do that is. I can say that we are not yet done either with GC work or with the other smaller, but important parts of CoreCLR integration just yet.

    So we will continue to work on both the implementation and the release plan. I'll share details when I can.
     
  22. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    586
    That's great to hear that managed threads in WebGL is being worked on! I was beginning to think that the WebGL platform was abandoned.

    Are there any blog posts about it or planned in the future? I'd love to know more about it in a technical deep dive.
     
  23. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    I don't know about any blog posts planned for WebGL, sorry. My team is not directly involved in that effort.
     
  24. Gamma_Snaplight

    Gamma_Snaplight

    Joined:
    Nov 23, 2022
    Posts:
    8
    Hi. As I understand it, we will get a good performance boost both in the editor and runtime in games?
     
    Zarbuz likes this.
  25. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Yes, managed code is significantly faster with CoreCLR in our tests. We also are seeing better GC performance.
     
  26. jiraphatK

    jiraphatK

    Joined:
    Sep 29, 2018
    Posts:
    296
    How about the crossing boundary cost?
    the example would be
    transform.position
    does this change also make this scenario faster?
     
  27. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    We've found so far that code which crossed the native/managed boundary is not faster with CoreCLR, but is also not slower than Mono, which is really great! For the past year or so, we have been focused almost entirely on making the code safe for the CoreCLR GC, knowing that we are introducing performance degradation in some places, most likely when code crosses this boundary (as discussed in the blog post). So the fact that we have mostly accomplished this part of the task, while still maintaining performance parity with Mono, is pretty cool.

    Going forward then, we will pick all of the low hanging fruit to improve the performance of the CoreCLR code, and we expect that overall we will see significant performance improvement over Mono.
     
  28. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    614
    Pray tell what the low hanging fruit looks like, I'm very curious!

    Once you have some numbers I would also like to see a direct comparison with IL2CPP. It would be a huge deal for build times if it stacks up to IL2CPP.
     
  29. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    We don't know about it all yet, but I'm planning for that to be another blog post!
     
  30. supersgf

    supersgf

    Joined:
    May 25, 2021
    Posts:
    3
    Based on the current progress, it is conservatively estimated that CoreClr will be officially released in 2026 or 2028.
     
    Thygrrr and Rennan24 like this.
  31. TheCelt

    TheCelt

    Joined:
    Feb 27, 2013
    Posts:
    741
    Would love more regular blog updates - its interesting to read these technical explanations of whats going on.
     
    jowseyy likes this.
  32. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Thanks! We are trying to work on more technical blog posts. Note that there is a new experiment over on Unity Discussions where we are also trying to post more technical content: https://discussions.unity.com/c/technical-articles/23

    My team does not have anything there yet, but we are hoping to get technical details there more often than we can on the blog.
     
  33. TheCelt

    TheCelt

    Joined:
    Feb 27, 2013
    Posts:
    741
    It's kinda silly to have 3 places to read this stuff though. Forums, discussions and blogs. Hope you can relay that to someone at Unity....pick a single platform and stick to it. I don't understand why Unity keeps spreading things out across different platforms...it's bad enough we have two documentation types out there we don't want news and information to also be scattered everywhere too.
     
    MaskedMouse, AllocTFP, Trigve and 2 others like this.
  34. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    I'll take this back to the community team, thank you!
     
    Harry-Wells likes this.
  35. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    374
    Wait what the hell is this haha. I had no idea that site existed. How does literally anyone find their way there?
    I'm all for hearing more from your team but if it goes into that black hole I doubt anyone will find it.
     
    AllocTFP, ProtoTerminator and bdovaz like this.
  36. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,331
    Unity Discussions is, for now, a replacement for Answers. So you find your way there because you try to open an old link to Answers and it forwards you to Discussions.

    As for why there's technical articles there, well...
    Look, the blog was at some point taken over by the marketing team, or the people in the marketing team got replaced, or whatever - I'm just seeing this from the outside. Anyway, what seems to have happened is that there's an enormous amount of red tape to go through to publish something on the Blog that's not pure marketing. The marketing articles, on the other hand - articles that's named "5 ways to fix your problem" that's just 5 adds for Unity services - gets posted all the time. They're worthless drivel, and Unity's marketing team keeps taking major dumps on Unity's brand by posting them on the front page. So that's sad and all, but that's the situation we're in now.

    So, there's people internally in Unity that wants to post interesting technical articles at a faster pace than what they're allowed to by the blog owners. So that means a new place that those articles can be posted. Unity Discussions is under active development, so it seems like putting the articles there was both a way to bypass the blog, and a way to boost adoption of Discussions. It's kinda a tragedy that it can't just be blog posts, but large corporations contain so much politics that I'm not surprised that things like the blog post this thread is about are islands of competence in an ocean of crap.
     
  37. joan_stark

    joan_stark

    Joined:
    Jul 24, 2018
    Posts:
    43
    Honestly, all this is nice to see, and I can see that Unity is doing great steps to improving and renovating Unity as a whole. It makes me happy and gives me hope.

    But I think this comes late. It's 2023 and we are still wating at least 1.5 years. Core CLR should have been released by now.

    Keep it up.
     
  38. TheCelt

    TheCelt

    Joined:
    Feb 27, 2013
    Posts:
    741
    I suspect it will take at least another 2 years from now. I don't know why they couldn't give an educated guess on timelines so we can decide if we want to begin projects on latest versions now or whether it wouldn't be worth it.
     
  39. akeit

    akeit

    Joined:
    Apr 28, 2021
    Posts:
    9
    The current IL2CPP full generic sharing is great, but it uses something like
    Code (CSharp):
    1. stackalloc byte [sizeof(T)]
    for all types that can contain references.
    This seems impossible with CoreCLR GC, is there any hope of making it possible??
     
  40. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    We've not looked too much yet at getting IL2CPP to work with the CoreCLR GC - our focus has mostly been on the Unity Engine and Editor code. But this is certainly something we plan to do in the future.
     
  41. akeit

    akeit

    Joined:
    Apr 28, 2021
    Posts:
    9
    Thank you very much! My current understanding is that C# to IL optimization is the main impact on IL2CPP, okay?Intrinsics support and reversal of type handle and header placement will be done?
     
  42. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    Sorry, I'm not sure what you mean with these questions. Can you elaborate a bit more?
     
  43. akeit

    akeit

    Joined:
    Apr 28, 2021
    Posts:
    9
    Sorry for the lack of clarity.
    The first is whether System.Runtime.Intrinsics can be used with IL2CPP.
    The second is that the current order of object headers and typehandles in mono and il2cpp is the opposite of it in coreCLR, so if mono is replaced by coreCLR, is it correct to say that the order will change in il2cpp as well?
     
  44. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    586
    That's an implementation detail of the runtime, so why does it matter? Are you relying on those details for some reason?
     
  45. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    No worries, thanks for clarifying!

    Yes, IL2CPP will support the same intrinsics as CoreCLR. Burst will as well.

    Yes the order will change. But as @ProtoTerminator mentioned, please don't depend on that! This is definitely something that can change without warning in the future.
     
    akeit likes this.
  46. forestrf

    forestrf

    Joined:
    Aug 28, 2010
    Posts:
    230
    If or when the CoreCLR release happens, will it be for PC only (and maybe some other platforms) or will we need to wait until all platforms can use CoreCLR? the amount of performance it could bring makes me want this a lot and I wouldn't want to wait for all platforms to support it before it can be used.

    Thank you!
     
  47. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,926
    We expect to support CoreCLR as the VM used in the Unity Editor, so that will be on Windows, macOS, and Linux. We also expect to support it in the Standalone Player builds for Windows, macOS, and Linux.

    We will also support the .NET 8 base class libraries on all platforms, including mobiles and console, but those will continue to use IL2CPP as the VM.

    Going forward, we will continue to watch the progress in the .NET ecosystem for CoreCLR and NativeAOT, and integrate them into Unity as we can.
     
  48. Tuncle

    Tuncle

    Joined:
    Oct 1, 2018
    Posts:
    22
    Will AssemblyLoadContext be supported on the mobiles platform?

    i am not sure the supporting for AssemblyLoadContext depends on CoreCLR VM or on the base class libraries.
     
  49. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    614
    2956A270-F993-4EC8-B4B2-8AE678FCA4D7.jpeg

    It has excellent documentation, you should be able to find this information yourself.
     
  50. Tuncle

    Tuncle

    Joined:
    Oct 1, 2018
    Posts:
    22
    Thanks for the information, and I have check the documentation. So the answer will be "The mobile platform support assemblyloadcontext, the implementation of vm doest not matter", right?

    Under my understanding, the unity application will be like a .net application, rather than being a .net application. so i am still not 100% sure about the answer.