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

2010-08-13 Thread Andy Nicholas
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 anything about this issue.

Normally, I would expect nearly no speed difference based on the Windows 
environment... but after some extensive timing tests it seems like the single-
core machine is usually at least 2x faster than using the same machine setup 
in multi-core mode. I limit the number of cores using MSCONFIG, advanced boot 
options.

We have some simple script and more complex scripts which show this behavior. 
The simple scripts do straightforward things like rm -rf over some directory 
trees. Even the simple scripts run slowly when the PC is booted with multiple 
cores.

Is this known behavior? Is there some way to work around it so I can boot my 
PC, use all the cores with other apps, and continue run cygwin 2x faster?

Thanks much,

andy



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



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

2010-08-13 Thread Andy Nicholas
Tim Prince n8tm at 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 into anyone running win7 32-bit; it may have more such 
 issues than the more common 64-bit.

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. 
The tree itself on the file-system is not gigantic. I've tried to make sure 
that the environment has all the usual suspects disabled (virus-checking 
disabled, paging completely disabled for all disks, nothing else running in 
the background) before comparing anything.

I've been comparing using 2 different methods, one is the time to clean the 
tree using rm -rf via a makefile on empty directories and the other is to do 
a full build on a clean tree. When running make we don't use the -j option 
to use multi-threaded builds. When running each testing method, the CPUs are 
barely loaded at all (10%, maybe) and there's almost no I/O that registers.

Hyperthreading is disabled. I've tried comparisons when configuring the PC 
using msconfig to present 1 core, 2 cores, and 4 cores. The difference between 
1-core and 2 or 4 cores is dramatic with 1-core running 2x+ faster. There's 
almost no difference in speed between 2 cores and 4 cores. The disk is an SSD.

I've recently tried launching the original command-line window with its 
affinity locked to core0 and priority set to realtime. I've inspected the 
results using SysInternals' Process Explorer and spawned processes appear to 
be locked to core0. I made sure that the non-spawned processes 
like conhost.exe also had their affinities set and their priority raised to 
realtime. There's no difference in processing speed though.

Btw, I don't think the issue is I/O. The disk I'm using is an SSD (OCZ Vertex 
2) which is fairly fast. But, the results repeat even if I try a regular 7200 
RPM hard drive.

Yeah, weird.

andy






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple