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

[Vadim Zeitlin]

On Mon, 04 Jan 2016 02:59:23 +0000 Greg Chicares <address@hidden> wrote:

GC> >  I've redone the benchmarks on a Linux machine (this is a notebook with i7
GC> > 4712HQ with 16GiB RAM and 1TB SSD) to compare the relative speed of
GC> > compiling inside the VM and cross-compiling.
GC> 
GC> Is your VM...a msw-7 guest, in a vmware host?

 Yes, I've simply cloned my existing VM that I previously used under MSW
host and I'm using it now under Linux host with the (free (as the beer))
VMware player.

GC> > wxMSW build               Time (s)        Size (MB)       CPU use (%)
GC> > =========================================================================
GC> > MinGW 3.4.5               341               82
GC> > Cygwin 4.9.2              424              463            637
GC> > MinGW-w64 4.9.1           429              462
GC> > Debian 4.9.1              322              567            629
...
GC> > A half-surprise is that the native compiler is not faster than the
GC> > Cygwin one on this machine, unlike in my previous tests and I'm not
GC> > sure why is it so
GC> 
GC> That's so strange that I wonder whether the native and Cygwin compilers
GC> were built with similar options. A wild guess: maybe the native one
GC> targets a more conservative architecture, like i586.

 Just to be clear, these are the same compilers, in the same VM, under a
similar VM software just on a different host. I can't directly compare the
times for the builds on different hardware, so I don't know if it means
that VMware under MSW is "faster" or VMplayer under Linux is slower, but
something outside the VM must be affecting this.

GC> By "The only regression", I take it that you mean:
GC>   MinGW 3.4.5   341s   82MB
GC>   Debian 4.9.1  269s  136MB <-- 54 MB more
GC> but, as you say, that's not a problem at all: I'd gladly trade 54MB for
GC> a one-minute improvment in build time.

 Yes, exactly.

GC> I anticipate that I'll be building in tmpfs,

 FWIW I tried building wxGTK in tmpfs and saw absolutely no gains, which
would seem to be another argument proving that the build is CPU bound for
me (or, alternatively, that Linux IO is good enough to use RAM for cache
effectively enough even when not using tmpfs).

GC> But still, it's more than ten times as big with PCH. Does that suggest
GC> that gcc's implementation of PCH isn't very good, at least with C++?

 I'm afraid it says more about wxWidgets build system than gcc. In the
multilib build we create a PCH for each library which is very wasteful,
ideally we would use only a single one or, at worst, two (one for the
non-GUI stuff and another for the GUI). Each GUI library PCH file is ~100MB
which is not unexpected, as it corresponds to a lot of precompiled code,
but it's the fact that we multiply this by 15 which is really annoying.

GC> Does msvc have such enormous disk overhead with PCH?

 Yes, PCH files are also quite big with MSVC, although they're smaller (35
and 76MB for base and core respectively, compared to 63 and 92 for gcc).
 
GC> IIRC, we chose 'monolithic' to solve some awful problem. Let's see...here's
GC> the earliest reference on the mailing list:
GC>   http://lists.nongnu.org/archive/html/lmi/2005-08/msg00008.html
GC> It had to do with passing exceptions across dll boundaries.

 Oops, I completely forgot about this, thanks for the reminder.

GC> I guess libstdc++ is a shared library now, so perhaps that problem no longer
GC> exists.

 Yes, this is what I think too.

GC> > Notice that it would also be worth using --without-opengl configure option
GC> > in either case as lmi doesn't wxGLCanvas, but this is a small gain.
GC> 
GC> But that's a small, safe change, so it's probably worthwhile.

 Should I commit the addition of --without-opengl and
--disable-precomp-headers to install_wx.make then or will you do it?

GC> >  So C++11 support doesn't come for free, in build time terms. I'd still
GC> > like to enable it because it brings important benefits in terms of
GC> > development time, i.e. productivity.
GC> 
GC> I agree.

 Great!

GC> Perhaps I can eventually use '-fuse-ld=gold'

 This definitely should help but I didn't have time to benchmark it yet.

GC> I haven't even tried cross-compiling lmi yet. It would be enormously helpful
GC> to me if you could figure out how to make that work.

 I'll post my notes soon.
VZ