To introduce myself to this list, I am a complete Wine newbie with no Windows experience at all, but I do have years of experience developing software on Linux, and in the interests of testing that software on a free Windows platform, I have recently been using the combination of Windows native versions of MinGW and CMake to build and test applications and libraries under Wine. That is, I run a Windows version of cmake under wine to configure Makefiles followed by running a Windows version of MinGW make under Wine (which in turn runs MinGW gcc and other applications under Wine to build and test the software).
So far this idea is going rather well, but I have run into some issues which I have been reporting on the wine-users mailing list. I find such preliminary discussion useful to help prepare a good bug report, but following a suggestion from Alexandre Julliard, I am moving the discussion of these issues here.
Since at least some of you have already seen my posts on wine-users, I will only summarize the issues as I currently see them.
The rest of this post concerns a slow software build issue I have discovered under Wine, and I will deal with a second issue in a later post.
The issue is that Wine builds of software take roughly a factor of 5 longer than the equivalent Linux builds. This issue appears to be caused mostly by command startup latency. What I mean by that phrase is
wine cmake --version
(and the "--version" option for many commands you can run under wine) take roughly 150 ms (with wine-1.2-rc3 built with the -O3 option and running that wine version with WINEDEBUG='-all' and wineserver -p) to complete while Linux versions of the same commands require 1 ms to complete.
It is a startup latency in the commands run under wine rather than a startup latency issue with the wine command itself because that command returns much faster than 150 ms if you give it an unknown command.
Because many thousands of commands (e.g., "gcc"; several "cmake -E" variants per gcc command to help report progress; figure out dependencies, etc.; and various further make commands generated by the initial make command) are used to complete a typical build (say of cmake itself or PLplot), the startup latency for each of those commands accumulates and is a major factor which slows down the build (by roughly a factor of 5) compared to the equivalent Linux build. So a reduction of the command startup latency under Wine by an order of magnitude should largely solve the problem.
I find the command startup latency depends very much on what X server I am using. Of course, the actual commands I am using (cmake, MinGW make, MinGW gcc, etc.) to build software under wine have nothing to do with X. So I am hoping if I build a stripped down version of wine configured to ignore X and all other systems (sound, etc.) that are not required for builds, then I might achieve the reduced command startup latency that I need.
Before I try that, however, is there some less brute-force way to reduce command startup latency?
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
---------- Forwarded message ---------- Date: Sat, 12 Jun 2010 14:10:31 -0700 (PDT) From: Alan W. Irwin irwin@beluga.phys.uvic.ca To: wine-users@winehq.org Subject: Re: [Wine] Speed/latency issues for development in a Wine environment
On 2010-06-11 18:09-0700 Alan W. Irwin wrote:
The previous timing numbers were done with wine-1.1.42. Following a suggestion made off-list to me, I have built wine-1.2-rc3 today (with CFLAG=-O3) and immediately noticed the start-up latency for simple commands (e.g., cmake --version) was reduced from about 0.25 s to about 0.15 s. I don't know how the previous Debian wine-1.1.42 packages were optimized so that difference may just be due to an optimization difference or an actual improvement in the Wine code from 1.1.42 to 1.2-rc3. However, to see how -O3 optimized wine-1.2-rc3 does with the full tests, I have redone my timing tests for I. (cmake), II (make install), and III (make install latency) and the following reductions have been observed.
Wine I. wine@raven> time wine cmake -G "MinGW Makefiles" \ "-DCMAKE_INSTALL_PREFIX=z:/home/wine/cmake/install1" \ z:/home/software/cmake/cmake-2.8.1_patched/ >& cmake.out
real 14m17.124s
==> real 8m18.041s
Wine II.
wine@raven> time wine mingw32-make install >& make_install.out
real 20m13.421s
==> real 12m4.198s
Wine III. wine@raven> time wine mingw32-make install >& make_install.out1
real 1m39.018s
==> real 0m51.045s
For reference here are the corresponding Linux numbers which are still much better than the corresponding Wine-1.2-rc3 results.
Linux I.
wine@raven> time cmake -G "Unix Makefiles" \ "-DCMAKE_INSTALL_PREFIX=/home/wine/cmake/install_linux" \ /home/software/cmake/cmake-2.8.1_patched/ >& cmake.out
real 0m34.015s Linux II.
wine@raven> time make install >& make_install.out
real 2m12.805s Linux III.
wine@raven> time make install >& make_install.out1
real 0m0.869s
To summarize these findings, it appears that changes in startup latency for simple commands strongly correlates with timing results for build steps I, II, and III on Wine. This makes sense since we know that several thousand commands are run for, e.g., build step II so startup latency of hundreds of milliseconds per command must be a real build performance killer.
So what can be done to reduce the simple startup latency from the current ~150 ms on Wine down much closer to the Linux startup latency for the same commands which is typically 1 ms? Simple commands requiring 150 ms to start must have an awful lot of extra start baggage. Is all that baggage really needed for command-line commands such as cmake, mingw32-make, gcc, etc.?
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________