On Tue, Jul 20, 2021 at 2:11 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jul 20, 2021 at 1:52 PM Nick Desaulniers > <ndesaulniers@xxxxxxxxxx> wrote: > > > > > -CC = $(CROSS_COMPILE)gcc > > > +CC = $(CROSS_COMPILE)clang > > > > So you haven't been using LLD... :( (imagine using more than one > > thread to link, and being faster than ld.gold) > > I started out just building my own clang - nothing else. > > And now that I'm using the distro clang, the linker isn't even _close_ > to a performance issue. Since clang is a big, slow, bloated pig. > > I posted profiles and performance numbers of clang being three times > slower than gcc, and it was all just clang itself, not the linker. All > due to insanely expensive startup costs. Yeah, it's unfortunate that package maintainers for your distro chose to distribute clang built in such a manner. But in response to that thread: 1. I planned a whole conference around how folks distribute LLVM (particularly how the configurations are done, and important ones to use): https://lists.llvm.org/pipermail/llvm-dev/2021-June/150861.html We have a pretty good set of CFPs lined up (and I need to go chase folks from Apple and Qualcomm that are working on proposals...) https://github.com/ClangBuiltLinux/llvm-distributors-conf-2021/issues 2. I brainstormed a whole set of ways to make Clang even faster. https://github.com/ClangBuiltLinux/tc-build/issues Most promising I think would be building musl with LTO and statically linking that into the toolchain. I don't have a ton of time to pursue that, but I will continue to bang on that drum in front of management. It's just very hard to fund improving build times for users on thinkpads when the corporate world has moved on to distributed and cached building in the cloud. 3. Pretty sure we've resolved that config with your distro's packager, and made other changes to upstream LLVM to default on some flags that help a lot when those unfortunate configs are used. https://reviews.llvm.org/D102090 > I suspect a lot of clang users build bloated C++ code where the time > to compile a single object file is so big that the startup costs don't > even show up. But for the (fairly) lean C kernel header files that > don't bring in millions of lines of headers for some template library, > startup costs are a big deal. > > So honestly, I don't care at all about "imagine being faster than ld.gold". > > I can only _dream_ of clang itself not being 3x slower than gcc. Let's be precise here, because quotes (even when imprecise) lead to PR cycles. Clang startup time for NULL input when testing command line flags as part of a build configure step, when clang is misconfigured is slower than GCC. Clang is not generally 3x slower than GCC. -- Thanks, ~Nick Desaulniers
