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

[Alexandre Ganea via llvm-dev]

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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev