Should I choose to take advantage of 64-bit?

  • Article

Here's the guts of a response that I posted a while back to an internal mailing list re: tradeoffs of runing your managed code as 64-bit vs 32-bit. YMMV, and I'll remind you that every perf question has a thousand answers depending on the situation.

 

>>>>>>> snip >>>>>>>>>>>>>>>>>

 

Here's my own personal list of the big pluses and minuses of moving to 64-bit code...

 

Pluses:

- more memory (+++++)

- better 64-bit math (+++)

- X64 OS kernel takes advantage of more memory to do good things for a lot of stuff (+++)

Minuses:

- things need more memory (pointers are bigger, and especially in managed code references are everything and are everywhere) (--)

- the processor's cache is effectively smaller (when comparing against the same machine in 32-bit vs 64-bit mode) because of the prior point (----)

- code also tends to be bigger because of extra prefix bytes and instructions that carry around 8-byte immediate values instead of 4 byte immediate values

 

What this tends to mean is that code that runs extremely well on 32-bit, doesn't have any 64-bit math (or otherwise take advantage of improvements in the 64-bit processor) and runs well in < 2GB of memory without having to bother hitting the disk for anything will likely continue to run on 64-bit with somewhat MORE memory usage and a little bit slower because the processors cache is effectively smaller when compared to the bloated size of the things that need to be in it.

In the scenario described above you get the minuses of the platform without taking advantage of the pluses.

If however you have an application or set of applications that can take advantage of the pluses to offset the minuses they can come out in the black (sometimes _very_ much so). We have seen a number of large applications which used to be memory starved on 32-bit and had some type of home-grown paging able to throw that more or less out the window and see their performance go up by 2, 3 or even 4X. PaintDotNet (which is a pretty cool photo editing application, Rick Brewster's blog: https://blogs.msdn.com/rickbrew/default.aspx) rewrote a bunch of their filters to take advantage of 64-bit math and saw speed boosts moving to x64 of 3X+ for those filters. I just saw a presentation the other day where microsoft.com was saying that they have seen both significant reliability boosts and throughput increases moving to 64-bit (however they were running 12 app pools on a box and were definitely running into the memory limits of the 32-bit system).

Comments

  • Anonymous
    July 18, 2006
    Josh Williams&amp;nbsp;wrote a nice summary of the big performance issues when considering x64.
    It's very...
  • Anonymous
    July 18, 2006
    PingBack from http://microsoft.wagalulu.com/2006/07/18/should-i-choose-to-take-advantage-of-64-bit/
  • Anonymous
    July 18, 2006
    The comment has been removed
  • Anonymous
    July 18, 2006
    Gabriel -- it is true that for a lot of early adopters the driver support isn't quite there yet. However things are getting better for Vista. I've been using 64-bit for my primary machines for a few years and things are definitely better now.

    However, the point of this entry isn't why to switch to 64-bit on your machine so much as why to target 64-bit with your development...
  • Anonymous
    July 18, 2006
    The only driver trouble I had on x64 was with my new HP printer. Other than that, it runs and performs like a dream.
  • Anonymous
    July 18, 2006
    What about the fact that 64-bit has more general-purpose registers? That should be in the "pluses" section as well, and should help with programs that would not otherwise normally see any benefits.
  • Anonymous
    July 18, 2006
    Dean -- Certainly a good point and in medium sized tight loops those extra registers can be helpful. However often they don't make as much of a difference as people would like to believe, certainly in many cases they are an extra few % and in a couple particular cases they make all the difference. In my mind they aren't a big enough deal to make the list.
  • Anonymous
    July 18, 2006
    Well, I agree with Dean, you completely miss the point of x86/64, it doubles the amount of general purpose registers.

    It's a known fact that one of the big problem with x86 is the small number of general registers, and this is how lower frequency arches can achieve a comparable amount of performance.

    Beside, these many registers also balance your argument with respect to cache size.  Code size is in some cases smaller due to the use of regs instead of the stack.  This also lowers the amount of data to fetch from memory when more data is passed via registers.

    However, it's nice that you balance your conclusion depending on the application type, and you're correct that some applications are negatively hit by the use of 64-bits pointers.
  • Anonymous
    July 18, 2006
    What about managed code? I must say that I'm a little disappointed by the x64 managed code performance. Running ikvmc to build IKVM.GNU.Classpath.dll is much slower in 64 bit mode. 164 seconds of user mode CPU time vs. 63 seconds in 32 bit mode (by forcing the CLR to run in 32 bit mode -- so all other conditions are identical).
  • Anonymous
    July 19, 2006
    The comment has been removed
  • Anonymous
    July 19, 2006
    Josh Williams offers a few tips on when to move to 64-bit from 32-bit.&amp;nbsp; &amp;nbsp; It is interesting...
  • Anonymous
    June 10, 2009
    From time to time customers or partners ask me about our plans to create a 64 bit version of Visual Studio.