3

It has been said it's OK for a .NET application to be compiled in x86 mode because pretty much the only benefit x64 gives is a larger virtual address space, thus allowing the application to allocate more than 2 (or 3) GB of memory, or memory-map very large files in their entirety.

However, a very simple test indicates that on a 64-bit machine, SHA256Managed hashes a 10 MB byte array almost twice as slowly if the application is x86 than if it is x64. So, any application that does a lot of SHA256 hashing benefits rather significantly from being "Any CPU" or having separate builds for the two platforms.

My question is: is this a typical result for .NET? Do other computationally-heavy tasks benefit similarly from running in 64-bit mode on a 64-bit OS? Of course, I could just test every specific computation, but I'd appreciate an overall "rule of thumb", such as:

  • yes, anything doing lots of integer arithmetic will be much faster
  • yes, all numeric computations are much faster (incl. doubles/decimals)
  • no, this is a rare exception and most algorithms run at roughly the same speed in both modes
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Roman Starkov
  • 59,298
  • 38
  • 251
  • 324

4 Answers4

4

First of all, great that you share the test results.

Answer: It depends.

64-bit is a lot different from 32-bit, and this is a whole separate discussion. The reason why you can't get a clear answer from anyone who knows what they are talking about is that some things are faster and other things slower. But some applications and certain algorithms clearly do benefit from it.

64-bit can address more, moves bigger chunks of data at the time, has more registers, makes shared libraries faster, etc. But it also changes how interrupts work(iirc), has more instructions (though some old are removed), is less efficient on smaller chunks of data, stack and pointers takes up more space, etc.

If you have a high demands on CPU power then it is usually cheaper for a business to buy a stronger CPU than to tune the program on such levels... Sadly! But to determine the efficiency of a certain algorithm on either platform you must test it.

In the machine code every stack item you add takes twice the memory, so twice the amount of data is being moved between L1, L2 and memory. But for every compute and memory read/write you can process more data per pass (higher throughput on large amounts of data). So it depends on how much data you are passing and how much and what kind of arithmics you are doing. Then consider that speed gain/loss compared to the OS only moving 4k pages, and that every pointer stored takes up twice as much of the highly valuabe L1 and L2 cache... + everything I can't remember.

My point is that the question quickly becomes complex and the answer will be very specific to the question.

I'd say the only reason to force a .Net application to 32-bit is if it references 32-bit libraries. It is unable to determine this dependency until the code is executed so it leads to an exception.

Tedd Hansen
  • 12,074
  • 14
  • 61
  • 97
  • _"the only reason to force a .Net application to 32-bit is if it references 32-bit libraries"_ - this was my stance too, until MS made x86 the default for new projects. That made me reconsider. But I'm back to this idea again now :) Just waiting for the ability to Edit-and-Continue in x64... – Roman Starkov Jan 27 '11 at 17:16
  • Indeed. Until then its conditional breakpoints and Immediate. I'd also suspect that the x64 compiler isn't as optimized as the x86 yet on the grounds that it is a comparatively new product. So we may see an increase in speed over time. (iirc Java had a really big jump once) – Tedd Hansen Jan 27 '11 at 17:33
  • Actually the x64 JIT is said to do a good deal more optimization on the stuff it issues. Hard to say it's "faster" overall because the JIT phase is slower while the runtime is faster... – Roman Starkov Feb 01 '11 at 18:18
2

As mentioned the answer is complex and depends highly on what you are doing. Related questions:

Community
  • 1
  • 1
Tedd Hansen
  • 12,074
  • 14
  • 61
  • 97
1

No, it is not typical.

The usage of 64-bit integer arithmetic is not a typical (!) measurement of application performance. If that does make up a significant portion of your application time (otherwise it is totally irrelevant), you have an application that deals with encryption / decryption of data, and I think you will agree this is not a typical application per definition.

•yes, anything doing lots of integer arithmetic will be much faster

No. Anything doing integer maths for a significant portion of its CPU usage (which may be different from doing many of them to start) may increase. This basically limits the impact to quite a few side effect applications. Web applications, for example, would not do SHA encryption - SSL would be handled by the kernel.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
TomTom
  • 61,059
  • 10
  • 88
  • 148
  • 1
    I think the question was asking specifically whether it is typical *for a computationally-heavy task*, not for any random application. – Timwi Jan 27 '11 at 17:09
  • Well, most computation heavy tasks will use floats ;) – TomTom Jan 27 '11 at 17:14
0

Operations involving long and ulong will certainly be almost twice as fast when using machine code instructions that operate on 64-bit CPU registers. In 32-bit mode, these operations are “emulated” as two (or more) separate instructions, which is also why reading and writing a 64-bit value is not atomic in 32-bit mode.

That said, the majority of computationally-heavy tasks probably still use 32-bit values (int and uint) or smaller. There is no speed difference for those.

Timwi
  • 65,159
  • 33
  • 165
  • 230