lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Compiling takes longer with gcc-4.9.2


From: Greg Chicares
Subject: Re: [lmi] Compiling takes longer with gcc-4.9.2
Date: Thu, 31 Dec 2015 04:57:31 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-12-22 00:28, Greg Chicares wrote:
> My local tree contains makefile changes to use MinGW-w64 gcc-4.9.2,
> with '-std=c++11', some new warning flags, and various other
> adjustments.

Hardware change:
  old: dual    E5520  ; sata 6Gbps, SSD = samsung 850 pro
  new: dual E5-2630 v3; sata 3Gbps, HDD = wd caviar black WD2003FZEX
Same VM: 32-bit msw-xp, 16 vCPUs, 4096G RAM...however, the new machine
is centos7 with an updated libvirt, under which the guest OS reports
only 3.00GB RAM, not 3.50GB as I saw on the old machine (both use PAE),
so for these tests on the new machine I'm using
  --param ggc-min-expand=25 --param ggc-min-heapsize=32768
in CFLAGS and CXXFLAGS.

> First I compile wx and wxPdfDoc:
[...]
> make --jobs=8 -f install_wx.make > ../log 2>&1
> 2662.23s user 1594.59s system 475% cpu 14:55.38 total

I ran out of memory with eight cores, so I used six here:

make --jobs=6 -f install_wx.make > ../log 2>&1
1966.27s user 1080.01s system 389% cpu 13:02.98 total

> make --jobs=8 -f install_wxpdfdoc.make > ../log 2>&1
> 446.34s user 182.72s system 393% cpu 2:39.91 total

Here, the new machine is noticeably faster:

make --jobs=6 -f install_wxpdfdoc.make > ../log 2>&1
289.07s user 125.95s system 421% cpu 1:38.58 total

> Now I do a complete rebuild of lmi, which I very recently measured
> with mingw.org's native gcc-3.4.5 as follows:
> 
>   --jobs=16
> 15.89s user 26.48s system 21% cpu 3:18.89 total
>   --jobs=1
> 16.13s user 19.98s system 3% cpu 17:55.20 total
> 
> ...and here are results for MinGW-w64 gcc-4.9.2 as installed by
> lmi's current 'install_cygwin.bat' (package 'mingw64-i686-gcc-g++'):
[...snipping all but the best run, with four vCPUs...]
> make --jobs=4 install check_physical_closure > ../log 2>&1
> 1324.14s user 581.83s system 341% cpu 9:17.47 total

make --jobs=4 install check_physical_closure > ../log 2>&1
825.93s user 653.26s system 366% cpu 6:43.30 total
make --jobs=6 install check_physical_closure > ../log 2>&1
871.03s user 683.03s system 482% cpu 5:21.92 total
make --jobs=8 install check_physical_closure > ../log 2>&1
934.54s user 741.38s system 460% cpu 6:04.16 total

Building lmi itself was the most painful gcc-4.9.2 slowdown with the
old machine. The new machine is considerably faster than the old,
but even new hardware with gcc-4.9.2 can't compete with old hardware
and gcc-3.4.5 .

> I can't figure out why the best result comes from '--jobs=4'. If the
> number of CPUs isn't the bottleneck, what is? disk? RAM? CPU cache?

The hardware comparison suggests to me that it's not disk-bound or
CPU-bound. I guess it's just the 32-bit guest OS.

> If gcc-4.9.2 needs more RAM, this might help...
> 
>   --param ggc-min-expand=25 --param ggc-min-heapsize=32768
> make --jobs=4 install check_physical_closure > ../log 2>&1
> 1474.91s user 565.68s system 351% cpu 9:41.12 total

That's the best figure to compare, because I used those options
on the new machine.

Conclusion: gcc-4.9.2 should be used with a 64-bit OS; there's no
point in trying to breathe life into this old 32-bit VM.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]