[llvm-dev] RFC: Replacing the default CRT allocator on Windows

Alexandre Ganea via llvm-dev
Thu, 02 Jul 2020 15:15:51 -0000

Hello David,

Please see below.

-----Message d'origine-----
De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la part de David
Chisnall via llvm-dev
Envoyé : July 2, 2020 8:04 AM
À : llvm-dev at lists.llvm.org
Objet : Re: [llvm-dev] RFC: Replacing the default CRT allocator on Windows

> These numbers all seem very close (apart from the baseline).  How many runs
did you do and what was the jitter?

Three runs, and I took the last value. Once the Windows cache is hot, the
numbers are very stable. The ThinLTO cache is not enabled, and I used
/opt:lldltojobs=all to extend the ThreadPool to all hardware threads.


> FWIW, I'm using snmalloc on FreeBSD instead of jemalloc and clang is
around 2% faster, so it might be worth considering this as an option for all
platforms.  It's likely to be a big win on anything where dlmalloc is the
default allocator.

I didn't mention, but the compile-time experience has was improved, in the
range of 5-10% depending on the file to compile. When using integrated
compilation, ie. all TUs compile in the same process, the gain is in the range
of 60%. But in that case there are other effects that come into play.


> I am obviously biased towards snmalloc, since I'm one of the authors,
and happy to help out anyone wanting to integrate it with LLVM.  Note that
snmalloc requires C++17, so would need to be conditional on LLVM being built
with a vaguely modern compiler.

snmalloc currently compiles as part of the LLVM codebase with a few
C++17-related constexpr warnings. However the contentious issue is the commit
size, which //could be// a showstopper for certain users. A runtime flag
-fno-integrated-crt-alloc could somehow mitigate this issue. However this only
exacerbates with high core count machines.

Peak commit when linking clang.exe with LLD and -flto on 36-core:

  Windows CRT heap allocator: 14.9 GB
  mimalloc: 19.8 GB
  rpmalloc: 31.9 GB
  snmalloc: 42 GB


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org