Ralf Wildenhues wrote: > * Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET: >> [...] EVERY separate patchset requires an independent full testsuite >> run. Until recently, that was 5 hours of sitting in front of my >> computer waiting for popups, while that computer was completely useless >> for anything else (100% cpu). > > That is horrible. May I ask what kind of CPU you have, and which Cygwin > version?
Core2Duo T5450 (1.66GHz) Vista 32bit Home Cygwin-1.5.25 or 1.7.38 (parallel installs; speed more or less the same) Vista @ 1.66G x 2 cores (my current laptop) seems to be about the same speed as XP @ 433MHz x 1 core (my previous laptop) -- in general, /not/ cygwin-specific. Sad, isn't it? What I try to do now is run long-running stuff on the "old" laptop since it's still humming away in the corner...but I don't have cygwin-1.7 installed on that one. > Can you work on a Linux system with Wine, for at least those > changes for which the difference shouldn't matter that much? Can you > work on a GCC cfarm system for those tests where Cygwin isn't a premium, > and ask the people running the mingw-w64 system for an account to test > there? Sure, I can always run tests on a linux system; that would ensure that any changes I make don't break linux; this tells me nothing about *cygwin*. Unfortunately, wine won't really help, as it'd still go thru the cygwin layer, THEN the wine (not-an-) emulator layer, before the splendiferously fast linux system gets a crack at doing anything. There's really no way around testing on cygwin other than testing on cygwin. Ditto for mingw: ya gotta test under MSYS (which is cygwin-really-old by another name). Even mingw-w64: you still need an MSYS shell and utilities to run all the test cases, compare the results, etc. The problem is that test suites, in general, are THE worst performance case for cygwin: a bunch of tiny file accesses and TONS of tiny fork-n-execs (this is why cygwin/mingw get a disproportionate speed boost whenever you succeed in reducing the number of forks in libtool). But process spawning behavior is one of the biggest differences between win32 and posix, and one of the most difficult (and thus, relatively slow and inefficient) for cygwin/msys to paper over. It's been a thorn in our sides for over a decade. However, you think libtool is bad: it took me almost a week to run the gcc test suite. I've only ever done that twice. Dave Korn (cygwin-gcc maintainer) oughta take up a collection for a dedicated machine... -- Chuck
