2

The little premature optimization bug in my head tells me that I should port my existing x86 C# application to x64 because of the x64 release of an unmanaged DLL on which it relies. I know the answer is probably to do it, test and see what happens, but I wanted to see the what benefits to expect generally are. I found a lot of posts from two to four years ago that complain that the x64 CLR speed is slower than the x86 CLR.

What are areas when one could expect to speed up with x64 code? Is it worthwhile to port, except if you need more than 2 GB of memory? My code is mainly network oriented, dealing with medium sized byte arrays and encryption algorithms.

user629926
  • 1,910
  • 2
  • 18
  • 43
  • Would the downvoter care to explain why they downvoted the question? +1 to offset it. – Ameen Feb 10 '13 at 06:42
  • FWIW a 32 bit, large address aware application actually gets the entire 4 GB address space if you run it on 64 bit OS, so that's an easy way to give the application access to more memory. – Brian Rasmussen Feb 10 '13 at 07:26
  • This question is very difficult to answer without specifics. 64-bit code is generally slower than the 32-bit equivalent, and there are really only a few reasons to port, IMO: 1) You need more memory than the 4GB available in 32-bit, or 2) you have a client who insists you should have a 64-bit version, or 3) you need to interact with a 64-bit system (eg., an Office or Windows Explorer extension). If you don't have a definite need to do the port, don't do it; it means you have another platform to test and debug. – Ken White Feb 10 '13 at 07:27
  • @KenWhite Another big reason to do this is if there is a lot of 64-bit integer arithmetic going on. In the floating point case, all of the code (if it is executing on a 64-bit processor) will be using SSE anyway, but integer arithmetic does not have this advantage, and will be implemented in multiple 32-bit instructions. – John Colanduoni Feb 10 '13 at 08:41
  • 2
    @KenWhite: That's not true. x64 code has access to more registers, which reduces the need to push non-volatile values to the stack, saving memory accesses in most functions. It also can do int64_t and uint64_t operations in a single cycle, compared to the 20-or-so cycles that it takes it on x86. Finally, in Windows, every WOW64 syscall has to be translated and suffers a CPU-mode transition and argument translation which you don't get if your code is x64 on an x64 OS. – SecurityMatt Feb 10 '13 at 10:22

1 Answers1

1

The simplest answer to this question is to profile 32-bit and 64-bit and compare them. However, since you said you are using encryption algorithms, I would strongly recommend considering going 64-bit, if you are using them often enough.

Encryption algorithms routinely do integer arithmetic and/or logical operations on values larger than 32-bits, which are made much faster in 64-bit code. In addition, they can often take advantage of the expanded register set of the processor (though certain superscalar/cache optimizations may already do this to a certain degree) more than normal code.

In the end, there is no way to tell which one will perform better other than testing it in your specific situations, but if whatever cryptology library you are using has a 64-bit version I believe it would be worthwhile to take a shot.

John Colanduoni
  • 1,596
  • 14
  • 18