All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	masahiroy@kernel.org, michal.lkml@markovi.net
Subject: Re: [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
Date: Fri, 21 Feb 2020 23:01:24 -0500	[thread overview]
Message-ID: <1582341758.yo66djba3t.none@localhost> (raw)
In-Reply-To: <20200222021619.GA51223@ubuntu-m2-xlarge-x86>

Excerpts from Nathan Chancellor's message of February 21, 2020 9:16 pm:
> Hi Alex,
> 
> On Fri, Feb 21, 2020 at 07:38:20PM -0500, Alex Xu (Hello71) wrote:
>> -pipe reduces unnecessary disk wear for systems where /tmp is not a
>> tmpfs, slightly increases compilation speed, and avoids leaving behind
>> files when gcc crashes.
>> 
>> According to the gcc manual, "this fails to work on some systems where
>> the assembler is unable to read from a pipe; but the GNU assembler has
>> no trouble". We already require GNU ld on all platforms, so this is not
>> an additional dependency. LLVM as also supports pipes.
>> 
>> -pipe has always been used for most architectures, this change
>> standardizes it globally. Most notably, arm, arm64, riscv, and x86 are
>> affected.
>> 
>> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
> 
> Do you have any numbers to show this is actually beneficial from a
> compilation time perspective? I ask because I saw an improvement in
> compilation time when removing -pipe from x86's KBUILD_CFLAGS in
> commit 437e88ab8f9e ("x86/build: Remove -pipe from KBUILD_CFLAGS").
> 
> For what it's worth, clang ignores -pipe so this does not actually
> matter for its integrated assembler.
> 
> That type of change could have been a fluke but I guarantee people
> will care more about any change in compilation time than any of the
> other things that you mention so it might be wise to check on major
> architectures to make sure that it doesn't hurt.
> 
> Cheers,
> Nathan
> 

Sorry, I should've checked the performance first. I have now run:

cd /tmp/linux # previously: make O=/tmp/linux
export MAKEFLAGS=12 # Ryzen 1600, 6 cores, 12 threads
make allnoconfig
for i in {1..10}; do
    make clean >/dev/null
    time make XPIPE=-pipe >/dev/null
    make clean >/dev/null
    time make >/dev/null
done

after patching -pipe to $(XPIPE) in Makefile.

Results (without ld warnings):

make > /dev/null  130.54s user 10.41s system 969% cpu 14.537 total
make XPIPE=-pipe > /dev/null  129.83s user 9.95s system 977% cpu 14.296 total
make > /dev/null  129.73s user 10.28s system 966% cpu 14.493 total
make XPIPE=-pipe > /dev/null  130.04s user 10.63s system 986% cpu 14.252 total
make > /dev/null  129.53s user 10.28s system 972% cpu 14.379 total
make XPIPE=-pipe > /dev/null  130.29s user 10.17s system 983% cpu 14.288 total
make > /dev/null  130.19s user 10.52s system 968% cpu 14.530 total
make XPIPE=-pipe > /dev/null  129.90s user 10.47s system 978% cpu 14.343 total
make > /dev/null  129.50s user 10.81s system 959% cpu 14.620 total
make XPIPE=-pipe > /dev/null  130.37s user 10.60s system 975% cpu 14.446 total
make > /dev/null  129.63s user 10.18s system 972% cpu 14.374 total
make XPIPE=-pipe > /dev/null  131.29s user 9.92s system 1016% cpu 13.899 total
make > /dev/null  129.96s user 10.39s system 961% cpu 14.596 total
make XPIPE=-pipe > /dev/null  131.63s user 10.16s system 1011% cpu 14.015 total
make > /dev/null  129.33s user 10.54s system 970% cpu 14.405 total
make XPIPE=-pipe > /dev/null  129.70s user 10.40s system 976% cpu 14.349 total
make > /dev/null  129.53s user 10.25s system 964% cpu 14.494 total
make XPIPE=-pipe > /dev/null  130.38s user 10.62s system 973% cpu 14.479 total
make > /dev/null  130.73s user 10.08s system 957% cpu 14.704 total
make XPIPE=-pipe > /dev/null  130.43s user 10.62s system 985% cpu 14.309 total
make > /dev/null  130.54s user 10.41s system 969% cpu 14.537 total

There is a fair bit of variance, probably due to cpufreq, schedutil, CPU 
temperature, CPU scheduler, motherboard power delivery, etc. But, I 
think it can be clearly seen that -pipe is, on average, about 0.1 to 0.2 
seconds faster.

I also tried "make defconfig":

make > /dev/null  1238.26s user 102.39s system 1095% cpu 2:02.33 total
make XPIPE=-pipe > /dev/null  1231.33s user 102.52s system 1081% cpu 2:03.29 total
make > /dev/null  1232.92s user 102.07s system 1096% cpu 2:01.71 total
make XPIPE=-pipe > /dev/null  1239.59s user 102.30s system 1096% cpu 2:02.39 total
make > /dev/null  1229.81s user 101.72s system 1093% cpu 2:01.74 total
make XPIPE=-pipe > /dev/null  1234.64s user 101.30s system 1098% cpu 2:01.64 total
make > /dev/null  1228.50s user 104.39s system 1093% cpu 2:01.91 total
make XPIPE=-pipe > /dev/null  1238.78s user 102.57s system 1099% cpu 2:01.99 total
make > /dev/null  1238.26s user 102.39s system 1095% cpu 2:02.33 total

I stopped after this because I needed to use the machine for other 
tasks. The results are less clear, but I think there's not a big 
difference one way or another, at least on my machine.

CPU: Ryzen 1600, overclocked to ~3.8 GHz
RAM: Corsair Vengeance, overclocked to ~3300 MHz, forgot timings
Motherboard: ASRock B450 Pro4

I would speculate that the recent pipe changes have caused a change in 
the relative speed compared to 2018. I am using 5.6.0-rc2 with -O3 
-march=native patches.

Regards,
Alex.

  reply	other threads:[~2020-02-22  4:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200222003820.220854-1-alex_y_xu.ref@yahoo.ca>
2020-02-22  0:38 ` [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS Alex Xu (Hello71)
2020-02-22  2:07   ` Masahiro Yamada
2020-02-22  9:01     ` Russell King - ARM Linux admin
2020-02-22  2:16   ` Nathan Chancellor
2020-02-22  4:01     ` Alex Xu (Hello71) [this message]
2020-02-22  8:01       ` Nathan Chancellor
2020-02-22 14:24         ` Alex Xu (Hello71)
2020-02-22 18:12           ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1582341758.yo66djba3t.none@localhost \
    --to=alex_y_xu@yahoo.ca \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=natechancellor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.