From nobody Sat Dec 6 17:42:57 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dNwZR0YJ1z6Hr8x for ; Sat, 06 Dec 2025 17:43:11 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dNwZQ3Bpqz3TLT for ; Sat, 06 Dec 2025 17:43:10 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5B6Hgvbo010181; Sat, 6 Dec 2025 19:43:00 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5B6Hgvbo010181 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5B6HgvJ7010180; Sat, 6 Dec 2025 19:42:57 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sat, 6 Dec 2025 19:42:57 +0200 From: Konstantin Belousov To: Mateusz Guzik Cc: FreeBSD Current Subject: Re: performance regressions in 15.0 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dNwZQ3Bpqz3TLT On Sat, Dec 06, 2025 at 06:34:01PM +0100, Mateusz Guzik wrote: > On Sat, Dec 6, 2025 at 6:31 PM Mateusz Guzik wrote: > > > > On Sat, Dec 6, 2025 at 6:25 PM Konstantin Belousov wrote: > > > > > > On Sat, Dec 06, 2025 at 11:50:08AM +0100, Mateusz Guzik wrote: > > > > II. compilation speed > > > > > > > > The the real and serious problem. Both versions of the system ship the > > > > same clang version: > > > > FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git > > > > llvmorg-19.1.7-0-gcd708029e0b2) > > > > Target: x86_64-unknown-freebsd14.3 > > > > Thread model: posix > > > > InstalledDir: /usr/bin > > > > > > > > FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git > > > > llvmorg-19.1.7-0-gcd708029e0b2) > > > > Target: x86_64-unknown-freebsd15.0 > > > > Thread model: posix > > > > InstalledDir: /usr/bin > > > > > > > > I found that compiling the will-it-scale suite about doubles in real > > > > time needed, along with doubling time spent in userspace. > > > > > > > > will-it-scale needs a little bit of massaging to work, diff at the end. > > > > > > > > check this out (repeabale): while true; do gmake -s clean && time > > > > gmake -s -j 8; done > > > > > > > > 14.3: > > > > gmake -s -j 8 8.93s user 2.03s system 769% cpu 1.42s (1.424) total > > > > gmake -s -j 8 9.02s user 2.16s system 757% cpu 1.48s (1.475) total > > > > gmake -s -j 8 9.29s user 1.95s system 774% cpu 1.45s (1.450) total > > > > gmake -s -j 8 8.97s user 2.46s system 770% cpu 1.48s (1.484) total > > > > gmake -s -j 8 9.13s user 2.30s system 773% cpu 1.48s (1.477) total > > > 14.3 clang/lld are probably statically linked, but I am not sure. > > > Can you confirm this? > > > > > > > They are dynamic, this was switched years ago. > > > > /usr/bin/clang: ELF 64-bit LSB executable, x86-64, version 1 > > (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for > > FreeBSD 14.3, FreeBSD-style, stripped > > > > ... but I do see a change in used .sos: > > /usr/bin/cc: > libz.so.6 => /lib/libz.so.6 (0x3d76fc831000) > libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0x3d76fcc0e000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x3d76fe213000) > libncursesw.so.9 => /lib/libncursesw.so.9 (0x3d76fd1ef000) > libthr.so.3 => /lib/libthr.so.3 (0x3d76ff8e5000) > libc++.so.1 => /lib/libc++.so.1 (0x3d76ff002000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x3d770073c000) > libm.so.5 => /lib/libm.so.5 (0x3d7701d4c000) > libc.so.7 => /lib/libc.so.7 (0x3d770161d000) > libelf.so.2 => /lib/libelf.so.2 (0x3d7701e58000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x3d770314a000) > libtinfow.so.9 => /lib/libtinfow.so.9 (0x3d7702808000) > [vdso] (0x3d76fc3cc000) > > vs > > /usr/bin/cc: > libprivateclang.so.19 => /usr/lib/libprivateclang.so.19 (0x311e43c00000) > libprivatellvm.so.19 => /usr/lib/libprivatellvm.so.19 (0x311e48000000) > libz.so.6 => /lib/libz.so.6 (0x311e4d1a9000) > libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0x311e430cf000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x311e4e075000) > libncursesw.so.9 => /lib/libncursesw.so.9 (0x311e4e7b3000) > libthr.so.3 => /lib/libthr.so.3 (0x311e4f717000) > libc++.so.1 => /lib/libc++.so.1 (0x311e502e0000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x311e5107d000) > libm.so.5 => /lib/libm.so.5 (0x311e52294000) > libc.so.7 => /lib/libc.so.7 (0x311e532a7000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x311e5414b000) > libelf.so.2 => /lib/libelf.so.2 (0x311e514d0000) > libtinfow.so.9 => /lib/libtinfow.so.9 (0x311e54751000) > libsys.so.7 => /lib/libsys.so.7 (0x311e563ff000) > [vdso] (0x311e419d5000) > > as in the 14 binary does not link to libprivateclang nor libprivatellm Well, yes, I mean, the internal llvm libc were linked statically in 14.3. This is where the count of relocations I posted comes from. > > > > > > > > > > > 15.0: > > > > gmake -s -j 8 19.90s user 3.02s system 773% cpu 2.96s (2.963) total > > > > gmake -s -j 8 19.90s user 3.18s system 774% cpu 2.98s (2.979) total > > > > gmake -s -j 8 20.24s user 2.90s system 770% cpu 3.00s (3.005) total > > > > gmake -s -j 8 19.92s user 3.25s system 771% cpu 3.00s (3.003) total > > > > gmake -s -j 8 20.25s user 2.95s system 772% cpu 3.01s (3.006) total > > > But 15.0 is definitely dynamically linked. > > > > > > clang is enormous C++ binary with enormous amount of relocs: > > > $ ldd /usr/bin/cc > > > /usr/bin/cc: > > > libprivateclang.so.19 => /usr/lib/libprivateclang.so.19 (0x27417e200000) > > > libprivatellvm.so.19 => /usr/lib/libprivatellvm.so.19 (0x274183e00000) > > > > > > $ objdump -R /usr/lib/libprivateclang.so.19 | wc -l > > > 232977 > > > $ objdump -R /usr/lib/libprivatellvm.so.19 | wc -l > > > 140712 > > > > > > > > > > > > > > user time *skyrocketed* > > >