LKML Archive on lore.kernel.org
 help / color / 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
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 index

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 ` 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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git