Search Unity

  1. Check out our Unite Austin 2017 YouTube playlist to catch up on what you missed. More videos coming soon.
    Dismiss Notice
  2. Unity 2017.2 is now released.
    Dismiss Notice
  3. The Unity Gear Store is here to help you look great at your next meetup, user group or conference. With all new Unity apparel, stickers and more!
    Dismiss Notice
  4. Introducing the Unity Essentials Packs! Find out more.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice
  6. Unity 2017.3 beta is now available for download.
    Dismiss Notice

Mono Upgrade Future plans for the Mono runtime upgrade

Discussion in 'Experimental Scripting Previews' started by JoshPeterson, Apr 3, 2017.

  1. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    I don't think that we have enough data yet to encourage async/await over coroutines, but that may come in the future. Indeed, making class libraries that can be used across the .NET ecosystem is something that we want to enable though.

    As for System.Numerics, I think that we had some problems related to its implementation, although I don't recall all of the details of that thread.
     
    Dmitriy-Yukhanov and npatch like this.
  2. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    44
    You wrong

    Task and async/await is just a conceptual library to Tasking things. It just the default TaskRunner of dotnet library is threading. But you could always override that to single thread runner. You could even change TaskRunner to work under CoRoutine itself if you would like

    You don't understand that Task and CoRoutine is both screwdriver. It is the same and Task is actually more elaborate to the point that is was used in multithread

    If I would make analogy I could said that it is a new screwdriver that could drive multiple screws at the same time. And you just only see it drive 4 screws so you scare that it can only drive 4 screws and cannot drive 1 screw. But it actually can drive any number of screw so 1 is never be a problem
     
  3. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    44
    Nearly 2 months so I wish to ask this again
    Will I could be sure that .NET 4.6 will release with the 2017.1 ?
    I wish it would at least still being experimental flag in 2017.1. But please don't take it out from the actual release
     
  4. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    @Thaina

    Yes, Unity 2017.1 will have support for .NET 4.6, although it is still experimental. We're not planning to turn back now!
     
  5. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    44
    That's great! Now I will go 2017.1 for my project without turning back too
     
  6. j-borden

    j-borden

    Joined:
    Mar 3, 2015
    Posts:
    21
    Hi, checking in again! I downloaded and tried out the new runtime but I was frustrated to find out that it can only load other full .NET framework libraries. I think a few others have run into this problem but packages built based on .NET Standard are unable to be used with Unity3D because they move the responsibility of the runtime to a separate DLL that is not provided with the full profile (i.e. System.Runtime.dll)

    I was able to get things to work by moving all the needed DLLs into the plugins folder of a test project, however (including getting System.Runtime.dll off of Nuget) so if you are facing a similar issue this might help. Has anyone else found a more elegant solution? What I'd really like to do is use Nuget with Unity3D, but that doesn't seem to be easily allowed yet.
     
  7. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    @j-borden

    Indeed, I'm unaware of a better solution for this in Unity 2017.1. Our support for .NET 4.6 only works with the full .NET 4.6 profile (and there are a few missing types there as well). We're working now on support for .Net Standard 2.0, so that you will be able to use an assembly compiled against .Net Standard 2.0 or earlier, or an assembly compile against .NET 4.6. This isn't in a 2017.2 beta release yet, but we're hoping to make it before the 2017.2 release is out (although I can't promise that for sure).
     
  8. j-borden

    j-borden

    Joined:
    Mar 3, 2015
    Posts:
    21
    Thanks for replying so quickly! I'm really looking forward to that. In the meantime I wrote a blog post about what I did to make the library work (i.e. getting stuff manually off of Nuget, taking advantage of multi-framework targeting, moving it into the Unity project and compiling, etc). I can post it here if that's ok, as it might be informative for others, but if not that's fine too (it could be self promoting since it is the product that I work on)
     
  9. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    Go ahead and post it, it might help others!
     
  10. j-borden

    j-borden

    Joined:
    Mar 3, 2015
    Posts:
    21
    Here is the post!
     
  11. j-borden

    j-borden

    Joined:
    Mar 3, 2015
    Posts:
    21
    I'd like to point out some pain I had with this (not specific to Unity3D, but probably applicable). Once you await something, be aware that when you return you are not necessarily on the same thread anymore. In fact you are probably not. That means that if you depend on being on the Unity main thread you WILL find yourself off of it after the await. This is not a problem with Coroutines. By default, though, SynchronizationContext is completely worthless and this would need to be implemented inside of Unity3D itself using a consumer queue. There is no way to inject yourself back into a running thread without that thread knowing about that situation first.

    So don't think that async / await is some magic that will work automatically, it requires orchestration. See this thread for your fate.
     
    Ethan_VisualVocal likes this.
  12. ncgreco

    ncgreco

    Joined:
    Mar 1, 2016
    Posts:
    11
    I have to ask since this is on topic of the Mono Runtime. Is InternalCall open to Unity Game Developers to use to speed up native C++ libraries? Or is that something still exclusive to the Unity Engine?
     
  13. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    @ncgreco

    No, InternalCall into the runtime or the engine is not something we support. The API layer between the managed and native code in the runtime or the engine is constantly changing, and not something that we can keep stable.

    With that said, we do have some incredible technology coming that will allow you to right very fast code in C#. Check out this video from Unite Europe 2017 if you are interested:
     
    ncgreco and Alverik like this.
  14. ncgreco

    ncgreco

    Joined:
    Mar 1, 2016
    Posts:
    11
    Thanks, fantastic video!
     
  15. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    171
    @JoshPeterson
    Hey, quick questions:
    1) Ref returns - since they're in c# language version 7, unity won't support them for now, but I feel like that will change soon, right?
    2) What exactly are the performance implications here, specifically I have an scneario in mind:
    getting and modifying all particles in a particle system (right now you have to provide a list or array and unity will copy over all data into your array). That should be a lot more performant using ref-returns, right? Or is the native<>managed transition getting in the way here as usual? If so, what are potential places where ref-returns can really make a difference in Unity?
    3) What is the approximate time-table for supporting c#7 and higher?
    4) Will unity make 100% use of roslyn to compile code, ditching the mono compiler and only using mono for the runtime eventually? (or is that already the case maybe?)
     
  16. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    Yes, we're working on C# 7 language support now.

    Use ref returns should really help with allocation-free APIs. We will take it slow changing existing APIs so as not to break any working code, but our plan is to move more and more toward APIs that don't require GC interaction. Check out this talk from Unite Europe for much more detail about where we are going:


    I'm not sure about specific APIs, and we will still have some managed-to-native overhead, but C#7 will allow us to minimize that.

    I can't say yet. We're looking to get it out as soon as possible, so that we can start using ref returns in our API. So it is a high priority.

    We're not sure yet. The mcs compiler doesn't have C# 7 support now, but there is some being added. Roslyn is a good alternative, although in its normal batch compile mode it is significantly slower than mcs. However, Roslyn has a pretty awesome server mode where it keeps compiled versions of code that is unchanged in a cache. This makes it much faster than mcs in our tests.

    So I suspect we will use Roslyn, but C#7 support (however we can complete it) is the goal.
     
  17. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    171
    Thanks for the really quick answer.
    That talk was super awsome btw, I didn't expect that job system stuff to be that cool (auto-rewriting code?, no vtables?, ... wow!)

    Sounds like Unity is on a great path when it comes to performance.

    I don't suppose you guys have using this for scene load integration on your road map yet?
    The integrate step of SceneManager.LoadSceneAsync still produces really bad (20ms+) hickups quite often even when you have no MonoBehaviours and only unity internal stuff (Terrain, SkinnedMeshRenderer).

    Any plans using that new system to improve that?
    Since you seem to be working on compiler stuff mostly, you might be the wrong guy to ask for that; In that case, would you happen to know who should I talk to in regards to that?
     
  18. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    I'm unsure about scene load changes, sorry. I do know that we're working on jobifying a number of subsystems in Unity to improve performance, so I suspect that anything which is a bottle neck is on the table to be corrected.
     
    Ethan_VisualVocal and Alverik like this.
  19. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    736
    That seems far more useful than the 'Assembly Definition' stuff put in 2017.2/3.. far more useful and easier than trying to manually tidy up a project filled with third party stuff. It's just a mess to trying to work with assembly definitions imo... and looks like it will be in the future completely useless?.. the first time I tried it, the biggest problem is zero automation/helper tools in the editor to assist users see where things could tidied up without breaking the project.

    So that looks far more useful and what is needed for an automatic boost to things like iteratative script changes with zero dev effort or thought to messing with doing assembly def's just to try improve recompile times.
     
    Qbit86 likes this.
  20. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    171
    They said they'll cover doing the assembly definition stuff with an UI / Editor 100%. No manual fiddling around with json files. I think I even saw a screenshot somewhere already.

    Keeping a project clean is one thing. Sure it's important, but what's even more important is that you keep understanding your own project :p If your project organization is messed up, then sooner or later that'll bite you in the ass. And then faster compile times won't help you either.
    So the feature will not be useless in any case.

    However I agree, faster compile and reload times are really needed.
    I don't know how much faster the whole process will get though! Serialization and restarting (deserializing and instantiating the old stuff again) the CLR stuff take quite a bit of time as well I think, in addition to the raw compilation time.

    Anyone know what's the factor of that? Like how much % of the time is spent actually recompiling and how much is spent on serialization and instancing objects again?
     
  21. ArturSushkovPlaytika

    ArturSushkovPlaytika

    Joined:
    Oct 2, 2017
    Posts:
    1
    Are you going to support some Portable Class Library profiles alongside with .net Standard?
     
  22. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    No, we're not planning to support portable class library profiles. Our current plan is to support the full .NET 4.6 profile and the .NET Standard 2.0 profile.
     
    Overing, pateras, MV10 and 3 others like this.
  23. MV10

    MV10

    Joined:
    Nov 6, 2015
    Posts:
    1,870
    .NET Standard is the replacement for PCL...
     
  24. pateras

    pateras

    Joined:
    Jan 12, 2013
    Posts:
    49
    Why both? To ease an eventual transition away from 4.6?

    Also, supposedly .Net Core 2.0 has dramatically improved the performance of many APIs. I know Unity won't be built on Core, but given that Core is open source, is it being referenced to bring similar gains to Unity's .Net Standard 2.0 implementation?

    Thank you for the work that you're doing, and for maintaining good communication and transparency with the community!
     
  25. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    30
    for the same reason that now we have full 2.0 and subset, except .net standard apis are not chosen arbitrarily by unity

    namely, subset/standard have less API but has a smaller build size and should be aot friendlier

    full profile is if you have something that don't support standard
     
  26. MV10

    MV10

    Joined:
    Nov 6, 2015
    Posts:
    1,870
    Technically the Standard profile is meant to separate .NET from Windows-specific features, whereas the full (Framework) profile retails all those dependencies (GDI, certain approaches to crypto, etc)
     
  27. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,719
    As @M_R said, the .NET Standard 2.0 profile is nice for a smaller size, and it is easier to make the code work on AOT platforms. In general, we cannot support all of .NET 4.6 on all platforms. Much of that profile is just too Windows-centric or desktop-centric. That makes creating reusable code across all platforms Unity supports rather difficult.

    We can support the whole of .NET Standard across all of our platforms. So if you are writing platform-independent code for Unity, then .NET Standard will be the profile to target.

    We're planning to continue support for .NET 4.6 though for those users who need more than .NET Standard.

    Xamarin is pulling in much of the class library code open sourced by Microsoft to Mono. As Mono gets that code, Unity will also get it. I'm not familiar with specific performance gains, but in general, we like the idea of sharing more class library code so that we can get more consistent behavior.
     
    pateras likes this.