The reason not to use [ComputeJobOptimization]?

I see this attribute on an IJob struct. I guess it tells Burst to optimize the generated job code.

  1. Is it only benefits me if I use Unity.Mathematics inside the job?
  2. Why not add it all the time? What is some situation not to use it?
  3. Is math.greaterThan/math.lessThan/etc. makes the code faster than using > or < ? I think unlike math.select which could not replace all if, these can safely replace the >, < operator 100% of the time but make it harder to read. Can I use >, < and get the same performance/optimization?

I cant answer all your questions. I think that Unity.Mathematics package due to it being written in c# which allows to burst to optimize maths better. although that is a conclusion from what i have gathered, so i might be completely off

This attribute only indicates that the job will be compiled by burst. But if you don’t use Unity.Mathematics, the job will still be optimized.

Because in some cases, you would like to debug your code or you have some (debug) code that is using managed objects (e.g strings) and burst would not be able to compile them. Also, you can hit a bug in burst (hopefully, not too many!) so that it allows you to select explicitly which jobs are good to go with burst.

It is all fine: greaterThan/lessThan are actually using > < behind the hood. So yes, you can use directly the standard operators (greaterThan/lessThan are GLSL like functions)

6 Likes

Thanks for the clarifications as it provides clear avenues to debug and eliminate problems