https://bugs.kde.org/show_bug.cgi?id=490651
--- Comment #6 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
Note that I did at work some trials of building with and without lto, with
lto-partition=one and with the default lto partitioning,
with gcc (GCC) 12.3.1
on AMD Ryzen Threadripper PRO 5975WX 32-Cores
Red Hat Enterprise Linux release 8.8 (Ootpa)
(only the 64 bit valgrind version).
time (./autogen.sh; ./configure --prefix=`pwd`/install --enable-only64bit ;
make -j20 install; make regtest) 2>&1 | tee B.out
(in 3 different directories: lto+one, just lto, no lto.
I have not observed a significant difference for the build of valgrind itself
between the 2 lto versions:
Build with --enable-lto=yes (one partition) ("lto")
( ./autogen.sh; ./configure --enable-lto=yes --prefix=`pwd`/install ; make ;
760.16s user 113.95s system 63% cpu 23:01.57 total
tee B.out 0.01s user 0.05s system 0% cpu 23:01.57 total
Configuring+compiling+installing valgrind: 5 min 51 seconds (measured as the
timestamp difference between config.h.in and the include dir timestamp.
Build with --enable-lto=yes no partition argument i.e. default, ("ltodef")
Configuring+compiling+installing valgrind: 5 min 45 seconds.
( ./autogen.sh; ./configure --enable-lto=yes --prefix=`pwd`/install ; make ;
684.63s user 100.39s system 60% cpu 21:42.06 total
tee B.out 0.01s user 0.06s system 0% cpu 21:42.06 total
(note that in total, a non lto build has taken around 15:53 minutes, with 21
seconds for config/compile/install valgrind).
I suspect in fact that some tests are quite sensitive to timing and can
sometimes loop a lot longer and/or block during a long(er) time
So, unless I missed something, I do not observe a significant build time
difference between the 2 lto builds.
I re-measured with make clean and then only make install. Again both lto
builds were similar (5min51s vs 5min38s)
So I guess that if we want to decrease (a lot) the time to build+test valgrind,
we should parallelise the tests.
i.e. finish https://bugs.kde.org/show_bug.cgi?id=319307
Note also that I have not observed a huge difference in performance between the
"one lto" and the "balanced (default) lto",
so removing lto-partition=one is confirmed as not being a problem.
--
You are receiving this mail because:
You are watching all bug changes.
