Hacker News Reader

Comment by m12k | Hacker News Reader

IMO the Burst compiler that can "jobify" and multi-thread your code relatively painlessly is the most impressive piece of tech Unity has produced (disclosure: used to work there, though this was made after my time there). It's not that hard to fit into its constraints, and it often provides 2x-200x speedups. It's still mind-boggling to me that it's possible to get (a constrained subset of) C# to beat hand-optimized C++.

View on HN

"painlessly" involves writing your code in a totally different paradigm to the standard MonoBehaviour component approach, doesn't it? It's impressive, but I think you understate the "pain" a bit. (Disclaimer: I haven't successfully been able to motivate myself to use it - it's a heavy framework and normally when I'm making games the limitation isn't performance but my ability to get the interactions I want coded, so I prefer the more flexible MonoBehaviour component style).

That's fair - and tbh most games don't need to push the envelope when it comes to performance, so it makes sense to just stay with the most flexible default option. Still, when you compare to something like ECS, which basically needs to take over your whole architecture and give up the flexibility of MonoBehaviours, it's much easier to burst-jobify a smaller, performance critical part of your game.

Burst and Job system forces the user to follow good patterns for the multithreading, and makes sure that the user isnt writing to the same thread-unsafe structure from 2 jobs. In that regard its similar to what Rust does. It really is great to have all that checking, as if it passes the checks, it probably will work great. Keeping all the read/write dependencies beetweeen tasks in Cpp is very hard.

Is there a technical write-up of what it does and how it works somewhere? I'm not about to write any games, let alone use Unity, so Unity-specific tutorials wouldn't really help me (plus they're just going to be focused on how to use it, not on how it works).

https://xoofx.com/blog/2019/03/28/behind-the-burst-compiler/

Thanks!

> It's still mind-boggling to me that it's possible to get (a constrained subset of) C# to beat hand-optimized C++.

To me the interesting question is -- what can you do within this constrained subset?

The restrictions are: no reference types, manually manage your memory. My previous job was basically writing loads of burst code and it was so ergonomic and fun to write, and (as the GP says) you basically get 200x speed up for free.

These manual pages have an exhaustive list of supported types and language constructs:

https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...

So, technically, they took into account what parts of C++ are used to optimize a game and they made them low-hanging fruits for C# devs?

C# has plenty of low hanging fruits, more so since C# 7.0, it is a matter of people to learn how to use them.

As of C# 9:

- value types

- proper memory slices

- ability to do stackalloc in safe code

- readonly structs

- generics for blittable types

- zero allocation pipelines

- using without IDispose for structs without implicit boxing

- return scope for zero copy struct parameters

- native function pointers

- static lambdas

- GC free code regions

What HPC# and Burst bring to the table is an enforced GC free code and a compiler that is special purpose for a game engine, taking that knowledge into consideration when generating native code, for example remapping SoA into AoS and similar.

> It's still mind-boggling to me that it's possible to get (a constrained subset of) C# to beat hand-optimized C++.

That sounds interesting, do you know if there are benchmarks available?

Reply on news.ycombinator.com