tags:

views:

543

answers:

13

I'd confidently say 99% of applications we write don't need to address more than 2Gb of memory. Of course, there's a lot of obvious benefit to the OS running 64-bit to address more RAM, but is there any particular reason a typical application would be compiled 64bit?

+12  A: 

Building them as 64-bit now, even if you never release the build, can help you find and repair problems that you will encounter later when you're forced to build and release as 64-bit.

Ignacio Vazquez-Abrams
Why am i going to be forced to release as 64-bit
John
You can't know that right now. At one point 32-bit CPUs may fall by the wayside in the same manner that 16-bit CPUs have, relegated to embedded roles; it's impossible to predict.
Ignacio Vazquez-Abrams
But even 16-bit apps can still run can't they? I mean if I write a 16-bit app which doesn't try to call system APIs and do low-level stuff, it can still run quite OK?
John
Only because the current ISA is a superset of the ISA used when the 16-bit app was popular. Trying to run one on e.g. an ARM is pain.
Ignacio Vazquez-Abrams
@John: 16 bit apps can't run on 64 bit versions of windows. At all.
Billy ONeal
That's an OS-issue though, not a hardware one? Not sure it makes much difference...
John
Yup. If your application is large, you don't know what sort of optimization could be lurking which assumes 32-bit (e.g., bit rotations). Putting-in the little bit of effort of building regularly now, and slowly testing during everyone's free cycles (ha!) will give much more confidence down the road if/when you have to make the transition.
hythlodayr
@John: x86 HW issue actually. 16 bits software is run in "Virtual 8086" mode. That's easily available when the processor is itself in 32 bits mode. However, when an x86-64 processor itself is in 64 bits mode, it can only run 64 and 32 bits applications (long mode/compatibility mode).
MSalters
You would be "forced" to release as 64-bit when your customer demands to be able to access more than 4GB of data. You might as well be prepared for it to happen, even if it's not likely in the foreseeable future.
Gabe
+11  A: 

There are performance improvements that might see with 64-bit. A good example is that some parameters in function calls are passed via registers (less things to push on the stack).

Edit I looked up some of my old notes from when I was studying some of the differences of running our product with a 64-bit build versus a 32-bit build. I ran the tests on a quad core 64-bit machine. So there is the question of comparing apples to oranges since the 32-bit was running under the emulation mode obviously. However, it seems that many things I read such as this, for example, consistently say that the speed hit for WOW64 is not significant. But even if that statement is not true, your application will almost certainly be run on a 64-bit OS. Thus a comparison of a 32-bit build versus 64-bit on a 64-bit machine has value.

In the testing I performed (certainly not comprehensive), I did not find any cases where the 32-bit build was faster. However many of the SQL intensive operations I ran (high CPU and high I/O) were 20% to 50% faster when running with the 64-bit build. These tests involved some fairly “ugly” SQL statements and also some TPCC tests with high concurrency. Of course, a lot depends on compiler switches quite a bit, so you need to do your own testing.

Mark Wilkins
+1 - Also worth mentioning that 32 bit applications run on an emulator (WOW64).
Chris Shaffer
But there are also potential negative performance issues equally, no? I was under the impression the difference was pretty tiny. And is it really an _emulator_?
John
@Chris: Do keep in mind that that "emulator" is supported in hardware and does not carry the traditional performance hit of a true emulator. You do pay for abstraction calls to path and registry functions though. But +1 for pointing it out.
Billy ONeal
@John: In the testing I did with our product, I did not find anything that was slower (maybe I simply didn't test enough). Quite a few different operations were faster (it's a database server). I'll have to dig up the numbers when I am at work, but if I recall correctly things were often 10% faster or better. And that wasn't just a difference of emulator versus not emulator.
Mark Wilkins
64-bit code might be larger, and definitely has larger requirements for pointer storage. So memory bandwidth and cache utilization take a small hit.
Mark Ransom
+1  A: 

If you don't need the extended address space, delivering in 64 bits mode offers nothing and has some disadvantage like increasing the memory consumption and the cache pressure.

While we offer 64 bits builds, our customer who are at the limit are pushing us to reduce the memory consumption so that they get these advantages.

AProgrammer
A: 

More data can be processed per clock cycle, which can deliver performance improvements to e.g. crypto, video encoding, etc. applications

Tom Frey
This is false. The when we talk about 64 bit now, we aren't talking about data register width or data bus width. The data bus went past 128 bits years ago, IIRC, and 64 bit ints have been supported by registers for a decade. The benefits of 64 bit are all about address space.
Steve314
not according to Microsoft: "The 64-bit systems offer direct access to more virtual and physical memory than 32-bit systems and process more data per clock cycle, enabling more scalable, higher performing computing solutions." and Wikipedia: "Some programs such as data encryption software can benefit greatly from 64-bit registers (if the software is 64-bit compiled) and effectively execute 3 to 5 times faster on 64-bit than on 32-bit."
Tom Frey
This is marketing. In the real world, 64 bit registers may speedup 64bit arithmetic or certain register operations, but normally reduce the performance by forcing every pointer to double in size. Video encoding does use another register set, where the registers are already 128 bit wide.
Christopher
@Tom: Quoting wikipedia as a source is not a good idea it is not an authoritative source. It is a good point to start research from and it can provide links to good sources but it is not a source itself. http://www.urbandictionary.com/define.php?term=wikijism See also the wikipedia article about citing: http://en.wikipedia.org/wiki/Citing_Wikipedia
Martin York
The pentium 1 had a 64-bit data bus and instructions for processing 64-bit "quadwords" (the precise term used in the P1 architecture guide and instruction reference).
Steve314
+3  A: 

I'd say only do it if you need more that 2GB.

One thing is 64-bit compilation means (obviously) 64-bit pointers. That means the code and data structures get a bit bigger, meaning that the app. will benefit a little less from cache and will hit the virtual memory a bit more often etc.

So, if you don't need it, the basic effect is to make your app a bit slower and more bloated for no reason.

That said, as time goes on, you'll care more about 64 bit anyway just because that's what all the tools and libraries etc will be written for. Even if your app can live quite happily in 64K, you're unlikely to use 16 bit code - the gains don't really matter (it's a small fast app anyway) and are certainly outweighed by the hassle involved. In time, we'll see 32-bit much the same way.

Steve314
+1  A: 

All applications that may need lots of memory: database servers that want to cache lots of data in memory, scientific applications that handle lots of data, ...

Patrick
Exactly. They fall in the 1% of apps which are not 'normal'. Few of us here are writing database servers.
John
I am writing scientific simulation software which sometimes loads and processes millions of records of a database. In more and more cases the 2GB limit is really becoming a problem. 64-bit is more becoming a necessity for me.
Patrick
A: 

Fastcall makes calling subroutines faster by keeping the first four parameters in registers.

Jens Björnhager
Sometimes -- not always. You get some improvement on some function calls because of fastcall but it forces every function call inside the called function to store the current state of the register.
Billy ONeal
Which they can save to registers, or in the worst case scenario, the stack.
Jens Björnhager
+3  A: 

You could consider it as future-proofing. It may be a long way away, but consider some years in to the future, where 64-bit OS and CPUs are ubiquitous (consider how 16-bit faded away when 32-bit took over). If your application is 32-bit and all your competitors have moved on to 64-bit by then, your application could be seen as (or accused by your competitors as) out of date, slower, or incapable of change. Maybe even one day support for 32-bit applications will be dropped or incomplete (can Windows 7 run 16-bit apps properly?). If you're already building a 64-bit version of your application today, you avoid these problems. If you put it off till later, you might write a lot more code between now and when you port, then your port will be even harder.

For a lot of applications there aren't many compelling technical reasons, but if it's easy, porting now might save you effort in future.

AshleysBrain
+7  A: 

x64 has eight more general purpose registers that aren't available when running 32-bit code. That's three times as many (twice as many if you count ESI, EDI, EBP and ESP as general purpose; I don't). That can save a lot of loads and stores in functions that use more than four variables.

Matthew Xavier
A: 

I've recently read this article,Optimizing software in C++. In chapter 2.3 Choice of operating system there is a comparison between advantadges and disavantages of 64 and 32 bits system, with some specific observations regarding Windows.

Mark Wilkins already noted in this thread about more registers for function calls. Another interesting property of 64 bit system is this:

The SSE2 instruction set is supported on all 64-bit CPUs and operating systems.

SSE2 instructions can provide excellent optimizations and they are being increasingly used, so in my opinion this is a notable feature.

fogo
Yes but SSE1/2/3 are still accessible through 32-bit apps. So all you're gaining is a bit of consistency, knowing that any PC your code targets will have SSE2?
John
Yes, I should probably said most modern 32-bit system support SSE nowadays. 64-bits systems just guarantee you will have it available.
fogo
+2  A: 

Don't underestimate the marketing value of offering a native 64-bit version of your product.

Also, you might be surprised just how many people work on apps that require as much memory as they can get.

John Dibling
The same effect was very obvious when Apple introduced the intel macs. If your app wasn't available as a Universal Binary then a substantial chunk of the mac userbase just didn't want to know.
the_mandrill
Whoever downvoted this must not live in the real world where we get a paycheck because people buy our software.
John Dibling
A: 

When you say that 99% of apps won't benefit from 64-bit, that may well be true for you personally, but during the day I use Visual Studio and Xcode to compile C++ with a large codebase, search the multi-Gb repositories with Google Desktop and Spotlight. Then I come home to write music using a sequencer using several Gb of sound libraries, and do some photoshopping on my 20Gb of photos, and maybe do a bit of video editing with my holiday clips.

So for me (and I dare say many other users), having 64-bit versions of many of these apps will be a great advantage. Word processor, web browser, email client: maybe not. But anything involved with large media will really benefit.

the_mandrill
You really don't understand statistics, do you? 99% doesn't mean 99% of the things I work on. Just because you use apps which might benefit, doesn't make me wrong. You're just using several of the 1% apps.
John
John, I'm not intending to prove you wrong (cheers for the downvote). My point was that a lot of applications in very common use (Pro Tools, Cubase, Sonar, Photoshop, InDesign, Pinnacle Studio,...) will benefit, and these may be the main apps that a lot of consumers will use. Considering the whole universe of apps, yes, that's probably less than 1%, but that's arguably not a very useful statistic.
the_mandrill
I down-vote because I disagree with you. That's the point of SO... it's not a personal attack. And the discussion of 64 bit is about developers, not users. Most developers work on apps which don't need 64bit... the fact most users use one app that does isn't the point of the question.
John