Looking at Three Systems (poor hash rates on a Xeon)

[inertia]

I didn't set any switches on the command line on any of these configuration.

System A: Xeon x4 @ 3.0GHz Windows 2003 Small Business Server (32-bit), Bitcoin v0.3.15:
Limited to 4 CPU: ~900 khash/s
Limited to 3 CPU: ~1100 khash/s
Limited to 2 CPU: ~1100 khash/s
Limited to 1 CPU: ~725 khash/s

System B: Core i7 x4 @2.66GHz Mac OS X 10.6.5 (64-bit), Bitcoin v0.3.13:
Limited to 4 CPU: ~1800 khash/s
Limited to 3 CPU: ~1800 khash/s
Limited to 2 CPU: ~1500 khash/s
Limited to 1 CPU: ~1000 khash/s

System C: Core i7 x4 @2.66 Windows XP x64 Edition (in VMWare Fusion on Mac OS X 10.6.5), Bitcoin v0.03.15:
Limited to 4 CPU: ~2100 khash/s
Limited to 3 CPU: ~2300 khash/s
Limited to 2 CPU: ~1900 khash/s
Limited to 1 CPU: ~1200 khash/s

I'm particularly concerned about System A.  How can 3 GHz only reach 900 khash/s?  I thought it was odd that limiting the number of CPUs to 3 allows the hash rate to increase.  That's why I looked at System B and C.  I wanted to see if the same thing would happen.

So System A doesn't scale in a way I would have expected.  If I get ~725 on one CPU, I would expect ~2900 on four.  But none of my configurations scale like that, so is this a reasonable expectation?  I would have never tried limiting any of my systems to 3 CPUs until I started monkeying with System A, trying to figure out why it was getting such poor hash rates.  Who would ever think to run 3 CPUs anyway?  If you intend to limit, you would probably limit to half, or a quarter, not three quarters.  It didn't occur to me to try it until today.

Systems B and C are actually the same computer.  Both configurations have managed to generate.  My theory as to why the virtualize System C is able to reach higher hash rates than the Mac OS X client is that VMWare is able to schedule as with system priorities as opposed to user priorities.

Anyway, my main question here is why does a 3.0 GHz system is getting such abismal hash rates as compared to the 2.66 GHz system?  Is Core i7 really that superior to Xeon?

[1715129863]

1715129863

[1715129863]

1715129863

[1715129863]

1715129863

[1715129863]

1715129863

[wumpus]

Compared to the systems in this topic you get really low hash rates:
https://www.bitcoin.org/smf/index.php?topic=1628.0

I don't know why.

[inertia]

Compared to the systems in this topic you get really low hash rates:
https://www.bitcoin.org/smf/index.php?topic=1628.0

I don't know why.

Indeed.  I saw that thread and tried -4way (and even -4way=0), but it didn't slow anything down nor speed it up.

[theymos]

It sounds like you actually only have two physical cores, and you're including the virtual hyper-threading cores. This has different effects on different architectures.

[teknohog]

The Xeon brand stands for a huge range of different CPUs, from the Pentium II days to present. Without a model number it is impossible to tell what kind of a processor it is. A 3.0 GHz Xeon could have a Pentium 4 architecture, which is not particularly efficient.

[inertia]

It sounds like you actually only have two physical cores, and you're including the virtual hyper-threading cores. This has different effects on different architectures.

Ok, turns out Small Business Server limits the number of physical CPUs to two.  Hyperthreading was indeed enabled so a cursory view made it appear there were four CPUs.  Disabling hyperthreading brought the hash rate up to 1400 on two CPUs, which seems fairly appropriate.