.NET 2 x64 slow compared to 32 bit?

Hi,

Are you trying to cross-compile? By this I mean are you trying to Build for the 64-bit machine on a 32-bit machine? On a 64-bit machine, by default the correct MSCORLIB gets referenced in VS2005 - I havent tried Beta 2 yet...but it was working fine in Dec CTP...

Regards,
Vikram

Thank you for the info, I have since seen an MS blog which states what you are both saying, that the correct 64 bit mscorlib will automatically be referenced.

Here is some info on the hardware and a (very basic) sample of code which I expected to execute faster on 64 bit:

32 bit machine:
Dell Precision Workstation 650
Dual Xeon 3.0GHz
512kb cache
2 GB RAM
Windows Server 2003 Standard SP1

64 bit machine
Dell 2850 rack server
Dual Xeon 3.2GHz (EM64T)
2MB cache
6 GB RAM
Windows Server 2003 Standard x64 SP1

Both systems run VS 2005 Beta 2.

// 32 bit copy
...
int intCount = bitCount >> 5;
fixed (byte* pbSrc = &data[byteIx + sizeof(ushort)], pbDst = b.Data) {
int* piSrc = (int*) pbSrc;
int* piDst = (int*) pbDst;
for (int i = 0; i < intCount; ++i)
*piDst++ = *piSrc++;
...

// 64 bit copy
...
int longCount = bitCount >> 6;
fixed (byte* pbSrc = &data[byteIx + sizeof(ushort)], pbDst = b.Data) {
long* plSrc = (long*) pbSrc;
long* plDst = (long*) pbDst;
for (int i = 0; i < longCount; ++i)
*plDst++ = *plSrc++;
...

These are actual snippets from our application (unsafe copying data between byte[]'s). All pointers on 64 bit .NET are 64 bits wide so one can expect a slight performance hit when running the 32 bit code on 64 bit hardware, but the 64 bit code should execute faster (at least that's what I thought). With 64 bit (long) being native and there being only half as many iterations through the loop, shouldn't the 64 bit code in this specific example execute at twice the speed? Here are the results from two low level bit-op tests similar to the code shown above:

32 bit code (int*), built on 32 bit hardware, run on 32 bit hardware
Test 1: 22,860 ms
Test 2: 22,765 ms

32 bit code (int*), built on 64 bit hardware, run on 64 bit hardware
Test 1: 20,859 ms
Test 2: 20,719 ms

The 64 bit hardware runs the 32 bit code (int*) about 10% faster than on the 32 bit machine. However, if I run the build from the 32 bit machine on 64 bit hardware it runs even faster, i.e. building and running the same code on 64 bit is fractionally slower than building it on 32 bit and running it on 64 bit:

32 bit code (int*), built on 32 bit hardware, run on 64 bit hardware
Test 1: 20,484 ms
Test 2: 20,485 ms

And now for the 64 bit code (long*):

64 bit code (long*), built on 32 bit hardware, run on 32 bit hardware
Test 1: 23,453 ms
Test 2: 22,969 ms

64 bit code (long*), built on 64 bit hardware, run on 64 bit hardware
Test 1: 21,500 ms
Test 2: 21,281 ms

Here the 64 bit hardware is slightly faster, while the 32 bit hardware takes a slight performance hit from processing long* vs. int*. But again, the greatest gain is achieved by building the 64 bit code (long*) on a 32 bit machine, and then executing the resulting assemblies on 64 bit hardware:

64 bit code (long*), built on 32 bit hardware, run on 64 bit hardware
Test 1: 20,375 ms
Test 2: 20,282 ms

So it appears that:
1) VS 2005 Beta 2 on 32 bit hardware builds assemblies which run faster on 64 bit hardware than if the assemblies were built using VS 2005 Beta 2 on 64 bit hardware.
2) Using long* vs. int* provides virtually no benefit on current EM64T hardware.

We have a fairly large test suite (around 220 classes, 1500 methods) which tests various aspects of our software. On some tests there are slight gains (up to approx. 10%) and on others there are slight losses, but overall the 64 bit tests lag by approx. 3% despite the fact that the 64 bit hardware is slightly faster than 32 bit. We are not seeing large wins anywhere.

We have been developing this project with 64 bit hardware in mind (for more than two years now) and the code is littered with #define's and #if's which split various methods between 32 bit and 64 bit specific implementations. To now find that there is virtually no performance benefit is a little disappointing. Is this scenario likely to change in future with newer processors and memory architectures or is there a different way to code for optimal 64 bit performance in .NET?

Nandor.

Many thanks for that, very interesting blog entry. My expectation was that bit-level operations will automatically be faster since this is where most of the 64 bit performance benefits are seen (e.g. encoding audio/video streams) and also due to 128 bit internal busses and registers, but clearly it's not quite that simple. I fully agree with your statement that "Good Engineering == Better Performance" but not all of that is currently under (3'rd party) programmer control unless you are prepared to rewrite portions of the .NET libraries. I was amazed to see how much faster .NET 2.0 is compared to 1.1 (e.g. our tests show up to 30% for hashtables) so I guess that most of the optimisations are already there and future hardware (and 64 bit CLR's) will probably keep improving.

Nandor.