e6f54c17c4
This version of mimalloc is very efficient at distributing threaded allocations in a way that maintains
locality which in turn improve the amount of memory that we're able to send back to the system
after heavily multithreaded workloads. This also improves performance as less page fault and cache misses
are expected coming from more densily packed allocations.
mimalloc v1 seemed to waste more memory because of its commit size being larger than TBB.
However, its allocation patterns was already way tigther than TBB but for it to become apparent, you had
to activate the "page_reset" and "reset_decommits" options, which came at a performance loss.
mimalloc v2 offers both better locality and by default will more agressively decommit memory with
only minor performance loss in some cases and performance gain in many.
Given the advantages of mimalloc v2 compared to Intel TBB, we should probably consider it
as our next default allocator for the editor.
- All tests performed on AMD TR 3970X with 256GB RAM
- Loading FramingCameraTest map on special project with -ddc=cold and waiting until every asset is built
- 699s @ 32GB for tbb malloc
- 655s @ 37GB for mimalloc v1
- 757s @ 12GB for mimalloc v1 + page_reset and reset_decommits
- 604s @ 15GB for mimalloc v2
- Loading P_World on Reverb -ddc=cold and waiting until every asset is built
- 2372s @ 71GB for tbb malloc
- 2587s @ 75GB for mimalloc v1
- 3212s @ 34GB for mimalloc v1 + page_reset and reset_decommits
- 2503s @ 37GB for mimalloc v2
- Loading P_Construct_WP on special project with -ddc=cold and waiting until every asset is built
- 6404s @ 56GB for tbb malloc
- 6640s @ 37GB for mimalloc v2
- Loading Apollo_Terrain on FortniteGame with -ddc=cold and waiting until every asset is built
- 751s @ 33GB for tbb malloc
- 744s @ 25GB for mimalloc v2
- Cooking FramingCameraTest map on special project with a warmed-up DDC
- 379s @ 34GB for tbb malloc
- 367s @ 29GB for mimalloc v2
#rb Brandon.Dawson, Yuriy.ODonnell, Stefan.Boberg
[CL 15859558 by danny couture in ue5-main branch]
Testing allocators is difficult as bugs may only surface after particular
allocation patterns. The main approach to testing mimalloc is therefore
to have extensive internal invariant checking (see page_is_valid in page.c
for example), which is enabled in debug mode with -DMI_DEBUG_FULL=ON.
The main testing strategy is then to run mimalloc-bench using full
invariant checking to catch any potential problems over a wide range of intensive
allocation benchmarks and programs.
However, this does not test well for the entire API surface and this is tested
with test-api.c when using make test (from out/debug etc). (This is
not complete yet, please add to it.)
The main.c and main-override.c are there to test if building and overriding
from a local install works and therefore these build a separate test/CMakeLists.txt.