Search Unity

Since the first stable release of Burst Compiler a year ago, we have been working to improve the quality, experience, and robustness of the compiler. As we’ve released a major new version, Burst 1.3, we would like to take this opportunity to give you more insights about why we are excited about it and what’s coming next.

We’re trying to constantly listen to our users and Unity partners. Also, internal teams at Unity are using Burst more and more. Based on this feedback, we have been prioritizing our work for the past quarter to ensure that we’re always thoroughly balancing the following 4 areas of improvements:

  • Scalability
  • Performance
  • Quality
  • Usability and Debuggability

As Burst is a core part of DOTS (Data-Oriented Technology Stack), the new 1.3 release of the Burst Compiler is trying to improve each of these areas to improve user experience.

Cross compilation for Desktop

Many of you have requested an option to compile a desktop player for a platform different from where the editor is running. One typical scenario is when you use Unity Build Cloud Services and the build machines are running on macOS while you’re trying to generate players for Windows. This new version of Burst enables the compilation of a Mono-based player across different desktop platforms.

Note that this new feature applies only for desktop build players. Console and mobile platforms usually have restrictions about which platform they can be compiled from as their SDK is often compatible with only one host platform.

Native Debugging

Debugging code compiled with Burst is another much-awaited usability feature. Until recently, the only way to debug Burst code was to actually disable Burst and rely on existing .NET managed debugging facilities. 

With Burst 1.3, you can now use any integrated IDE native debugger found in Visual Studio, XCode or VSCode and debug Burst code with it:

In order to enable this feature, you need to select Enable Native Debugging in the Unity Editor Burst menu. The debugging experience allows you to:

  • Hit breakpoints, including conditional breakpoints (data breakpoints should work too)
  • Inspect frame callstack
  • Inspect local variables
  • Inspect structures and data, follow pointers
  • Use debugger watches

You need a separate native debugger launched from your regular .NET IDE in order to use this feature. You can then attach this native debugger to your game or even the Unity Editor. You can watch the following video tutorial for more details.

We understand that a more integrated debugging experience alongside regular .NET managed code is something that our users are looking forward to. This is something that we want to pursue as well, even though it’s difficult to bring about without penalizing the debugging experience. But we will try to improve this situation in the future. 

Debug.Log and strings support

Another usability feature is the support for Debug.Log and partial string support available for Unity 2019.3 and above.

You can learn more about this feature from this documentation.

New Intel CPU Intrinsics API

Burst has been optimized to leverage the power of SIMD. The Unity Mathematics package supported by Burst provides an API to manipulate standard vector types (e.g float3, float4) and to perform various calculations encountered by 2D and 3D workloads more efficiently. 

We also understand that in order to fully take advantage of existing hardware and to empower our users, we need not only to provide this abstract math API, but also to unlock more advanced optimization scenarios. With this new release, we’re introducing a new Intel CPU Intrinsics API to cover that performance aspect.

Compilation Time

As more and more studios and teams are using it to optimize their games, Burst has to compile and optimize an increasing amount of user code. In the previous version, we introduced multithreaded compilation for both in-Editor experience and when building a standalone player, but the compiler still had to recompile your entire project whenever you restarted the editor.

We’re working on improving this scalability problem by first introducing in Burst 1.3 the caching of compilation results to disk, so that whenever you restart the editor, Burst should no longer try to recompile code that was previously compiled.

But we’re not where we want to be with compilation times just yet. In the next quarter, we’re actively working to improve further and help larger projects iterate faster with Burst.

Better codegen

Thanks to the C# Job System which ensures that concurrent write accesses are impossible, the Burst Compiler is in a unique position to better optimize your code than a regular C++ compiler. One of the critical optimizations that Burst allows is auto-vectorization, which can bring a 3x to 4x performance boost over regular scalar code. When you couple this with a carefully crafted layout of your game data, you can get improve the efficiency of your code by another order of magnitude, compared to non-data-oriented game code.

In this new version of Burst, we have rewritten the memory aliasing analysis which is the entry point to actually auto-vectorize your code. We’re also introducing new intrinsics,  providing asserts to your code that can verify that two memory references aren’t aliasing or that a loop should vectorize (this one is still experimental).

You can learn more about this unique feature from this Memory Aliasing and noalias documentation.

More bug fixes

The Burst Compiler should generate code that you can safely rely on, but as with any other compiler, it can have bugs. Since the 1.2 release, we have fixed many issues and invalid codegen cases. But we’re also trying to make sure that the quality of the compiler is rock solid by adding more and more unit tests and integration tests with larger projects for every new release.

While it improves codegen performance, this new release should also be safer to use in your projects.

What’s next?

We’re constantly adapting our priorities based on your feedback. In the coming months, we’ll be working on:

  • Improving compilation time for both editor experience and player builds.
  • Improving codegen.
  • Bringing a new intrinsics API for Arm CPUs.
  • Various improvements in C# support (foreach, IDisposable…)

Start using Burst

Burst is part of DOTS and you can already use it now! It’s stable and we’re actively working on improving it.

It supports major desktop, console, and mobile platforms. It’s verified for Unity 2018.4 and newer, including the latest Unity 2020.2 alpha.

We will come back in an upcoming series of blog posts to provide better guidance on using Burst as well as insights about what’s coming next.

In the meantime, let us know what you are doing with it and if you have any questions or issues, please feel free to leave a message on the DOTS forum!

 

14 replies on “Optimize your projects with Burst Compiler 1.3”

Thanks to sharing the nice blog about the information of Optimize projects with Burst. It’s really help for us….

What is Burst good for?

Serious question!!!

What kinds of games, game features and devices benefit from the efforts required to find a Unity version and Burst version that’s production ready, and learning how to use Burst?

Burst is mostly used with the job system, and every game/application can benefits from it. I know of at least 3 games that shipped with it and it would not have been possible to even create 2 of those games without Burst. In my own project I gained ~20x speed increase. Burst is definitely one of Unitys gems

Burst is really good. I wish Unity could license it with Mathematics outside of Unity at some point.

Probably the best feature Unity has introduced for years – and essential for the company’s future.

+1 for deterministic floats.

First of all thanks for the great work!
Secondly we used it in a shipped game for real-time texture modification on mobile and it worked perfectly and are using burst in our pre-production of our current game in DOTS which is systemic and with lots of unit and the magic that it is doing is undescribable.

What I personally look forward to now is more speed ups in compilation time and cross-architecture deterministic floats so a multiplayer game hosted on x86 can be deterministic with ARM clients. This said the x86 determinism on its own is good enough for so many cases.

The new debugging experience also and the simple addition of Debug.Log is great. Disabling burst for debugging was ok but this is fantastic and also helps in the rare case that the bug only happens when using burst

I’m glad to see that you’ve added a CPU intrinsics API, but it’s very disappointing that it can’t be used outside of burst jobs.

I have a C# physics engine that pretty much requires the use of SIMD to be performant. Using it inside Unity right now is not feasible, and porting it to burst jobs would mean rewriting the entire thing.

I’m glad you’ve added the CPU intrinsics API to burst, but it’s very disappointing that this can’t be used outside of the job system.

I have my own physics engine written in C# that really needs to use SIMD for reasonable performance. It’s basically unusable inside Unity as it currently stands. Porting it to burst jobs isn’t feasible.

Comments are closed.