[PATCH] D71786: RFC: [Support] On Windows, add optional support for rpmalloc

Alexandre Ganea via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Feb 15 05:59:55 PST 2020


aganea added a comment.

In D71786#1877744 <https://reviews.llvm.org/D71786#1877744>, @riccibruno wrote:

> In D71786#1871211 <https://reviews.llvm.org/D71786#1871211>, @rnk wrote:
>
> > - Try raising BumpPtrAllocator "slab" size above 4096, that seems too small. Most AST nodes are allocated with BumpPtrAllocator.
>
>
> - I agree that 4K is too small. Virtual memory is cheap so we should just allocate large slabs. That said in my experiments increasing the slab size had no measurable impact in itself (at least for clang with `-fsyntax-only`). What did have a meaningful impact is using large pages (5%-6% in `-fsyntax-only` on all of Boost, obviously hardware dependent). Additionally I suspect, but have no data, that the improvement will be comparatively larger in a normal compilation because typically the DTLB and STLB are shared between the logical threads on each core.


We could add a `PageAllocator` instead of the current `MallocAllocator`, and make the default 64kb. The beauty about this is that we could either: 1. use large pages with just flipping a flag; or 2. allocate large contiguous slabs or virtual memory and commit memory pages on-the-go. This is a technique we're using in games to avoid reallocating/moving around allocated blocks. This only works with 4kb pages, not with large pages (which are committed by default)
But further down the line, it'd be nice to collect statistics about how the BumpPtrAlloctor grows/is used. And same for stack-based structures like the "Small" containers, so that we can set default container sizes that actually have the most impact. Nicolas Fleury has a talk here <https://youtu.be/tD4xRNB0M_Q> about some of the techniques we use at Ubisoft (check at 21:26).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71786/new/

https://reviews.llvm.org/D71786





More information about the llvm-commits mailing list