Search Unity

How improve jobs performace

Discussion in 'Data Oriented Technology Stack' started by dreamerflyer, Jan 21, 2018.

  1. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,476
    Without mono on the editor side, you have huge iterative workflow problems (way too slow compile times) and error checking becomes really hard.

    There are technical justifications though, you can't use burst and you have to copy memory back and forth without NA. I'd call them technical justifications that are 100% optional - you can always do your own threading, still.
     
  2. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    2,373
    We don't know that you will be able to do that, would be interesting to hear if we can, or if the new api's that allow concurrency will only be available when in a job context.

    Things like the burst compiler is actually a good example of something that is not a technical justification. There are a lot of use cases where you wouldn't care about that. Just because others haven't thought of those doesn't mean they are not there. And that is exactly the trap MS got itself into. It's why for example we can't tune the .NET GC for low latency workloads very well, because while internally it's possible they restrict access to the tuning knobs needed, because they never thought it would be useful.

    None of this is stuff people like myself can't work around. But this is the time to pick on design, so I'm picking.
     
  3. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,015
    With the focus on bust, it sounds like Unity is moving towards longer build time.
    I'm a fan of quick iteration cycles.
     
  4. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,671
    So am I. Our aim is to reduce iteration time. With burst we can do lots of caching on a per job basis, if none of the code in a single job has changed we can cache the compiled code.

    Overall we want iteration times to be reduced, starting with C# script compilation time, that is one of our focus areas right now.

    The burst compiler itself in the editor is running async, meaning we run the C# code via mono until the burst compilation completes at which point we hot swap the compiled burst job function in.
     
  5. X301

    X301

    Joined:
    Jan 24, 2013
    Posts:
    108
    Really good performance!!! I get 360+ fps using the Lightweight rendering pipeline. I have a i5 Surface pro 4 so I don't even have a graphics card.
     
    GameDevCouple_I likes this.
  6. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,015
    Brilliant! But that hot swap... do we get the typical post compile hiccup again?
     
    Last edited: Jan 28, 2018
  7. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    787
    Replacing a function pointer is like a hook.

    The hiccups you are talking about are related to unity serializing everything, not actual code compiling or reloading.
     
  8. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,015
    oh so background burst compile is followed by that function pointer swap? no hiccup is good.