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
- Out-of-bounds memory access with multiple CanvasRenderers under a Canvas when using Mesh API
- Inspector tries to access file after it was deleted when the file was locked in Inspector window
- Changing Transform values in Search window Inspector loses focus while dragging and stopping mouse without releasing dragging action
- Saving changes on the dirty VFX Graph during the Play mode throws "The referenced script (Unknown) on this Behaviour is missing!" warnings
- VFX Graph Debug Info overlaps the "Initialize" block debug info by default
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).