Burst and thread safe API outside Unity Jobs system

Hello,

I could guess that Burst works in a similar way to how native dll works with mono. If this is true, would be feasible to make the Burst attribute available for code even outside the Job system?

Similarly, could be possible to have thread safe API (transforms, raycast) that could work outside the job system?

 

Thanks for the reply! It was a wild guest, but I still hope I could use it outside the job system

I have my own multi-threaded scheduling system, which is comparable to the JobSystem, therefore I would love to not be forced to use jobs if I don't strictly see the benefits. Currently the benefits I see are not due to the Job interface, but to the fact I would like to use burst and the thread safe API. I understand that you want to make performance accessible to everyone, but you should not assume that very experienced people don't use and love Unity (like I do). I believe c# is powerful enough, but I am limited by the unity API. Burst is also awesome and it would be a shame to limit it to jobs only. What I am trying to say is, you are doing a great job, don't limit it to your vision only though, it could be counter productive.

 

Hello Joachim,

it's great seeing you reply on the forum wow! I tried it for my One Million Points on CPU demo and it works well. I noticed that the IL2CPP needs some optimizations, but I think you are aware of it. I also 100% understand your goals for the Job System and I agree with the objectives, I am just saying that for medium/big teams with custom solutions there could be already alternatives. Our solutions currently runs at the same speed of the Job System in my demo, faster if compiled with IL2CPP.
The only concern I wrote in my article about the the Job System is that this solution would be optimal in a totally multi-threaded environment, but as long as a lot of stuff still happens on the main thread, triggering a burst of parallel tasks is less beneficial than running the tasks while the main thread does other things. Obviously I understand that stalling the main thread is necessary for safety concerns.
Again I love what you are doing, no critics at all, I just would also love to be able to use all this stuff outside the job system too. I will test the prototype API asap!

 

yes you are absolutely right. Thanks for enlightenment, I will profile it again.

To be honest, there is no way to know from the name of the functions when the jobs actually start. From the examples I saw so far, it seemed more reasonable that schedule was just preparing the jobs while Complete was starting and waiting for them.

Obviously now it makes more sense, but if you didn't tell me, I wouldn't have guessed.

About the performance, I also thought Unity Jobs could have been slower for that reason, but it is not. Currently Unity jobs is slower only if compiled in native code through IL2CPP, but this is a know problem by you.

Of course Burst is what I am looking forward for, my concern is about how to use Burst with IL2CPP. Once we move to 2018, I don't see any reason to not use IL2CPP. I still expect burst to do a better job than the Microsoft compiler, even with all the optimizations enabled.

I will replicate your work for my new profiling, why did you need to remove the static access? I guess because burst doesn't compile it right?

 

Hello Xoofx, I am doing some tests. I will test burst right after this, but without burst I did this:

Code (CSharp):

1. var jobSchedule = _job.Schedule(_particleCount, 32);
2.          
3.             //do something seriously slow
4. #if DO_SOMETHING_SERIOUSLY_SLOW        
5.             Thread.Sleep(10);
6. #endif
7.             jobSchedule.Complete();

and the timings didn't change compared to my article ones...while the main thread gets stuck for 10ms, the jobs should start, but it seems they don't? According what you said they should. I mean they could have started (I cannot verify it), but in this case the timing should be 10ms faster.

 

call JobHandle.ScheduleBatchedJobs();

then do your sleep.

Lennart

 

thanks can you explain me the difference beetween Schedule and ScheduleBatchedJobs?

Edit: NVM, Got it! I don't understand why there is Schedule at all then.

Edit2: Oh I see, it's actually a static function which is not specifically related to the jobs I just scheduled...weird

 

You can set up many jobs with schedule, then you tell them to start with JobHandle.ScheduleBatchedJobs();
If you do not start them they will only start when you call complete

 

OK timings are now back to normal, thanks for the help @LennartJohansen

 

I lost the link with the build that includes burst, can you link it again please?

Edit: right I forgot Burst runs only inside the editor and that I have already decided to wait for the standalone compatible version to profile it.

 

Any news on the

Code (CSharp):

1. Burst.BurstDelegateCompiler.CompileDelegate

? is this still in pipeline?

 

So then you can call methods outside of the job after it has finished running or am I understanding it wrong?

 

Hey,


Thank you for the answer. That is unfortunate to hear though. So, there will be no feature that allows us to use the power of the burst compiler outside of a job? Sometimes we have systems that are not big enough to be scheduled for a job; because of the overhead of creating a job. Those systems could still benefit a lot from better compiled code.

 

We found that your scheduling system is not perfect enough on Android. in some cases, overall performance suffers from scheduling jobs worth 2-3 ms.

Can we execute a job specifically in the main thread? It would help us a lot in some cases.

 

> Yes. You can use .Run() on any job.
There's no such thing as .Run() in any job not in 2019.2 not in 2019.3 documentation.
do you mean .Execute()? And it will run with burst optimizations?

 

Was this changed? I'm running function fine in MonoBehaviour.Update().

 

Unfortunately seems like NativeArrays don't work and without them overhead of running simple functions is not worth using.

 

I'm sure that will work in the future. For the time being you may just wrap it:

Code (CSharp):

1. [MethodImpl(MethodImplOptions.AggressiveInlining)]
2. public static bool ComputeSomeStuff(NativeArray<float> values)
3. {
4.     return computeSomeStuffBurst((float*)values.GetUnsafePtr(), values.Length);
5. }
6.  
7. [BurstCompile]
8. static bool ComputeSomeStuffBurst([NoAlias] float* values, int valueCount)
9. {
10.     // hellishly fast code
11. }

 

Thanks @julian-moschuering

No idea if possible but it would be amazing if those function could be edited and recompiled during playmode without domain reload. Even if it makes caching .Invoke impossible it would significantly speed up my workflow.

 

Will stuff like [MethodImpl(MethodImplOptions.AggressiveInlining)] and [BurstCompile] be an implicit conversion based on certain criteria at some point so we don't have to explictly specify?

 

For me the job system has too big of a fundamental flaw that I'm trying to work around and starting to question if its worth it at all. It looks like Unity uses jobs internally for things like recalculating bounding volumes and particle system modules.

Well now that I have some huge jobs (can take around 500ms in the editor) those Unity jobs can be blocked by them and that feels so fundamentally wrong. I'll be walking around and everything will freeze for a noticeable second, I check the profiler and there is a huge spike on WaitForJobGroupID and within it one of my jobs.

So now I could do things like break down that job into many smaller ones but the reason I didn't before was cause in my initial tests this batch size was most optimal, splitting it up will mean it will take much longer overal to process all my data.

This however isn't a full solution, cause now my FPS is limited by the biggest job I have. I see consistent time lost per frame when I'm processing lots of smaller jobs as well.

As a note, I've also profiled in builds (Windows standalone) and seeing the same behaviour. Its just less noticeable since everything is running faster without the safety system but its still a big bottleneck for me.

I've also opened a ticket around this to make sure its not just a bug, but it doesn't feel like it.

 

Also the documentation is just really confusing. I've been working with a custom multi threaded solution for years but jobs feels messy compared.

I create my job and call schedule. Then on the main thread I check each frame (on both Update and LateUpdate) for if the handle .IsCompleted and is so I call Complete().

Well the documentation says things like: "The job system intentionally delays job execution until you call
ScheduleBatchedJobs manually"

And when talking about .Complete() "this method flushes the jobs from the memory cache and starts the process of execution".

I never call ScheduleBatchedJobs anywhere (about to try it and see if it helps) and it feels like in my code Complete should never be called until the job has finished but it instantly raises the question of why are my jobs even running/how are they getting started?

 

I had problems with it too, the design is completely different to what you would expect from other multithreaded patterns, but it makes sense eventually. It's probably the simplest way to solve the data dependency problem. The only thing I don't like about the job system is that it has been partially written in c++, when this was not necessary (they reuse a framework that is used also by the engine at c++ level).

If you want to know more about how it works at low level ,you can check the work-stealing technique. Regarding how to use it, I wouldnt know where to start to explain it, but you must not use .Complete() as it would defeat the purpose.

 

See I felt I was used to it and happy, its just when an issue comes up that it leaves you scratching your head cause the documentation feels conflicting.

It feels like jobs is mainly made for one purpose and that's to be used in quick bursts in sync with the main thread. Long running jobs are the afterthought which I find strange since they feel like the more usual use cases.

My first thought isn't to multi thread the updates of say 1000 enemies, but I would think to multi thread that big task of calculating a terrain. It feel like jobs focuses more on those 1000 enemies type scenarios.

 

it really depends by a lot of factors, but if you use full ECS and SystemBase most of it should be completely transparent to you. If you are not using ECS, then it's another story.