4 ms·

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: u

by m12k 6y ago

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++.

vanderZwan 6y ago
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).
- sharpercoder 6y ago
  https://xoofx.com/blog/2019/03/28/behind-the-burst-compiler/ https://xoofx.com/blog/2019/03/28/behind-the-burst-compiler/
  - vanderZwan 6y ago
    Thanks!
jstimpfle 6y ago
> 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?
- camjw 6y ago
  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.
- ratww 6y ago
  These manual pages have an exhaustive list of supported types and language constructs: https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual/docs/CSharpLanguageSupport_Types.html https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual... https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual/docs/CSharpLanguageSupport_Lang.html#language-support https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...
johnnycerberus 6y ago
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?
- pjmlp 6y ago
  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.
emsy 6y ago
> 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?
vblanco 6y ago
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.
OneGuy123 6y ago
It's a fallacy to say that this can beat hand-optimized C++. If you were to write the equivalent code in hand-optimized C++ you could in 99% get at least a small speedup if not a larger one. It's as if you are comparing singlethread C++ with multithreaded burst C# code?
jan_Inkepa 6y ago
"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).
- m12k 6y ago
  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.
deleted 6y ago
[deleted]

by m12k 6y ago

vanderZwan 6y ago

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).

sharpercoder 6y ago
https://xoofx.com/blog/2019/03/28/behind-the-burst-compiler/ https://xoofx.com/blog/2019/03/28/behind-the-burst-compiler/
- vanderZwan 6y ago
  Thanks!

jstimpfle 6y ago

> 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?

camjw 6y ago
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.
ratww 6y ago
These manual pages have an exhaustive list of supported types and language constructs: https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual/docs/CSharpLanguageSupport_Types.html https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual... https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual/docs/CSharpLanguageSupport_Lang.html#language-support https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...

johnnycerberus 6y ago

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?

pjmlp 6y ago
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.

emsy 6y ago

> 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?

vblanco 6y ago

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.

OneGuy123 6y ago

It's a fallacy to say that this can beat hand-optimized C++. If you were to write the equivalent code in hand-optimized C++ you could in 99% get at least a small speedup if not a larger one. It's as if you are comparing singlethread C++ with multithreaded burst C# code?

jan_Inkepa 6y ago

"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).

m12k 6y ago
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.

deleted 6y ago

[deleted]