Search Issue Tracker
Fixed
Fixed in 1.8.17
Votes
0
Found in [Package]
1.8.15
Issue ID
BUR-2701
Regression
No
The time consumption of the Burst function delegate call is unproportionally higher for the function pointers compared to jobs on Windows machines when working with the x86 architecture family
How to reproduce:
1. Open the “Archive 3“ project
2. Open the “SampleScene“
3. Open the “Window > General > Test Runner“ window
4. Open the Play Mode tests
5. Run the “Burst Test/Test.dll/Tests/BurstFunctionPointerTests/TestFunctionPointer“ test
6. Observe the “Avg“ fields of the “Bad function pointer“ and “Normal Job“ categories
Expected result: The “Bad function pointer“ and “Normal Job“ average time consumptions are close in value
Actual result: The “Bad function pointer“ average time consumption is over 10 times bigger than the “Normal Job“ time consumption
Reproducible with: 1.8.14 (2022.3.30f1, 6000.0.3f1), 1.8.15 (2022.3.33f1, 6000.0.6f1)
Could not test with: 1.8.15 (2021.3.39f1) (Could not resolve the Console errors)
Reproducible on: Windows 10 Pro (22H2)
Not reproducible on: macOS 14.5 (Intel)
Notes:
- Only tested on the x86 Architecture family (including macOS (Intel) and Windows machines)
- On the macOS (Intel) machine the “Bad function pointer“ and “Normal Job“ average time consumptions are close in value, the issue is not reproducible
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Skinned Mesh Renderer with multiple Animator Components does not render when "Optimize Game Objects" is enabled
- [iOS]Certain characters are not displayed when using iOS devices with 18 OS and newer
- Trees do not render in 'Unity Terrain - URP Demo Scene'
- Silent crash when clicking in Scene View in a specific project
- The Player renders black on a Quest headset when MSAA, Post Processing, and Spacewarm depth submission are enabled
Resolution Note (fix version 1.8.17):
This is mostly as-designed, but with a caveat (explained below).
In order to correctly restore CPU state when handling a `throw new Exception(...)` in Burst-compiled code, the Burst compiler emits some code to save CPU state at the start of Burst entry points. (This is only done in the Editor, because in player builds, thrown exceptions terminate the process.) Because of differences between calling conventions across platforms, this code is only needed on Windows x64. Specifically, on Windows x64, XMM6-15 registers are callee-saved, while on MacOS x64, those registers are not callee-saved. This difference is why you only saw the bad performance on Windows x64.
So this is mostly as-designed, except: while investigating this bug, we noticed that we were always emitting this CPU-state-saving code, even if there was no `throw` in the code being compiled. So in the next release of Burst, we'll tweak it such that the CPU-state-saving code is only emitted when necessary.
Unfortunately, this doesn't help with the test cases in the repro project for this bug, because e.g. {{MyJob0}} calls into {{NativeArray}} APIs that do throw exceptions, so the CPU-state-saving code is still necessary.