Re: Cygwin speed difference on multiple cores -vs- single-core?

2010-08-14 Thread mike marchywka
On 8/13/10, Andy Nicholas <> wrote: > The scripts we're using form the basis of a build system to invoke GCC and > an > assembler lots of times throughout a directory tree of a few thousand items. You can end up spending all your time chasing include paths that isn't hard to do. > to use multi-t

Re: Cygwin speed difference on multiple cores -vs- single-core?

2010-08-13 Thread Andy Nicholas
Tim Prince aol.com> writes: > Several possibilities which you haven't addressed may affect this. > Are you comparing the performance of a single thread when locked to a > single core, compared to when it is permitted to rotate among cores, > with or without HyperThread enabled? > I've never run

Re: Cygwin speed difference on multiple cores -vs- single-core?

2010-08-13 Thread mike marchywka
On 8/13/10, Andy Nicholas <> wrote: > Hi Folks, > > When using cygwin, I've noticed that there seems to be a large speed > difference when I boot my windows 7 (32-bit) machine in single-core mode > versus the regular number of cores (4, Core i7-930). > > I've read through the FAQ and didn't notice

Re: Cygwin speed difference on multiple cores -vs- single-core?

2010-08-13 Thread Tim Prince
On 8/13/2010 5:37 PM, Andy Nicholas wrote: Hi Folks, When using cygwin, I've noticed that there seems to be a large speed difference when I boot my windows 7 (32-bit) machine in single-core mode versus the regular number of cores (4, Core i7-930). I've read through the FAQ and didn't notice any

Re: Cygwin speed

2007-10-05 Thread Oleg Volkov
I had come across with the following problem: after upgrading Cygwin from version 1.5.19-4 to 1.5.24-2 my application (relational database) began to function several times slower. The reason was a slowdown of a function, which performs rebalancing of table index tree; this function calls write() fu

Re: Cygwin speed

2007-03-19 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 3/7/2007 2:25 PM: >> Cygwin's sigprocmask() unconditionally calls sig_dispatch_pending(). > > And if cgf decides not to patch cygwin in this manner Fortunately, snapshots are patched now. >, I can at least try to > patch

Re: Cygwin speed

2007-03-07 Thread Brian Ford
On Wed, 7 Mar 2007, Christopher Faylor wrote: > I removed the sig_dispatch_pending from handle_sigprocmask. Would now be a good time to ask this question again? http://cygwin.com/ml/cygwin-developers/2006-07/msg00029.html I assume the answer is still the same, though ;-(. -- Brian Ford Lead R

Re: Cygwin speed

2007-03-07 Thread Christian Franke
Eric Blake wrote: ... And the way I see it, if the mask is unchanged, then any signal that was unblocked before calling sigprocmask() should have already fired. In other words, the only signals that sigprocmask() HAS to worry about are signals that just changed to unmasked;... To handle

Re: Cygwin speed

2007-03-07 Thread Christopher Faylor
On Wed, Mar 07, 2007 at 09:13:33PM +0100, Christian Franke wrote: >Christopher Layne wrote: >>On Fri, Mar 02, 2007 at 11:11:54AM -0800, Brian Dessent wrote: >>>Vinod Gupta wrote: >>> Cygwin was a slow by a factor of 3x. Is that normal? >>>Yes. Emulation of POSIX functions which do not exist on

Re: Cygwin speed

2007-03-07 Thread Eric Blake
Christian Franke t-online.de> writes: > Cygwin's sigprocmask() unconditionally calls sig_dispatch_pending(). > This is necessary because POSIX requires that at least one pending > signal is dispatched by sigprocmask(). Actually, POSIX requires "If there are any pending unblocked signals after t

Re: Cygwin speed

2007-03-07 Thread Christian Franke
Christopher Layne wrote: On Fri, Mar 02, 2007 at 11:11:54AM -0800, Brian Dessent wrote: Vinod Gupta wrote: Cygwin was a slow by a factor of 3x. Is that normal? Yes. Emulation of POSIX functions which do not exist on Windows is expensive. Fork is especially bad, which is all you're really te

Re: Cygwin speed

2007-03-04 Thread Christopher Layne
On Fri, Mar 02, 2007 at 11:11:54AM -0800, Brian Dessent wrote: > Vinod Gupta wrote: > > > Cygwin was a slow by a factor of 3x. Is that normal? > > Yes. Emulation of POSIX functions which do not exist on Windows is > expensive. Fork is especially bad, which is all you're really testing > there.

Re: Cygwin speed

2007-03-02 Thread Thorsten Kampe
* Brian Dessent (Fri, 02 Mar 2007 11:11:54 -0800) > Vinod Gupta wrote: >> Cygwin was a slow by a factor of 3x. Is that normal? > > Yes. Actually no. The standard approximate guess is a factor of two which corresponds to Vinod's testings. -- Unsubscribe info: http://cygwin.com/ml/#unsubscr

Re: Cygwin speed

2007-03-02 Thread Brian Dessent
Vinod Gupta wrote: > Cygwin was a slow by a factor of 3x. Is that normal? Yes. Emulation of POSIX functions which do not exist on Windows is expensive. Fork is especially bad, which is all you're really testing there. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Pr