Re: [lmi] [PATCH] Trivial patch to avoid building unnecessary wxWidgets parts

[Greg Chicares]

On 2015-03-07 15:00, Vadim Zeitlin wrote:
> On Fri, 06 Mar 2015 21:27:36 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2015-03-06 18:19, Vadim Zeitlin wrote:
> GC> > On Fri, 06 Mar 2015 18:14:18 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> I don't seem to have recorded how long it took previously, but...
> GC> > 
> GC> >  Me neither exactly because it was too long to redo it again just to
> GC> > benchmark it. It takes less than 10 minutes now (inside my 2 CPU VM, I
> GC> > should probably give it 4 of them...) which is definitely a gain.
> GC> 
> GC> Please say exactly what you're doing that takes less than ten minutes.
> GC> Are you actually running the same command I gave:
> GC> 
> GC> /lmi/src/lmi[1]$time make wx_version=3.1.0 
> wx-3.1.0-md5=3c049ed2f470d81627ea5d513a06aa15 $coefficiency -f 
> install_wx.make >../log 2>&1
> 
[your result with zsd REPORTTIME:]
> make $coefficiency -f install_wx.make wx_version=3.1.0  -s  57.05s user 
> 146.03s system 36% cpu 9:13.59 total
[your result with "time":]
> make $coefficiency -f install_wx.make wx_version=3.1.0  -s  62.21s user 
> 159.18s system 39% cpu 9:25.09 total

What's your $coefficiency ? Mine is:
/lmi/src/lmi[0]$echo $coefficiency
--jobs=16

> GC> (which does something like 'make clean' first), and using a MinGW
> GC> gcc-3.4.5 toolchain? Does your "2 CPU VM" have two cores with that
> GC> function as four due to hyperthreading, one that functions as two
> GC> for the same reason, or two cores with hyperthreading turned off?
> 
>  But this is where the problem was, sorry for confusing you. I completely
> forgot (this must be the phrase I use the most in my correspondence...)
> that I had already increased the number of CPUs to 4, exactly because
> building wx inside the VM was so slow. So the numbers above are with 2
> (emulated) CPUs with 2 cores each, so 4 logical CPUs in all.
> 
>  FWIW VMware doesn't seem allow to configure hyperthreading, it probably
> isn't very advantageous for the VMs.

Okay, this task takes you nine or nine and a half minutes with four
logical CPUs, in a VM. I'm wondering how it can be that fast. Under
native msw-xp here, with all eight physical cores in use (sixteen if
we count hyperthreading, but we'll call it eight), I get:
 528.68s user 243.44s system 187% cpu 6:50.74 total
Seven minutes compared to your nine, but I use twice as many cores.
Mine are E5520 at 2.27 GHz, and yours are rather faster IIRC, but I
use twice as many--and I'm running msw native, while you're using
a VM, so I'd expect a bigger difference in our timings. What am I
missing? Different OS version? SSD? I'm using an HDD, but much
of the time CPU utilization stays at 1600% (hyperthreaded).

> GC> It's about half that speed in my VM:
> GC>  541.79s user 821.04s system 165% cpu 13:41.95 total

Compared to native msw, that's about half speed. FWIW, building
lmi runs at about five-eighths the speed of native ('configure'
imposes a larger drag on the wx build). My VM uses a raw file;
qemu's qcow2 format is much slower, and a physical partition
would probably be faster. The VM file is a limiting factor: when
I build lmi in the VM, CPU utilization sometimes hits 1600%, but
it doesn't stay there constantly.