Should I choose to take advantage of 64-bit?


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: http://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 (12)

  1. Josh Williams&amp;nbsp;wrote a nice summary of the big performance issues when considering x64.

    It’s very…

  2. 64-bit => Sh!t driver support that’s the reason I had to go back from 64-bit Windows to the 32-bit equivalents. Maybe this is not entirely through if you by a standard Dell or another brand computer but it sure as hell is if you built your own computer.

  3. joshwil says:

    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…

  4. rickbrew says:

    The only driver trouble I had on x64 was with my new HP printer. Other than that, it runs and performs like a dream.

  5. Dean Harding says:

    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.

  6. joshwil says:

    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.

  7. Loïc Minier says:

    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.

  8. 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).

  9. joshwil says:

    Loic — I get the point. I’m suggesting that I believe it is not as benefitcial as many people think it is. If more registers is all you need then IA64 would be running away with the crown hands down. Most of the time for most of the scenarios I see (note the wiggle words there) stuff is not processor bound in tight loops. If it always was then more registers would make a bigger difference.

    Jeroen — In general we believe that managed code performance on 64-bit is competitive with 32-bit, in some cases better, in some cases worse, in most cases somewhere in the noise. However, the 64-bit CLR/JIT is in effect a v1 product competing against the 32-bit version which is for many practical purposes ~v3. We still however have some rough edges. If you can shoot me a relatively simple to execute repro for the problem you mention I can profile it and see where we’re losing time (with a difference that large I would hope that something would jump out) and hopefully we can fix the problem in an upcoming release of the CLR.

  10. Josh Williams offers a few tips on when to move to 64-bit from 32-bit.&amp;nbsp; &amp;nbsp; It is interesting…

  11. From time to time customers or partners ask me about our plans to create a 64 bit version of Visual Studio.