Stop using precompiled headers for Linux?
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Thu Nov 1 10:38:20 UTC 2018
On 2018-10-31 00:54, Erik Joelsson wrote:
> 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
> I do know that the benefit is huge on Windows though, so we cannot
> remove the feature completely. Any other comments?
Well, if you show that it is a loss in time on macosx to disable
precompiled headers, and no-one (as far as I've seen) has complained
about PCH on mac, then why not keep them on as default there? That the
gain is small is no argument to lose it. (I remember a time when you
were hunting seconds in the build time ;-))
On linux, the story seems different, though. People experience PCH as a
problem, and there is a net loss of time, at least on selected testing
machines. It makes sense to turn it off as default, then.
> real 4m13.658s
> user 27m17.595s
> sys 2m11.306s
> real 4m27.823s
> user 30m0.434s
> sys 2m18.669s
> real 5m21.032s
> user 35m57.347s
> sys 2m20.588s
> real 5m33.728s
> user 38m10.311s
> sys 2m27.587s
> real 3m54.439s
> user 25m32.197s
> sys 2m8.750s
> real 4m11.987s
> user 27m59.857s
> sys 2m18.093s
> On 2018-10-30 14:00, Erik Joelsson wrote:
>> 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.
>> real 4m6.657s
>> user 61m23.090s
>> sys 6m24.477s
>> real 3m41.130s
>> user 66m11.824s
>> sys 4m19.224s
>> real 4m47.117s
>> user 75m53.740s
>> sys 8m21.408s
>> real 4m42.877s
>> user 84m30.764s
>> sys 4m54.666s
>> real 3m54.564s
>> user 44m2.828s
>> sys 6m22.785s
>> 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.
More information about the build-dev