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

[Greg Chicares]

On 2015-12-30 01:10, Vadim Zeitlin wrote:
> On Tue, 22 Dec 2015 00:28:44 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> The bottom line:
> GC>   3:19 = 199s gcc-3.4.5, std=gnu++98
> GC>   7:32 = 452s gcc-4.9.2, std=c++03
> GC>   9:18 = 558s gcc-4.9.2, std=c++11

Normalizing my {199, 452, 558} gives
  100%
  227%
  280%
and I'll add a similar column to your table, showing its '-O2'
column as a percentage of {3.4.5, C++98}:

>                       Optimization level | -O0 | -O1 | -O2 |  -O2
> Compiler/C++ standard                    |     |     |     | added
> -----------------------------------------+-----+-----+-----+ by GWC
> MinGW 3.4.5 C++98                        | 101 |     | 115 |  100%
> Cygwin MinGW-w64 4.9.2 C++03             | 105 | 128 | 152 |  132%
> Cygwin MinGW-w64 4.9.2 C++11             | 150 | 175 | 186 |  162%
> Native MinGW-w64 4.9.2 C++03             |  88 | 116 | 118 |  103%
> Native MinGW-w64 4.9.2 C++11             | 126 | 146 | 158 |  137%
> -----------------------------------------+-----+-----+-----+

You aren't seeing as large a penalty as I am. But I'm using 32-bit
msw-xp, and I imagine you're using 64-bit msw-7, right? Then...
 (1) C++11 costs 22 or 23% more than C++03 for both of us;
 (2) for you, with gcc-4.9.2, cygwin costs 18% more than native;
 (3) {gcc-3.4.5, C++98} and {gcc-4.9.2, C++03} perform about the
     same for you, if you use native toolchains for both;
 (4) gcc-4.9.2 costs much more for me, and I suppose that must be
     due to a different pattern of resource demands--with 3.4.5,
     during the parallel compile phase, my VM kept all 16 CPUs
     fully loaded, and now that no longer happens.

> GC> Vadim, can you make any sense of my timing data above,
> 
>  Not really, but I suspect that the bottleneck might be XP handling of
> that many processes consuming so much RAM. Each compiler process eats up to
> 300MB of RAM here and I'd be surprised if XP were optimized at handling
> such workloads considering the typical amounts of RAM in the PCs in 2001
> when it was released.

Or the number of cores per CPU.

And qemu doesn't have a good msw-xp disk driver.

> Practically speaking, I'd advise you to either switch
> to a Windows 7 VM

I'd rather move away from non-free software...

> or to stop compiling under MSW entirely and cross-compile
> from Linux instead. I'd expect this to give results similar to the native
> MinGW builds.

Have you tried that yourself? I haven't yet--I'm on vacation the rest
of December. I have no doubt that it'll work; I just wonder how fast
it will be.

> GC> This (4.9.2) is the latest MinGW-w64 package that Cygwin offers (they
> GC> have 4.9.3 and 5.2.0 versions that target Cygwin, not MinGW). Here:
> GC>   http://sourceforge.net/projects/mingw-w64/
> GC> a 4.9.4-20151215 version is offered; would that native build be better
> GC> for us? (I'm not really sure how their Cygwin package differs.)
> 
>  As you can see, the answer is definitely yes. As you have already taken
> the trouble to set things up so that they work with both MinGW and Cygwin
> paths, switching to it looks like an obvious choice.

One notable advantage is that it should let us choose which gcc version
we all use. They seem to have numerous releases here:
  http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
whereas cygwin keeps only the last couple of releases of any package.
That will help my coworkers, who are using msw-7, and will presumably
experience about the same results as you. But as for me...

> OTOH it can (will?)
> probably still suffer from the same problem, whatever it is, in your VM, so
> maybe cross-compiling would still be a better option.

Yes, that's what I need to explore next, after vacation.