Search Issue Tracker
Won't Fix
Votes
1
Found in
2022.3.49f1
Issue ID
UUM-98768
Regression
No
Low performance using memory allocated by UnsafeUtility.Malloc when using AMD Ryzen CPUs
Reproduction steps:
1. Open the attached “BugRepro” project
2. Click Window > General > Test Runner
3. Run all “Hitting_The_Wall“ tests
4. Observe the total running time of the tests
Expected results: Tests are finished within 1 minute
Actual results: Tests are finished in 6 minutes
Reproduced with: 1.8.18 (2022.3.49f1), 1.8.8 (2023.3.0a2), 1.8.17, 1.8.18 (6000.0.20f1, 6000.0.22f1)
Couldn’t reproduce with: 2021.3.44f1 (Burst is not available in 2021.3)
Reproduced on: Ubuntu 22.04 (AMD Ryzen 7 5800), Windows 11 (AMD Ryzen 7 5800)
Not reproduced on: Ubuntu 22.04 (Intel i9-10885H), Windows 11 (Intel Core 9-11900H)
Notes:
- Intel i9-10885H finishes all the tests in 51 seconds
- AMD Ryzen 7 5800 finishes all tests in 362 seconds
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:
`UnsafeUtility.Malloc` uses Unity's allocators under the hood, for large persistent allocations this ultimately ends up calling the platform specific memory allocation function (`VirtualAlloc` on Windows).
Our allocators work on a Reserve + Commit system where memory is reserved but cannot be accessed, it is then committed when it is intended to be used and uncommitted when memory is freed (allowing for reuse). Due to various factors (mainly for allocation headers, page granularity & alignment); for larger allocations, our allocator tends to reserve more memory than requested.
With the above in mind, we have chosen to close this issue as "won't fix" as the cause is a combination of the specific processor's cache size, non linear access pattern (due to IJobFor multithreaded access) and the fact our allocator tends to allocate additional memory (leading to reaching cache size sooner).