On 11/05/2018 05:46 PM, Erik Joelsson wrote:
>> If we decide to keep precompiled headers on by default, maybe we should add
>> a simple no-PCH
>> verification task in tier1? It only needs to build hotspot, so it should be
>> quick.
>>
> That is a good point, so sure we can do that. Which debug
On 2018-11-03 01:51, Magnus Ihse Bursie wrote:
On 2018-10-30 20:21, Erik Joelsson wrote:
Last I checked, it did provide significant build speed improvements
when building just hotspot, but that could need revisiting.
We do have verification of --disable-precompiled-headers (in
slowdebug) in
On 2018-10-30 20:21, Erik Joelsson wrote:
Last I checked, it did provide significant build speed improvements
when building just hotspot, but that could need revisiting.
We do have verification of --disable-precompiled-headers (in
slowdebug) in builds-tier2 so we normally get notified if
On 2018-11-02 15:00, Magnus Ihse Bursie wrote:
So obviously this is a nice improvement even here. I could probably
try around a bit and see if there is an even better fit with a
different selections of header files, but even without that, I'd say
this patch is by itself as good for clang as
On 2018-11-02 17:21, Erik Joelsson wrote:
Nice work!
What exactly are you measuring, "make hotspot" or some other target?
Yes, "make hotspot".
If we can find a reasonable set of extra files for the windows pch
that restores all or most of the performance, that would of course be
On 11/02/2018 12:14 PM, Magnus Ihse Bursie wrote:
> And here is the "winning" list (which I declared as "on or above 130, without
> inline"). I encourage
> everyone to try this on their own system, and report back the results!
>
> #ifndef DONT_USE_PRECOMPILED_HEADER
> # include
Nice work!
What exactly are you measuring, "make hotspot" or some other target?
If we can find a reasonable set of extra files for the windows pch that
restores all or most of the performance, that would of course be
preferable. I doubt we will find a significantly better selection on Mac
Hi Magnus,
your winning variant gives me a nice boost on my thinkpad:
pch, standard:
real17m52.367s
user52m20.730s
sys 4m53.711s
pch, your variant:
real15m0.514s
user46m6.466s
sys 2m38.371s
(non-pch is ~19-20 minutes WTC)
With those numbers, I might start using pch
On 2018-11-02 12:14, Magnus Ihse Bursie wrote:
Caveats: I have only run this on my local linux build with the default
server JVM configuration. Other machines will have different sweet
spots. Other JVM variants/feature combinations will have different
sweet spots. And, most importantly, I have
On 2018-11-02 11:39, Magnus Ihse Bursie wrote:
On 2018-11-02 00:53, Ioi Lam wrote:
Maybe precompiled.hpp can be periodically (weekly?) updated by a
robot, which parses the dependencies files generated by gcc, and pick
the most popular N files?
I think that's tricky to implement
On 2018-11-02 00:53, Ioi Lam wrote:
Maybe precompiled.hpp can be periodically (weekly?) updated by a
robot, which parses the dependencies files generated by gcc, and pick
the most popular N files?
I think that's tricky to implement automatically. However, I've done
more or less, that, and I've
On 2/11/2018 9:53 AM, Ioi Lam wrote:
Maybe precompiled.hpp can be periodically (weekly?) updated by a robot,
which parses the dependencies files generated by gcc, and pick the most
popular N files?
Do we need to use precompiled.hpp at all? Can we not use the list of
files contained in
Maybe precompiled.hpp can be periodically (weekly?) updated by a robot,
which parses the dependencies files generated by gcc, and pick the most
popular N files?
- Ioi
On 11/1/18 4:38 PM, David Holmes wrote:
It's not at all obvious to me that the way we use PCH is the
right/best way to use
It's not at all obvious to me that the way we use PCH is the right/best
way to use it. We dump every header we think it would be good to
precompile into precompiled.hpp and then only ask gcc to precompile it.
That results in a ~250MB file that has to be read into and processed for
every source
> 1 nov. 2018 kl. 17:49 skrev Erik Joelsson :
>
>> 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
>>>
Hello,
My point here, which wasn't very clear, is that Mac and Linux seem to
lose just as much real compile time. The big difference in these tests
was rather the number of cpus in the machine (32 threads in the linux
box vs 8 on the mac). The total amount of work done was increased when
PCH
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.
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
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?
Thanks
Ioi
> On Nov 1, 2018, at 5:09 AM, Magnus Ihse Bursie
> wrote:
>
>
>
>> On 2018-11-01 12:51, Thomas
I vote for disabling precompiled headers by default - they simply make the
build less reliable.
It seemed like precompiled headers did not work when using different
optimization levels for different source files, which in turn was needed
for building with clang, so I've been disabling precompiled
On 2018-11-01 12:51, Thomas Stüfe wrote:
On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie
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
On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie
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
> 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
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
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
On 2018-10-30 21: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
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
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
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,
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
Last I checked, it did provide significant build speed improvements when
building just hotspot, but that could need revisiting.
We do have verification of --disable-precompiled-headers (in slowdebug)
in builds-tier2 so we normally get notified if this fails. However,
Mach5 has not been
It would help already if Oracle would disable precompiled headers for
the submit test builds.
..Thomas
On Tue, Oct 30, 2018 at 6:26 PM Ioi Lam wrote:
>
> Is there any advantage of using precompiled headers on Linux? It's on by
> default and we keep having breakage where someone would forget to
I'd be in favour of disabling by default.
Roman
> Is there any advantage of using precompiled headers on Linux? It's on by
> default and we keep having breakage where someone would forget to add
> #include. The latest instance is JDK-8213148.
>
> I just turn on precompiled headers explicitly in
Is there any advantage of using precompiled headers on Linux? It's on by
default and we keep having breakage where someone would forget to add
#include. The latest instance is JDK-8213148.
I just turn on precompiled headers explicitly in all my builds. I don't
see any difference in build time
34 matches
Mail list logo
