On 02/07/2020 05:20, Alexandre Ganea via llvm-dev wrote: > Time to link clang.exe with LLD and -flto on 36-core: > > Â Windows CRT heap allocator: 38 min 47 sec > > Â mimalloc: 2 min 22 sec > > Â rpmalloc: 2 min 15 sec > > Â snmalloc: 2 min 19 sec These numbers all seem very close (apart from the baseline). How many runs did you do and what was the jitter? 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. Snmalloc currently supports macOS, Windows, Linux, FreeBSD, NetBSD, OpenBSD, Haiku, and OpenEnclave (adding other POSIXy systems is fairly trivial, can be completely trivial if you don't want any non-standard-POSIX behaviour) on x86, ARM, and PowerPC (RISC-V and MIPS under review). 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. David
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4