Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
New Forum User Notice Update to the Unity Editor Software Terms

Question Noob Question: Simple Loop for 100x100 Grid vs Job worth the effort?

Discussion in 'Entity Component System' started by jGate99, Aug 20, 2022.

  1. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    1,847
    Hi there,

    I read in past that using jobs has overhead
    so my question is what about now? for a loop that goes through every cell of a 100x100 grid what should i do? A job or simple old style loop that we are used to?

    Please advise
     
    jGate99, Aug 20, 2022
    #1

  2. apkdev

    apkdev

    Joined:
    Dec 12, 2015
    Posts:
    263
    It somewhat depends on what you're doing in the job, but since you're processing 10000 elements it does sound like jobs would be worth it.

    The job overhead only really becomes an issue when you're scheduling hundreds of jobs. You won't notice any overhead when scheduling a single job that processes a large amount of data. (Obviously, you shouldn't be scheduling a separate job for each grid element, that's not correct usage.)
     
    apkdev, Aug 20, 2022
    #2
    jGate99 likes this.

  3. Per-Morten

    Per-Morten

    Joined:
    Aug 23, 2019
    Posts:
    109
    Whether you should use jobs depends on how much work you're doing per cell in the grid, and also how parallelizable your problem is. What you can do is write your implementation in a job first, then try to measure the difference between scheduling the jobs or just running it in the main thread using .run(). But I would think that the overhead is negliable.
     
    Per-Morten, Aug 20, 2022
    #3
    jGate99 likes this.

  4. Krajca

    Krajca

    Joined:
    May 6, 2014
    Posts:
    347
    If you can use a job - always use a job. Even Run() it if you need it now but a job gives you easy access to Burst so it means a possible performance boost even on the main thread.
     
    Krajca, Aug 20, 2022
    #4
    jGate99 likes this.

  5. elliotc-unity

    elliotc-unity

    Unity Technologies

    Joined:
    Nov 5, 2015
    Posts:
    228
    You can burst static functions on the main thread also, so that shouldn't be a consideration speed-wise. Job overhead pre-22.2/entities 1.0 varies with many things including core count, how many jobs you've scheduled, and how many jobs are running for how long in the rest of the system, so it's best just to try it both ways and see.

    It is frequently not negligible, unfortunately, in 22.1 and earlier, which is why we spent many months rejiggering it for 22.2 and entities 1.0. In the new version it's not _always_ negligible, but it gets a lot closer.
     
    elliotc-unity, Aug 20, 2022
    #5
    Elapotp, charleshendry, Occuros and 7 others like this.

  6. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    1,847
    Thank you everyone for their replies,

    It will always remain single job without any parrall use case as its more like a "fit rect algorithm" but using tetris shapes.

    @elliotc-unity
    I'm using Unity 2022.2 beta so if understand correctly i should be using a job? (rather than burst static function)
     
    jGate99, Aug 20, 2022
    #6

  7. apkdev

    apkdev

    Joined:
    Dec 12, 2015
    Posts:
    263
    By default, you should use jobs for everything unless you hit some specific edge case where function pointers are necessary for some reason. Burst-compiled static functions are quite cumbersome right now, the jobs API is much better supported. There's also some performance reasons according to the Burst docs.
    https://docs.unity3d.com/Packages/c...tion-pointers.html#performance-considerations
     
    apkdev, Aug 20, 2022
    #7
    jGate99 and Krajca like this.

  8. elliotc-unity

    elliotc-unity

    Unity Technologies

    Joined:
    Nov 5, 2015
    Posts:
    228
    @jGate99 [edit: didn't notice the part about it being a single job and not a parallel for] If it's a single job, I'd think the job should almost always be better than or equal to the bursted static function in 22.2+.

    @apkdev Ah, that is not correct for 22.2+ NativeArray. DisposeSentinel has been removed from NativeArray in 22.2: https://github.com/Unity-Technologi...2.2/Runtime/Export/NativeArray/NativeArray.cs , and we're doing the same with all the other nativecontainers in the upcoming collections release (2.0 I think?), so none of these things will be managed types anymore. (You still get leak checking, but without as much of the overhead or unburstability of the managed types.) I suppose we should update that doc.

    It's true that burst can guarantee more things about aliasing with jobs by default than with straight static functions; the basic thing that would happen is that it would theoretically vectorize some code in a job that it couldn't vectorize in a static function. You could check this in a burst inspector if you were worried about it. I also think that if one correctly sprinkles [NoAlias] in the right places one can get a similar effect with static functions, but I haven't tried myself.

    Finally, note that recent burst versions are able to patch calls to bursted static functions directly, so you don't need to monkey around with function pointers in order to enjoy them anymore. Just put [BurstCompile] on the enclosing type and the static method, and it's pedal to the metal.
     
    elliotc-unity, Aug 21, 2022
    #8
    Ghat-Smith, Elapotp, jGate99 and 8 others like this.

  9. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    1,847
    Thank you for detailed reply, this is really helpful and i'm now crystal clear of my code using Jobs now :)
     
    jGate99, Aug 22, 2022
    #9