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

[Greg Chicares]

On 2015-12-22 01:33, Vadim Zeitlin wrote:
> On Tue, 22 Dec 2015 00:28:44 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> It takes three times as long, which is not an argument in favor of
> GC> upgrading. Can we improve the build time?
> 
>  I am pretty sure that using PCH will do it.

IIRC, you worked on an lmi PCH patch a long time ago, but found that it
wasn't worthwhile for gcc-3.4.5 . Do you happen to know whether there's
a working patch in our email archives?

> GC> I can't figure out why the best result comes from '--jobs=4'. If the
> GC> number of CPUs isn't the bottleneck, what is? disk? RAM? CPU cache?
> 
>  No idea neither. All I can say is that for me all 8 virtual CPUs are
> consistently pegged during the compilation stage while the linking stage
> (which is quite long) only runs on a single CPU but also consumes maximal
> amount of disk bandwidth, so I don't even know what limits it more.

I can't understand it. I've always been able to peg sixteen vCPUs during
compilation, and now I can hardly peg four. I guess either 4.9.2 needs an
unusual amount of memory or storage bandwidth, or the cygwin cross compiler
is less efficient than MinGW-w64's native build.

> 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
> 
>  I'm afraid these numbers have to be just accepted.

Please tell me it'll be much better if I cross-compile lmi from GNU/Linux
using tmpfs. (Do you happen to do that already?)

> IME every new version
> of g++ is slightly slower than the next previous one and apparently this is
> what such cumulative slowdown results in, over 10 years. I suspect the
> difference might be smaller with -O0 instead of -O2 as gcc optimizer has
> become vastly more sophisticated (and hence time consuming) since gcc3
> days, perhaps you could use -O0 while developing?

Last time I tried that, numerical test results with -O0 differed. But I
could take another look.

> If not, I think only the
> PCH can save us.

I'll cross my fingers. And throw new hardware at the problem.

> 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.)
> 
>  Yes, it probably would, Cygwin emulation does have its overhead, but I
> don't know by how much. I could try if you'd like to and are not already
> doing this.

Yes, I'd appreciate it if you would give that a try and share your findings,
as I've already spent an awful lot of time on this and I'm on "vacation" now.
I understand what you say here:

http://wxwidgets.blogspot.com/2011/06/choosing-gcc-for-building-wxwidgets.html
| [people] tried to use native MinGW compilers under Cygwin and this could be
| made to work but was so painful because you had to painstakingly ensure that
| both MinGW compiler and Cygwin tools could understand the paths you used
| (which basically meant that only relative paths could be really used as
| absolute paths take different forms for Windows-based MinGW compiler and
| Cygwin-based tools) that I could never wholeheartedly recommend it.

and can apply that to my situation in one of two ways:

(1) I've made it work perfectly well with mingw.org tools, so maybe it'll
be easy with MinGW-w64's native distribution; or

(2) adapting that work to a new toolchain brings new challenges, and no one
wants to go through that twice.

Before attempting this, it would be good to know how much of the slowdown
is due to the cross-compiler's Cygwin dependency.