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
- Build fails when building a project containing an 18+ dimension array with IL2CPP
- [Android][Sentis] Human poses are not detected when using the BlazePose model
- Sprite Editor Outline Tool Overlay is not displayed when no Sprite is selected
- “No method with RuntimeInitializeOnLoadMethod attribute” warning from ReadmeEditor.cs is thrown after installing Project Auditor Rules
- Projection matrix is altered when using RasterCommandBuffer.ClearRenderTarget on DX12 and Metal
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).