[llvm-dev] RFC: Replacing the default CRT allocator on Windows (original) (raw)

Alexandre Ganea via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 2 08:15:51 PDT 2020

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

More information about the llvm-dev mailing list