Search Unity

  1. Are you interested in providing feedback directly to Unity teams? Sign up to become a member of Unity Pulse, our new product feedback and research community.
    Dismiss Notice

C#7 Support

Discussion in '2018.2 Beta' started by tarahugger, Jun 7, 2018.

  1. tarahugger

    tarahugger

    Joined:
    Jul 18, 2014
    Posts:
    129
  2. JJJohan

    JJJohan

    Joined:
    Mar 18, 2016
    Posts:
    214
    You could give the incremental compiler package a try. God knows why they put the thread for it in the ECS/Jobs sub-forum but it's completely separate.

    "Built using Microsoft's Roslyn open source compiler project, our new C# compiler is designed to dramatically accelerate iterating on your C# code as well as giving you access to the latest and greatest C# 7.2 features."

    https://forum.unity.com/threads/unity-incremental-c-compiler.523993/
     
  3. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,521
    In Unity 2018.3 Roslyn will be the default C# compiler for all platforms, and it will have support for C# 7.2.
     
    drcharris, Gru, optimise and 6 others like this.
  4. tarahugger

    tarahugger

    Joined:
    Jul 18, 2014
    Posts:
    129
    This makes me beyond ecstatic, keep up the great work :D
     
  5. interpol_kun

    interpol_kun

    Joined:
    Jul 28, 2016
    Posts:
    134
    That means there will be no Mono backend, right? Or there will be Mono with it's bad GC?
     
  6. buFFalo94

    buFFalo94

    Joined:
    Sep 14, 2015
    Posts:
    251
    Is a new Garage Collector finally rolled out?
     
  7. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    Compiler has almost nothing to do with the runtime.

    The old compiler was the "Mono C# Compiler". Now we'll get "Roslyn" (that new c# compiler, which by the way is also the thing at the core of the "Incremental Compiler" unity package). The compiler simply turns C# source code into MSIL assemblies (dll files).

    The "backend" / runtime will still be mono. Most new C# features don't require any changes to the runtime at all, thats why all those fancy new C# features still work. (Some of you guys also use IL2CPP as a backend, but that's something else again).

    The "api compatibility level" setting in unity only determines what assemblies are fed to the compiler (no matter what compiler that is) to enable some newer APIs.

    The garbage collector will still be the same old thing we had for years with no new thing coming in the forseeable future. It was mentioned once or twice that the guys at unity are looking into upgrading the GC to something more modern though. For example switching from the current mode (called "mark and sweep") to a newer one (called "generational").
    Generational is basically mark-and-sweep but it has 2 or 3 different pools, and objects that survive a garbage-collection will be promoted to a higher pool (think of it as pools named "objects that die quickly" and "objects that seem to be here to stay").
     
    Gru likes this.
  8. buFFalo94

    buFFalo94

    Joined:
    Sep 14, 2015
    Posts:
    251
    It's sad to see Unity not giving high priority to get a new GC.:(
     
  9. interpol_kun

    interpol_kun

    Joined:
    Jul 28, 2016
    Posts:
    134
    Because they are trying to move very heavy code to non-GC area with ECS, Jobs and Burst.

    Like there will be a lot of non-GC code with a small GC area. I think they are doing it right.
     
  10. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    They are giving it max priority already. There are TONS of things that have to be done before a switch to a newer GC is really possible though. It's one of the core components of the runtime that can't be easily messed around with.
    We know they have started internal tests with a different GC implementations, but there is still a lot of groundwork to be done. So don't worry, we're getting there.
    It's just not as easy as people think. It's not like you just drop in "BetterGC.dll", quite the opposite actually, lots of moving and interacting parts here...

    Getting a better GC is unavoidable though.
    The amount of time people have to spend to get rid of lags from the GC is enormous.
    There are many GDC talks on youtube of people talking about what work they went through just to make sure games don't lag on slower platforms (consoles or smartphones).

    Sure ECS will have the advantage of having explicitly managed memory, but not everyone can or wants to use them.
    Some games (like mine) can at most port a few auxiliary systems to ECS (and I did), but the majority of things are so complicated that it wouldn't be worth the effort, or sometimes its even entirely impossible (*).
    Also lets say your requirements change, you want to add a new feature, or you see that some feature needs to be changed, then scrapping all the work you invested + getting everything to work in ECS is more work than writing code the classic way (using MonoBehaviours on things) and then optimizing out some performance-critical sub system IF there's even need.

    My point is:
    ECS is awesome, and a much needed (for many use cases even essential) part of unity.
    But it is NOT a silver bullet that solves all your problems.
    It is another tool.
    One that has (exactly like every other tool in a developers toolbox) many many places where it is simply not useful.

    </rant> :p


    (*) Can't avoid string allocations by using ECS. Can't avoid allocations from serializers/deserializers unless they support it, and ECS is not help there.
    Can't avoid allocating state-machines from IEnumerator/Task, variables captured into lambda expressions, ...
     
    Last edited: Jun 10, 2018
    nirvanajie, Gru, Laicasaane and 3 others like this.
  11. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,521
    We are actively working now on better GC performance. We don't have anything ready to ship yet, but it is a priority for us. Our focus for GC is on preventing unexpected pauses that drop frame rate. I'm not sure yet what that means for which GC we will use, or what mode it will run in, but we are working on the problem.
     
    Gru, Laicasaane, SugoiDev and 9 others like this.
unityunity