Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

What if....? (Async programming >thread<)

Discussion in 'General Discussion' started by Roni92pl, Mar 27, 2019.

  1. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    261
    So you just shaved off 2ms off your game logic by spending few days optimizing your game's logic?

    So you wanted to have <enter unreasonable amount> of your super smart ai updating every frame using monoBehaviours, but frames tanked after you spawned 20 ais?

    So you finally managed to run 30% of your procedural content generation multithreaded?

    So is this a shameless ad for upcoming solution?

    So you have your super low-level optimized logic using frameworks and lot of systems, but you feel like you've written your own engine?

    So you're using ECS and miss Monobehaviours simplicity and object-oriented code design?

    Those are the problems. Those are the questions we need to ask.



    All those problems can be solved with changing the way you thinking of writing code.
    Unity accustomed/forced us so much to writing single threaded code, that for many people
    theading is like some kind of dark magic, so it's better not to touch it or that
    it should be used only for heavy math like mesh manipulation etc(that's baloney)

    So the idea is simple - to reverse this way of thinking - so I could write my code on my own thread
    by "default" and only when NECESSARY delegate Unity api calls to it's thread.
    Decouple logic from rendering, but not in coding context, but in threads context.
    Your logic frequency shouldn't be dependent on game framerate.
    This way you have full control over frequency of events, and you 'pay' nothing on main thread
    because you use it only for stricte Unity stuff like GetComponent and stuff(which you shouldn't do
    a lot anyway).

    But hey, it looks like someone from first world have serious problem with such approach, let's listen



    What do you think? ;)
    TBC....
     
    Last edited: Mar 27, 2019
  2. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,713
    Or you can just learn how to use ECS, which solves all these problems aside from the desperate clinging on to OOP.
     
    xVergilx, Lurking-Ninja and Ryiah like this.
  3. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    261
    I see. However ECS is not answer for everything. I for instance, and I guess hundreds of ppl in middle of project won't just scrape hundreds of thousands lines of code to write them in completely new way. It's also far from mature for serious use and will be for at least next few months.
     
  4. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    4,658
    Anything tied to input will need to run on the main render thread otherwise it will introduce input lag
     
  5. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,277
    You don't need to rewrite all of your code though. You just need to rewrite the heaviest portions. ECS is not intended to be a complete replacement for MonoBehaviour. It's intended to be used alongside it.
     
  6. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,713
    So your plan instead is for Unity to introduce what is essentially a THIRD coding paradigm?

    There is no universal solution, but ECS is the best one.
     
    Ryiah likes this.
  7. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    4,138
    What if I told you that I'm too tired today for the riddles?

    BTW, WTF are you talking about?
    Are you talking about rolling your own multi-threaded code based on C# threads? Congratulations, you just reinvented the wheel and started to race for the available threads with the Unity core engine. Good luck.
    It is not impossible to roll a robust multi-threaded solution but you will never have the same ease to schedule tasks inside Unity and also, the simplicity to burst (pun intended) your execution and have the simplicity of the Job system. Not to mention the extensive checks they perform.

    So what's your point exactly?
     
    xVergilx and Ryiah like this.
  8. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,431
    Isn't that exactly what you proposed in the OP?

    Extreme multi threading and ECS both require writing code in a completely new way.
     
    xVergilx, Lurking-Ninja and Ryiah like this.
  9. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,149
    I just looked at first image (then second), before even reading, and I knew, the OP post will be silly to begin with.

    Then don't. Problem solved.

    Depends how code was written in first place, conversion may involve anything from simple adaption, some update, restructuring, to rewriting whole parts of scripts.

    But anyway, most of us when been learning (and beyond), were rewriting things twice over at least at some point, when realizing, there are more suitable ways, to do same things.

    Smart person will justify and weight benefits and cost, of learning and implementing new paradigm.
     
  10. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    261
    [first post continuation]

    Ryiah made a great point.
    Because in real project you almost never just divide your code into two groups: one that needs to be super fast, and one that you don't really care for performance, right? It's not black or white. 90% of your code can still benefit from reducing time it takes on main thread, whether you use DOTS or not.
    And that's why I belive that despite ECS/DOTS greatness, there is still very much place and point to using async programming model today and in the future with Unity.

    Now, let's see what's this whole async programming idea and why it's so awesome:


    [^Timelines; rectangles are your methods/code execution blocks/'frames', however you call it]

    So what's happening there?
    Im simply moving target position for white box, and interpolate white box's position to it every frame;
    At first, I update target position @60hz, so basically every frame(not really because its done on other thread, but that's not the point here).
    Second(after first scene reset) I update target position @20hz. You see any difference? Me neither.
    Then finally after second scene reset, I update target position @5hz. Only at such low rate you can clearly see when target positions for interpolation changes.
    You see my point? It's that even with stuff related to rendering you don't need such high frequency for your logic.
    Almost every time you create MonoBehaviour with logic in it's update loop it's very wastefull usage of cpu time, even if you write super optimized code there.
    You always think how to make your code execute faster, and that's perfectly fine.
    But what's often forgotten is how many times per second you'll execute it? Because perf shouldn't be measured just by time your method takes to call. But you should take this time and multiply it by how many times it'll be called every second.
    Now sure, you can do simple timer in update loop and exit it early, but your update method will still be called every frame, and on main thread.
    Other great benefit of async programming is that your logic won't affect your framerate, and framerate is afterall main reason we optimize code. Even if you overload your logic thread, it still won't affect framerate(well of course as long as you won't saturate your all cpu resources with other threads lol).

    Sorry for huge post, but it's complex issue and cant be explained in two sencences, that's also reason for breaking it in a few posts.

    In the next post I'll be explaining a second meme(because it's not just for fun) and discuss with a little more details problems and solutions for async related issues. Cheers.
     
    Last edited: Apr 2, 2019
  11. Voronoi

    Voronoi

    Joined:
    Jul 2, 2012
    Posts:
    250
    InvokeRepeating? That's what I use for most logic that doesn't need to run at 60fps. If I spawn an army of AI, I just randomize the repeat rate to avoid spikes.
     
  12. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,713
    Yeah, this is... a really obvious solution. It's how I handle AI in high traffic racing situations.
     
  13. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,149
    You are aware that ECS can run code on separate threads right? And besides what guys said already, you can define parts of ECS systems, to execute at desired frequency.
     
    Kiwasi and xVergilx like this.