Speed/latency issues for development in a Wine environment
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(a)beluga.phys.uvic.ca> To: wine-users(a)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(a)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(a)raven> time wine mingw32-make install >& make_install.out
real 20m13.421s ==> real 12m4.198s
Wine III. wine(a)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(a)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(a)raven> time make install >& make_install.out
real 2m12.805s Linux III.
wine(a)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 __________________________
On Thu, Jun 17, 2010 at 4:35 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
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(a)beluga.phys.uvic.ca> To: wine-users(a)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(a)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(a)raven> time wine mingw32-make install >& make_install.out
real 20m13.421s
==> real 12m4.198s
Wine III. wine(a)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(a)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(a)raven> time make install >& make_install.out
real 2m12.805s Linux III.
wine(a)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 __________________________
To make sure your numbers are somewhat consistent, you might want to do `wineserver -p; wine notepad` before tests to make sure the wineserver is loaded. It should help with timing of a single app startup, but probably won't help in the cmake case. Mike.
On 2010-06-17 17:07-0400 Mike Kaplinskiy wrote:
On Thu, Jun 17, 2010 at 4:35 PM, Alan W. Irwin
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. [...] 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?
To make sure your numbers are somewhat consistent, you might want to do `wineserver -p; wine notepad` before tests to make sure the wineserver is loaded. It should help with timing of a single app startup, but probably won't help in the cmake case.
I don't think I have access to notepad, but I assume that was just your template for any wine app I am timing. I agree timing results depend strongly on what has been previously cached in memory so the startup latency timing tests, I report e.g., wine(a)raven> time wine gcc --version gcc.exe (GCC) 4.5.0 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.143s user 0m0.088s sys 0m0.020s wine(a)raven> time wine lxxxx wine: cannot find L"C:\\windows\\system32\\lxxxx.exe" real 0m0.011s user 0m0.004s sys 0m0.008s wine(a)raven> time gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.001s user 0m0.000s sys 0m0.004s are all quoted for the second run of the command with "wineserver -p" running and with "export WINEDEBUG='all'" set. That typical difference between ~150 ms startup latency on wine versus ~1 ms startup latency on Linux is what I need to reduce in order to obtain reasonable build speeds on Wine. Ideas? 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 __________________________
On Friday 18 June 2010 03:05:08 am Alan W. Irwin wrote:
On 2010-06-17 17:07-0400 Mike Kaplinskiy wrote:
On Thu, Jun 17, 2010 at 4:35 PM, Alan W. Irwin
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. [...] 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?
To make sure your numbers are somewhat consistent, you might want to do `wineserver -p; wine notepad` before tests to make sure the wineserver is loaded. It should help with timing of a single app startup, but probably won't help in the cmake case.
I don't think I have access to notepad, but I assume that was just your template for any wine app I am timing. I agree timing results depend strongly on what has been previously cached in memory so the startup latency timing tests, I report e.g.,
wine(a)raven> time wine gcc --version gcc.exe (GCC) 4.5.0 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.143s user 0m0.088s sys 0m0.020s
wine(a)raven> time wine lxxxx wine: cannot find L"C:\\windows\\system32\\lxxxx.exe"
real 0m0.011s user 0m0.004s sys 0m0.008s
wine(a)raven> time gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.001s user 0m0.000s sys 0m0.004s
are all quoted for the second run of the command with "wineserver -p" running and with "export WINEDEBUG='all'" set. That typical difference between ~150 ms startup latency on wine versus ~1 ms startup latency on Linux is what I need to reduce in order to obtain reasonable build speeds on Wine.
Ideas?
Alan __________________________ Alan W. Irwin
Alan, Try to keep the wineserver initialized and running - for example keep a cmd.exe or notepad or something idle (in the same WINEPREFIX). To get more accurate timings run the test twice so the 2nd time the files should be cached in memory. If you are _sure_ you don't need a GUI you can unset DISPLAY (or run in a pure text console) so wine won't be able to create any windows. But the fact the X server matters suggests that some GUI components are used after all. Also please verify how fast gcc is to start on Windows, it may not be a wine problem. On Windows it is typically more expensive to start processes so Windows programs are usually more complex, do more tasks (eventually multithreaded) and live longer than the average UNIX program. Paul
Hi Paul: Thanks for your ideas on reducing the command startup latency. On 2010-06-18 10:48+0300 Paul Chitescu wrote:
Alan,
Try to keep the wineserver initialized and running - for example keep a cmd.exe or notepad or something idle (in the same WINEPREFIX).
I tried that by running wine cmd in another xterm (but the same WINEPREFIX) and left it idle at the command prompt rather than exiting. That made no significant difference to the startup latency timing results. I then tried the experiment of turning the wineserver off (wineserver -k). I double-checked that nothing was running wineserver by using "ps auxww". I also made sure there were no other idle wine commands running. For that experiment, the startup latencies still remained the same! So either I am not running wineserver properly (I use wineserver -p) or it makes absolutely no difference to simple commands that essentially do very little such as the three "--version" ones I am using to test startup latency.
To get more accurate timings run the test twice so the 2nd time the files should be cached in memory.
Always.
If you are _sure_ you don't need a GUI you can unset DISPLAY (or run in a pure text console) so wine won't be able to create any windows. But the fact the X server matters suggests that some GUI components are used after all.
The cmake and MinGW gcc and make commands are all pure command line. So I tried setting DISPLAY= and that actually made a small but significant reduction (a drop from near ~150 ms to ~125 ms on average for the --version option for those three commands) in the startup latency. Therefore, I think the conclusion must be that command startup under wine initializes GUI components even when they are not needed. I will test this hypothesis further by disabling X altogether by configuring a stripped-down build of wine and doing further command startup latency tests with that stripped-down version of wine.
Also please verify how fast gcc is to start on Windows, it may not be a wine problem. On Windows it is typically more expensive to start processes so Windows programs are usually more complex, do more tasks (eventually multithreaded) and live longer than the average UNIX program.
That would be a most interesting comparison. In computer terms 150 ms is an absolutely enormous time that allows something like 150 million (!) operations to occur on modern PC's. So I would be surprised if Microsoft Windows required that long to start up applications. However, I would need help from others here to report command startup times under Microsoft Windows since I don't have access to that platform. The average of the times to run the commands "gcc --version", "cmake --version", and "mingw32-make --version" should be a pretty good measure of command startup time. Ideally, of course, these Wine versus Microsoft Windows startup time comparisons should be made on the same box, but we are looking for orders of magnitude here (The Linux startup times are two orders of magnitude lower) so I don't think this strict "same box" requirement is necessary so long as the boxes are roughly the same (mine is a garden-variety dual-core Intel 2.4 GHz). 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 __________________________
On 18 June 2010 20:12, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
That would be a most interesting comparison. In computer terms 150 ms is an absolutely enormous time that allows something like 150 million (!) operations to occur on modern PC's. So I would be surprised if Microsoft Windows required that long to start up applications.
Creating processes on Windows is *expensive*. Do a "./configure;make;make install" natively in Cygwin for any piece of open source software and you'll be amazed how slow ./configure is to run. This is because ./configure works by making a source code file, compiling it in gcc and then running the resultant binary; this is easy on a Unix, very laborious on Windows. So I don't know, but I would be unsurprised if it's Wine doing all the stuff it has to do to pretend to be Windows. Cygwin runs under Wine. How does ./configure for a given program running on Cygwin on Wine compare to ./configure for the same program running on Cygwin on Windows on the same hardware? - d.
On Sat, Jun 19, 2010 at 11:00 AM, David Gerard <dgerard(a)gmail.com> wrote:
On 18 June 2010 20:12, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
That would be a most interesting comparison. In computer terms 150 ms is an absolutely enormous time that allows something like 150 million (!) operations to occur on modern PC's. So I would be surprised if Microsoft Windows required that long to start up applications.
Creating processes on Windows is *expensive*. Do a "./configure;make;make install" natively in Cygwin for any piece of open source software and you'll be amazed how slow ./configure is to run. This is because ./configure works by making a source code file, compiling it in gcc and then running the resultant binary; this is easy on a Unix, very laborious on Windows.
So I don't know, but I would be unsurprised if it's Wine doing all the stuff it has to do to pretend to be Windows.
Cygwin runs under Wine. How does ./configure for a given program running on Cygwin on Wine compare to ./configure for the same program running on Cygwin on Windows on the same hardware?
- d.
Since mingw isn't a cygwin application, what relevance does cygwin's sh and configure have here? It's a much more complicated beast. I think you would be right to say that creating processes in the cygwin environment is expensive, but otherwise if we should restrict the obersvation to mingw's gcc since that's what was mentioned: Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.020s user 0m0.000s sys 0m0.015s Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\gcc" "--version" gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps If we look at serial process creation with 1000 invocations of gcc --version #include <windows.h> #include <stdio.h> int main(void) { STARTUPINFO si; PROCESS_INFORMATION pi; char* proc = "c:\\mingw\\bin\\gcc.exe --version"; int i; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); for(i = 0; i < 1000;i++) { if(!CreateProcessA(NULL, proc, NULL,NULL, FALSE,0,NULL,NULL,&si,&pi)) { puts("fail\n"); } WaitForSingleObject(pi.hProcess, INFINITE); CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } return 0; } This takes 3.2 seconds on Windows Vista SP2 with output directed to nul, Intel Core 2 2.6GHz. 8 seconds under Wine (with wineserver already running) 1.2-rc3 with output directed to /dev/null. Intel Core 2 2.4GHz. If we test actual compiling, so gcc does some IO. Both mingw gcc 3.4.5, 50 iterations of compiling the following: #include <windows.h> #include <stdio.h> int main(void) { STARTUPINFO si; PROCESS_INFORMATION pi; char* proc = "c:\\mingw\\bin\\gcc.exe cp2.c -o cp2.exe"; int i; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); for(i = 0; i < 100;i++) { if(!CreateProcessA(NULL, proc, NULL,NULL, FALSE,0,NULL,NULL,&si,&pi)) { puts("fail\n"); } WaitForSingleObject(pi.hProcess, INFINITE); CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } return 0; } Windows: $ gcc cp2.c -o cp2bench.exe && time cp2bench.exe real 0m22.453s user 0m0.000s sys 0m0.000s Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine cmd "/c cp2bench.exe" 0.10user 0.02system 0:26.53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k I don't use cmake, so I'm not sure how that behaves, but otherwise mingw-gcc doesn't seem to have enough of a performance difference that would bother me. Jeff
Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below. On 2010-06-19 12:55+1000 Jeff Zaroyko wrote:
Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.020s user 0m0.000s sys 0m0.015s
Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\gcc" "--version" gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps
So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that? One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with "mingw32-make --version" and "gcc --version". "cmake --version" tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that? How about file systems? My experiments were done on ext3. What filesystem were you using on the box where you did the wine timing experiment? The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result? Other data here that may be relevant to the comparison with you: My hardware is 64-bit. Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries: irwin(a)raven> ldd /home/software/wine/install/bin/wine linux-gate.so.1 => (0xf77a2000) libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) libc.so.6 => /lib32/libc.so.6 (0xf74d3000) libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000) Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I switched to to building my own wine-1.2-rc3, but 150 ms with the latter just doesn't cut it compared to your 20 ms. Let me know if there is any additional comparison data I can provide. For me the important question is what is fundamentally different between our two software platforms or wine configurations that causes this order of magnitude difference in startup latency on similar hardware? 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 __________________________
On Sun, Jun 20, 2010 at 12:50 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below.
On 2010-06-19 12:55+1000 Jeff Zaroyko wrote:
Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.020s user 0m0.000s sys 0m0.015s
Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\gcc" "--version" gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps
So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that?
One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with "mingw32-make --version" and "gcc --version". "cmake --version" tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that?
Wine 1.2-rc3: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\mingw32-make.exe" "--version" GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 0.09user 0.02system 0:00.14elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+8432minor)pagefaults 0swaps Windows: $ time mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 real 0m0.030s user 0m0.015s sys 0m0.000s
How about file systems? My experiments were done on ext3. What filesystem were you using on the box where you did the wine timing experiment?
ext3 also
The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result?
Other data here that may be relevant to the comparison with you:
My hardware is 64-bit.
Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux
Likewise, but an older kernel: Linux genera 2.6.22-15-generic #1 SMP Fri Jul 11 18:56:36 UTC 2008 x86_64 GNU/Linux X.Org X Server 1.4.0.90 8GB of ram, 6GB of swap.
I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries:
irwin(a)raven> ldd /home/software/wine/install/bin/wine linux-gate.so.1 => (0xf77a2000) libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) libc.so.6 => /lib32/libc.so.6 (0xf74d3000) libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000)
Ubuntu 8.04 I've compiled from git with the default -O2. I'm running wine from the source directory as you may have noticed. jeffz(a)genera:~$ ldd git/wine/loader/wine linux-gate.so.1 => (0xffffe000) libwine.so.1 => /home/jeffz/git/wine/loader/../libs/wine/libwine.so.1 (0xf7deb000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7dd2000) libc.so.6 => /lib32/libc.so.6 (0xf7c83000) libdl.so.2 => /lib32/libdl.so.2 (0xf7c7f000) /lib/ld-linux.so.2 (0xf7f2d000)
Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I switched to to building my own wine-1.2-rc3, but 150 ms with the latter just doesn't cut it compared to your 20 ms.
Are you still compiling with -O3 here?
Let me know if there is any additional comparison data I can provide. For me the important question is what is fundamentally different between our two software platforms or wine configurations that causes this order of magnitude difference in startup latency on similar hardware?
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 __________________________
On 2010-06-20 11:16+1000 Jeff Zaroyko wrote:
On Sun, Jun 20, 2010 at 12:50 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below.
On 2010-06-19 12:55+1000 Jeff Zaroyko wrote:
Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.020s user 0m0.000s sys 0m0.015s
Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\gcc" "--version" gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps
So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that?
One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with "mingw32-make --version" and "gcc --version". "cmake --version" tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that?
Wine 1.2-rc3: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\mingw32-make.exe" "--version" GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program built for i386-pc-mingw32 0.09user 0.02system 0:00.14elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+8432minor)pagefaults 0swaps
Windows: $ time mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program built for i386-pc-mingw32
real 0m0.030s user 0m0.015s sys 0m0.000s
So for mingw32-make our wine startup latencies are essentially identical (near 150 ms) and substantially worse than the Windows numbers (30 ms) and much worse than the Linux numbers (~1 ms). "make" startup latency matters for builds configured by CMake because typically the top-level Makefile is configured in a way to run make many times per build. "cmake" startup latency also matters a lot because special modes for it are used during the build (typically two times per object file that is compiled by gcc) to figure out dependencies, keep track of progress, etc. If you are game for one more download (from http://cmake.org/cmake/resources/software.html) what are your cmake --version startup latency numbers? Of course, the gcc startup latency matters as well (for builds made with lots of different source files), but perhaps our numbers vary there because of our different MinGW gcc versions. If you are interested in trying the MinGW 4.5.0-1 compiler, it and its dependencies are available from http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem.
The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result?
I am still interested in that question.
Other data here that may be relevant to the comparison with you:
My hardware is 64-bit.
Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux
Likewise, but an older kernel: Linux genera 2.6.22-15-generic #1 SMP Fri Jul 11 18:56:36 UTC 2008 x86_64 GNU/Linux X.Org X Server 1.4.0.90 8GB of ram, 6GB of swap.
2GB ram, 6GB swap here.
I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries:
irwin(a)raven> ldd /home/software/wine/install/bin/wine linux-gate.so.1 => (0xf77a2000) libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) libc.so.6 => /lib32/libc.so.6 (0xf74d3000) libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000)
Ubuntu 8.04 I've compiled from git with the default -O2.
I'm running wine from the source directory as you may have noticed. jeffz(a)genera:~$ ldd git/wine/loader/wine linux-gate.so.1 => (0xffffe000) libwine.so.1 => /home/jeffz/git/wine/loader/../libs/wine/libwine.so.1 (0xf7deb000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7dd2000) libc.so.6 => /lib32/libc.so.6 (0xf7c83000) libdl.so.2 => /lib32/libdl.so.2 (0xf7c7f000) /lib/ld-linux.so.2 (0xf7f2d000)
Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I switched to to building my own wine-1.2-rc3, but 150 ms with the latter just doesn't cut it compared to your 20 ms.
Are you still compiling with -O3 here?
Yes. I will try -O2 also just to match as closely as possible to you, but I think that is a reach. In sum, you do have one rather large startup latency for mingw32-make that agrees with mine and which confirms the problem in that case and a much shorter startup latency for an old version of MinGW compared to mine. So the results are currently ambiguous, but we will find out more if you are willing to do the appropriate downloads of CMake and modern MinGW gcc. Thanks for your continuing help in narrowing down the factor(s) that are killing performance for CMake-based builds under Wine. 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 __________________________
On Sun, Jun 20, 2010 at 1:46 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
So for mingw32-make our wine startup latencies are essentially identical (near 150 ms) and substantially worse than the Windows numbers (30 ms) and much worse than the Linux numbers (~1 ms). "make" startup latency matters for builds configured by CMake because typically the top-level Makefile is configured in a way to run make many times per build.
"cmake" startup latency also matters a lot because special modes for it are used during the build (typically two times per object file that is compiled by gcc) to figure out dependencies, keep track of progress, etc. If you are game for one more download (from http://cmake.org/cmake/resources/software.html) what are your cmake --version startup latency numbers?
In sum, you do have one rather large startup latency for mingw32-make that agrees with mine and which confirms the problem in that case and a much shorter startup latency for an old version of MinGW compared to mine. So the results are currently ambiguous, but we will find out more if you are willing to do the appropriate downloads of CMake and modern MinGW gcc.
Thanks for your continuing help in narrowing down the factor(s) that are killing performance for CMake-based builds under Wine.
Alan
I'd test further but unfortunately it seems as though my video card (nvidia 8800) has bought the farm - no video signal at POST following a system freeze, which leaves me with only a Windows laptop. Jeff
participants (5)
-
Alan W. Irwin -
David Gerard -
Jeff Zaroyko -
Mike Kaplinskiy -
Paul Chitescu