Resolved Do I need to add [BurstCompile] to inner functions?

Hi,
do I need to add [BurstCompile] for calculateA() and calculateB(), or is it already covered, because OnUpdate() has already the tag?

Code (CSharp):

1. public partial struct TestSystem : ISystem
2. {
3.     [BurstCompile]
4.     public void OnUpdate(ref SystemState state) {
5.         TestSystem.calculateA();  // Burstcompiled?
6.         this.calculateB();  // Burstcompiled?
7.     }
8.  
9.     public static void calculateA() {
10.     }
11.  
12.     public void calculateB() {
13.     }
14. }

And here the same for a job too, do I need to add [BurstCompile] for calculateX() and calculateY()?

Code (CSharp):

1. [BurstCompile]
2. public partial struct TestJob : IJobEntity
3. {
4.     public void Execute(
5.         Entity entity
6.     ) {
7.         TestJob.calculateX();  // Burstcompiled?
8.         this.calculateY();  // Burstcompiled?
9.     }
10.  
11.     public static void calculateX() {
12.     }
13.  
14.     public void calculateY() {
15.     }
16. }

 

Regarding your System implementation:

(Source: https://forum.unity.com/threads/whe...with-mild-under-the-hood-explanation.1344539/)

So your OnUpdate method has the BurstCompile attribute, so when Burst compilation is enabled also your calculate methods are Burst compiled.

Regarding your Job implementation: Nothing is bursted. You have to put the BurstCompile attribute onto the Execute method. BurstCompile attributes on classes/structs should be used to help Burst finding the methods to be bursted, they itself do not cause Burst compilation of inner methods.

 

Nope, that's not required. Rest looks correct.

If in doubt what's compiled and what's not - use Burst Inspector.
If respective jobs / methods are present - they are compiled.

Also, Rider displays what's bursted.
(if you need another reason to dump VS)

For more see pinned post:
https://forum.unity.com/threads/whe...with-mild-under-the-hood-explanation.1344539/

 

From the documentation:

 

Good official documentation about Burst compilation process: https://forum.unity.com/threads/whe...with-mild-under-the-hood-explanation.1344539/

 

Thank you all!

Should have read this earlier

Thanks for that!! I just had to update Rider, but it seems it only works for ISystem, but not IJobEntity.
(ISystem) (IJobEntity)

So does this mean already that calculateX() is compiled with Burst? Or do I need to learn Assembly?

 

Decent heuristic: If you're seeing it in the Burst inspector, it's definitely Burst-compiled.

Another one: If you're using it from a Burst-compiled method, it's definitely Burst-compiled. (You cannot call managed code from Burst, it simply won't compile, and you'll see errors in the console and in the Burst Inspector. Therefore, if it works, it's all bursted.)

 

Yeah, the update somehow made it worse. Idk how. Probably going to be fixed eventually.

If method is called from within burst compiled code - Burst will attempt to burst compile it.
Meaning you'll get either:
- a managed error in the console if it fails;
- [BurstDiscard] will discard it from compilation;
- a working burst compiled code;

As a rule of thumb - don't mark random static methods with [BurstComple].
That will throw exceptions since Burst will actually attempt to compile a FunctionPointer method for the static context. Which usually fails at complex structs, e.g. float3 params. Plus its a waste of editor performance, since job code method calls are inlined into what you see in the inspector.

Tl;DR: Yes.

Mark jobs & ISystem methods that should be burst compilable in theory.

 

Thank you for clarifying!