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
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.)
1 Like
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.
1 Like
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.
1 Like
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.
10 Likes
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)
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.
2 Likes
@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: UnityCsReference/Runtime/Export/NativeArray/NativeArray.cs at 2022.2 · Unity-Technologies/UnityCsReference · GitHub , 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.
11 Likes
Thank you for detailed reply, this is really helpful and i’m now crystal clear of my code using Jobs now 