Re: [lmi] Retooling: timing comparison

[Vadim Zeitlin]

On Mon, 8 Feb 2016 02:19:33 +0000 Greg Chicares <address@hidden> wrote:

GC> We've just tested a new set of tools:
GC>  - the latest Cygwin
GC>  - MinGW-w64 gcc-4.9.1
GC> on machines in the office, and everything seems to have gone well
GC> except for this nuisance:
GC>   http://lists.nongnu.org/archive/html/lmi/2016-01/msg00092.html
GC> due to corporate antimalware. It is interesting to compare timings:
GC> 
GC>     -begin stamp--     --end stamp--- min   %
GC> log-20160129T1600Z-gwc 20160129T1719Z  79 100%
GC> log-20160128T1527Z-wab 20160128T1757Z 150 190%
GC> log-20160128T2207Z-wab 20160129T0034Z 147 186%
GC> log-20160129T1642Z-kmm 20160129T1942Z 180 228%
GC> log-20160120T1933Z-gwc 20160120T2017Z  44  56% --jobs=6'
GC> log-20160130T0038Z-gwc 20160130T0121Z  43  54% --jobs=6'
GC> log-20160130T2115Z-gwc 20160130T2158Z  43  54% --jobs=4'
GC> log-20160131T1406Z-gwc 20160131T1500Z  54  68% --jobs=2'
GC> log-20160130T2335Z-OLD 20160131T0039Z  64  81% --jobs=2
GC> log-20160201T1951Z-kmm 20160201T2152Z 121 153% --jobs=2
GC> log-20160202T2007Z-kmm 20160202T2141Z  94 119% --jobs=4
GC> log-20160204T2216Z-gwc 20160204T2258Z  42  53% --jobs=4
GC> log-20160206T0108Z-gwc 20160206T0151Z  43  54% --jobs=6
GC> log-20160206T0155Z-gwc 20160206T0239Z  44  56% --jobs=4
...
GC> The "gwc" machine is 2 x E5-2630 v3 with a 1TB Samsung 850 pro SSD.
GC> The "OLD" (2009) machine is 2 x E5520 with a 2TB WDC WD2003FZEX HDD.
GC> Both these machines were running msw-xp in a kvm-qemu VM, hosted by
GC> debian-7.

 I just don't understand these results at all :-( Leaving aside the office
machines which have much slower disks, the fact that you gain only 10
minutes or ~15% when switching from "OLD" to "gwc" with -j2 is just
incomprehensible. Whether the bottleneck is IO or CPU, you should have
gained more than this.

GC> The other machines have i7-2600 (not i7-2600K) CPUs, with 250GB
GC> Hitachi HDS721025CLA682 HDDs, running 64-bit msw-7.
GC> 
GC> All machines have more RAM than these tests could use.

 Interesting, I'd expect a machine with one of the cheapest 250GB drives
from 5 years ago to have a commensurate amount of RAM, i.e. 1 or 2GB at
most. Are you really sure they don't swap (Resource Monitor, included in
MSW 7, could be used to check for this)? This would explain their pretty
results (1.5 hours to compile is just horrible).

GC> To round out the comparison, here are timings for cross-building
GC> msw binaries. Same compiler; same script and makefiles as above,
GC> with just enough adjustments to get them to run in a debian-8 chroot:
...
GC>     --jobs=32
GC>   3238.23s user 175.19s system 1605% cpu 3:32.59 total

 This, at least, is reasonable. 3.5 minutes is still a bit long, but
certainly much more bearable than 1.5 hours...

GC> The biggest difference is the operating system: msw with aftermarket
GC> security added on, versus GNU/Linux (with security built in).

 If the antivirus really scans all the object files produced by the build,
it could indeed explain poor performance, but can they really be so dumb?
Maybe it's possible to exclude the directory used for building from the
antivirus checks?

 Regards,
VZ