On 2018-11-01 08:17, Magnus Ihse Bursie wrote:
On 2018-11-01 15:53, Ioi Lam wrote:
Just a stupid question. Does GCC have actual support for PCH? I know
windows can load pre-compiled information from a special binary file.
Does GCC support that kind of functionality?
Yes.
https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
But the Visual Studio compiler seems to be able to gain much more build
performance from it. I don't have fresh numbers but I definitely
remember a non PCH build on Windows taking more than double the time, if
not triple or quadruple.
/Erik
/Magnus
Thanks
Ioi
On Nov 1, 2018, at 5:09 AM, Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com> wrote:
On 2018-11-01 12:51, Thomas Stüfe wrote:
On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com> wrote:
On 2018-11-01 11:54, Aleksey Shipilev wrote:
On 11/01/2018 11:43 AM, Magnus Ihse Bursie wrote:
But then again, it might just signal that the list of headers
included in the PCH is no longer
optimal. If it used to be the case that ~100 header files were
so interlinked, that changing any of
them caused recompilation of all files that included it and all
the other 100 header files on the
PCH list, then there was a net gain for using PCH and no
"punishment".
But nowadays this list might be far too large. Perhaps there's
just only a core set of say 20 header
files that are universally (or almost universally) included, and
that's all that should be in the
PCH list then. My guess is that, with a proper selection of
header files, PCH will still be a benefit.
I agree. This smells like inefficient PCH list. We can improve
that, but I think that would be a
lower priority, given the abundance of CPU power we use to
compile Hotspot. In my mind, the decisive
factor for disabling PCH is to keep proper includes at all times,
without masking it with PCH. Half
of the trivial bugs I submit against hotspot are #include
differences that show up in CI that builds
without PCH.
So this is my ideal world:
a) Efficient PCH list enabled by default for development
pleasure;
b) CIs build without PCH all the time (jdk-submit tier1
included!);
Since we don't yet have (a), and (b) seems to be tedious,
regardless how many times both Red Hat and
SAP people ask for it, disabling PCH by default feels like a good
fallback.
Should just CI builds default to non-PCH, or all builds (that is,
should
"configure" default to non-PCH on linux)? Maybe the former is
better --
one thing that the test numbers here has not shown is if incremental
recompiles are improved by PCH. My gut feeling is that they really
should -- once you've created your PCH, subsequent recompiles will be
faster.
That would only be true as long as you just change cpp files, no? As
soon as you touch a header which is included in precompiled.hpp you
are worse off than without pch.
So the developer default should perhaps be to keep PCH, and we
should only configure the CI builds to do without PCH.
CI without pch would be better than nothing. But seeing how clunky and
slow jdk-submit is (and how often there are problems), I rather fail
early in my own build than waiting for jdk-submit to tell me something
went wrong (well, that is why I usually build nonpch, like Ioi does).
Just my 5 cent.
I hear you, loud and clear. :) I've created
https://bugs.openjdk.java.net/browse/JDK-8213241 to disable PCH by
default, for all builds, on gcc. (I'm interpreting "linux" in this
case as "gcc", since this is compiler-dependent, and not OS dependent).
/Magnus
..Thomas
/Magnus
-Aleksey
