Below are the corresponding numbers from a Mac, (Mac Pro (Late 2013),
3.7 GHz, Quad-Core Intel Xeon E5, 16 GB). To be clear, the -npch is
without precompiled headers. Here we see a slight degradation when
disabling on both user time and wall clock time. My guess is that the
user time increase is about the same, but because of a lower cpu count,
the extra load is not as easily covered.
These tests were run with just building hotspot. This means that the
precompiled header is generated alone on one core while nothing else is
happening, which would explain this degradation in build speed. If we
were instead building the whole product, we would see a better
correlation between user and real time.
Given the very small benefit here, it could make sense to disable
precompiled headers by default for Linux and Mac, just as we did with
ccache.
I do know that the benefit is huge on Windows though, so we cannot
remove the feature completely. Any other comments?
/Erik
macosx-x64
real 4m13.658s
user 27m17.595s
sys 2m11.306s
macosx-x64-npch
real 4m27.823s
user 30m0.434s
sys 2m18.669s
macosx-x64-debug
real 5m21.032s
user 35m57.347s
sys 2m20.588s
macosx-x64-debug-npch
real 5m33.728s
user 38m10.311s
sys 2m27.587s
macosx-x64-slowdebug
real 3m54.439s
user 25m32.197s
sys 2m8.750s
macosx-x64-slowdebug-npch
real 4m11.987s
user 27m59.857s
sys 2m18.093s
On 2018-10-30 14:00, Erik Joelsson wrote:
Hello,
On 2018-10-30 13:17, Aleksey Shipilev wrote:
On 10/30/2018 06:26 PM, Ioi Lam wrote:
Is there any advantage of using precompiled headers on Linux?
I have measured it recently on shenandoah repositories, and
fastdebug/release build times have not
improved with or without PCH. Actually, it gets worse when you touch
a single header that is in PCH
list, and you end up recompiling the entire Hotspot. I would be in
favor of disabling it by default.
I just did a measurement on my local workstation (2x8 cores x2 ht
Ubuntu 18.04 using Oracle devkit GCC 7.3.0). I ran "time make hotspot"
with clean build directories.
linux-x64:
real 4m6.657s
user 61m23.090s
sys 6m24.477s
linux-x64-npch
real 3m41.130s
user 66m11.824s
sys 4m19.224s
linux-x64-debug
real 4m47.117s
user 75m53.740s
sys 8m21.408s
linux-x64-debug-npch
real 4m42.877s
user 84m30.764s
sys 4m54.666s
linux-x64-slowdebug
real 3m54.564s
user 44m2.828s
sys 6m22.785s
linux-x64-slowdebug-npch
real 3m23.092s
user 55m3.142s
sys 4m10.172s
These numbers support your claim. Wall clock time is actually
increased with PCH enabled, but total user time is decreased. Does not
seem worth it to me.
It's on by default and we keep having
breakage where someone would forget to add #include. The latest
instance is JDK-8213148.
Yes, we catch most of these breakages in CIs. Which tells me adding
it to jdk-submit would cover
most of the breakage during pre-integration testing.
jdk-submit is currently running what we call "tier1". We do have
builds of Linux slowdebug with precompiled headers disabled in tier2.
We also build solaris-sparcv9 in tier1 which does not support
precompiled headers at all, so to not be caught in jdk-submit you
would have to be in Linux specific code. The example bug does not seem
to be that. Mach5/jdk-submit was down over the weekend and yesterday
so my suspicion is the offending code in this case was never tested.
That said, given that we get practically no benefit from PCH on
Linux/GCC, we should probably just turn it off by default for Linux
and/or GCC. I think we need to investigate Macos as well here.
/Erik
-Aleksey
