Burst JIT Compile Times

As our project is getting more complicated with more Burst jobs involved our time spent JIT compiling on each project run in the editor is increasing.

We are using async compilation where possible, but for some of the more complicated jobs we have to force synchronous compilation or suffer a very very long first iteration in a ParallelFor loop (5s non burst vs around 0.006s once compiled!).

As far as I can tell from the debugger however a lot of time is spent JIT compiling the jobs with no other work happening, this is sitting at about 30-40% of our time while entering play mode.

Are there any ways to offload this work from the main thread?

Is it possible to cache the compilation between runs, only recompiling if that job has changed?

Forgive my probably stupid questions.

 

That's great to hear!

 

Thanks Lee and team. This has halved the time it takes to start our project. Much much much better.

 

While this has been working fantastic up until now, unfortunately I've just wasted a couple of hours trying to figure out why things were working fine when I had a job Burst compiled, and went to crap as soon as I enabled it.

For some reason after updating the code it's not being detected as having changed, and therefore not recompiling and I'm stuck with older code while using Burst.

The only way so far I've figured out how to fix it is to restart Unity.

The job in question is a fairly large pathfinding job which may have something to do with it.
Can't seem to find where the logs are for this to post though.

 

These are grayed out for me in the package manager. Am I supposed to change it manually in the manifest?

 

Thanks for the quick response.

Updated to the latest Burst package, but unfortunately I still have the same problem. I can reproduce it by simply commenting out some code with in a job with [BurstCompile].

The code will continue to run on next launch as if unchanged, and will not compile correctly regardless of how many times the game is started. If I comment out [BurstCompile] the code executes correctly. If I renable [BurstCompile] and run again the code is now compiled correctly.

I was running on 2019.3.0b1 initially, just updated to 2019.3.0.b2 and have the same issue.

 

I had that happen to me the other day (2 days ago I believe). I could not figure out what the deal was. I ended up removing the file from my project, compiling, adding it back in and then it seemed ok. I thought I was losing my mind for a bit.

 

@tim_jones yeah that's correct.

I've just submitted a bug report now. It's taking a while to pack and upload so I'll get back to you with the bug number in the morning.

 

I just installed and tried this with 2019.3.0b3 using 1.2-preview.1 (was fine on 0b2) and I get this each time I try to play.

Code (CSharp):

1.  
2. Caught fatal signal - signo:11 code:2 errno:0 addr:0x7fe24c4e5000
3. Obtained 13 stack frames.
4. #0  0x007fe20c09d0bd in (Unknown)
5. #1  0x00000041026954 in Burst.Compiler.IL.Jit.JitCompiler:CompileMethod (Mono.Cecil.MethodReference,Burst.Compiler.IL.Jit.JitOptions)
6. #2  0x00000040f56740 in Burst.Compiler.IL.Jit.JitCompilerService:Compile (Burst.Compiler.IL.Jit.JitCompilerService/CompileJob)
7. #3  0x00000040ea4760 in Burst.Compiler.IL.Jit.JitCompilerService:CompilerThreadLoop ()
8. #4  0x00000040ea3e36 in System.Threading.ThreadHelper:ThreadStart_Context (object)
9. #5  0x00000040ea2c34 in System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
10. #6  0x007fe26c0da8d9 in mono_print_method_from_ip
11. #7  0x007fe26c246def in mono_perfcounter_foreach
12. #8  0x007fe26c260a81 in mono_threads_set_shutting_down
13. #9  0x007fe26c2c20d7 in GC_inner_start_routine
14. #10 0x007fe26c2b6e42 in GC_call_with_stack_base
15. #11 0x007fe452697182 in start_thread
16. #12 0x007fe4525c0b1f in clone
17. Launching bug reporter
18. QObject: Cannot create children for a parent that is in a different thread.
19. (Parent is QNetworkAccessManager(0x1a7c270), parent's thread is QThread(0x196a060), current thread is Thread(0x1a20a70)
20. [0910/172216:ERROR:browser_main_loop.cc(207)] GLib-GObject: invalid unclassed pointer in cast to 'GtkWidget'
21. [0910/172216:ERROR:browser_main_loop.cc(207)] Gtk: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed
22. [0910/172231:ERROR:browser_main_loop.cc(207)] GLib-GObject: invalid unclassed pointer in cast to 'GtkWidget'
23. [0910/172231:ERROR:browser_main_loop.cc(207)] Gtk: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed
24. [0910/172233:ERROR:browser_main_loop.cc(207)] GLib-GObject: invalid unclassed pointer in cast to 'GtkWidget'
25. [0910/172233:ERROR:browser_main_loop.cc(207)] Gtk: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed
26. [Unity Package Manager (Upm)]
27. Parent process [17864] was terminated
28.  

 

I've tried to upload a bug report three times now and just as it has finished I've gotten a bad gateway error. I'll try again this afternoon but it looks like the bug reporting system is down.

 

I keep getting that with the forum, too. I keep having to refresh a few times.

(I think I accidentally hit report on your post instead of reply! D : ! If an admin/mod reads this and I did report him, that was my bad! I just hit the button and started typing my reply without paying much attention)

 

No, that was just running my project with burst 1.2-preview.1. I was going to submit a bug report when I get home.

 

I finally got the bug report uploaded @tim_jones

Kept getting gateway errors, until yesterday where it finally uploaded properly but I never got a confirmation email... it looks like it just disappeared.

Tried again this morning and worked fine, got the email in 1 min.

Case number is 1184669.

 

Just installed Burst 1.2.0 preview 5 this morning. Testing so far shows problem has been fixed.