This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Tim Prince <n8tm <at>> 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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]