7 ms·

Any idea of how much faster we're talking here?

• charcircuit 4y ago
  Around 10% faster. In D130810 the speedup is given as: Performance linking some programs with --threads=8 (glibc 2.33 malloc and mimalloc): - clang: 1.05x as fast with glibc malloc, 1.03x as fast with mimalloc - chrome: 1.04x as fast with glibc malloc, 1.03x as fast with mimalloc -internal search program: 1.08x as fast with glibc malloc, 1.05x as fast with mimalloc In D133003 the speedup is given as: Speed-up with mimalloc and --threads=8 on an Intel Skylake machine: - clang (Release): 1.27x as fast - clang (Debug): 1.06x as fast - chrome (default): 1.05x as fast - scylladb (default): 1.04x as fast Speed-up with glibc malloc and --threads=16 on a ThunderX2 (AArch64): - clang (Release): 1.31x as fast - scylladb (default): 1.06x as fast
  • jeffbee 4y ago
    That's fairly interesting about lld speedup. What I gather is it's faster if you build lld itself with mimalloc, and the reason they chose mimalloc was largely because it was easy or at least possible to integrate mimalloc with the project on supported platforms, and jemalloc or tcmalloc was harder. Which makes me wonder: will distro packages build it with mimalloc? Do they have to do something, or is on by default?
    • jeffbee 4y ago
      It appears that simply preloading either mimalloc or tcmalloc has a significant speedup for clang-16 and -15 for that matter. I wish these Linux systems came with better defaults! With mimalloc, a medium-sized C++ test repeatedly takes exactly 43.7s to build and link on this system, while with the default allocator it's all over the place from 46s to 49s. I would loosely characterize that as a free 10%.