#What is the use case of IJobFor since IJobParallelFor exists?

1 messages · Page 1 of 1 (latest)

timber root
#

Different job types: https://docs.unity3d.com/Manual/job-system-jobs.html#:~:text=the correct order.-,Job types,-IJob%3A Runs a

It says that IJobParallelFor runs a task in parallel, ie on multiple worker threads.

And IJobFor runs on a single worker thread. They both have Execute(int index).

Now, I initially thought that since IJobFor runs on a single worker thread, I could e.g increment some global variable in every Execute() to track how many Execute()s have already been run.

But that is not possible, as the Execute()s may run on multiple cores.

The Unity page for IJobFor says:

Each iteration must be independent from other iterations and the safety system enforces this rule for you. The indices have no guaranteed order and are executed on multiple cores in parallel.

Here: https://docs.unity3d.com/ScriptReference/Unity.Jobs.IJobFor.html#:~:text=Each iteration must be independent from other iterations and the safety system enforces this rule for you. The indices have no guaranteed order and are executed on multiple cores in parallel.

kind hound
#

IJobFor was meant to be the replacement of IJobParallelFor and when it was introduced it was mentioned that IJobParallelFor would be removed in future

#

for whatever reason, that never ended up happening and now we're stuck with both of them

#

So the reason IJobFor was introduced was a few years they standardized the naming of Schedule[Parallel] calls

#

IJobParallelFor.Schedule does a multi thread scheduling - but they standardized it so Schedule() on jobs is always the single thread version

#

This was awkward because it would break all existing users code if you applied this standardization to IJobParallelFor, suddenly everyones jobs scheduled on parallel workers would now run on a single thread

#

instead they introduced the new job, IJobFor which is exactly the smae, just with properly schedule naming

#

IJobFor.Schedule runs on a single worker
IJobFor.ScheduleParallel runs across all workers - this is the same as IJobParallelFor.Schedule

#

imo you should only be using IJobFor, to me IJobParallelFor is the legacy, should be deprecated version that I hope is removed at some point in future like their original intention

#

All modern jobs use this consistent naming,
IJobEntity, IJobChunk etc all use Schedule() being single thread version, ScheduleParallel() being the multi thread version
Your code will be more consistent and less prone to bugs if you stick with this and use IJobFor

#

/endofmyhistorytalk

timber root
#

thanks @kind hound but my question was about: in what situation would I want to use a single worker thread and have Execute(index)?

why not just use multiple worker threads

kind hound
#

because your code is not thread safe and you want the convenience of the api

# 
    public struct TestJob : IJobFor
    {
        [ReadOnly]
        public NativeArray<int> Values;
        
        public NativeReference<int> Sum;
        
        public void Execute(int index)
        {
            Sum.Value += Values[index];
        }
    }```
#

very simple example

#

obviously you could just use IJob and iterate the array yourself in it

#

but it can also be useful to be able to swap your job from parallel to single thread temporarily for debugging bugs

timber root