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
- Too little validation messages in the "WebAssembly Language Features" Memory settings
- Project Settings Search Highlights are misaligned when using the Bitmap Text Rendering Mode
- "GetControlID at event ValidateCommand returns a controlID different from the one in Layout event" Warning is thrown when undoing the deletion of Sprite Shape Profile
- Memory related fields in the "WebAssembly Language Features" can be set to the negative numbers
- "WebAssembly Language Features" Header in the Player Settings has a smaller indentation
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.