Advantages of a 64 bit system - c++

From a developer perspective i am trying to understand , what is the selling point of a 64-bit system ?
I understand that more registers are at your disposal , more memory can be allocated to a process , but i cannot understand what makes a developer's life easier. Any examples ?
From a performance perspective are there any gains seen if a program is run on a 32bit vs 64 bit ?
Cheers!
EDIT : Thank you for all your replies. I see some conversations shooting towards end user experience , important as it may be.. I am looking more at any architectural benefits that you can squeeze out.
From what i understand , it looks like the optimizations are a lot at the compiler-assembler chain rather than a functionality which a programmer can call on ?

When you have 64-bits of address space to play with, you can adopt certain designs that would be very hard with less of an address space. For example, a friend recently pointed out to me that address space for thread stacks can get to be a problem with thousands of threads on a 32-bit system. But on a 64-bit system, this is no longer even remotely close to being a problem. This is the main direct benefit to developers that can affect how you write programs. And this is true regardless of how much actual memory the machine has.
Most programs I have seen converted to 64-bit have seen performance improvements because of the extra registers available.
Having 64-bit addresses can offset this performance improvement in some programs. The extra space pointers take up mean they take more cache, which leaves less space in your cache for other things. Also they take up more memory bus bandwidth when being transferred to and from main memory.
There is at least one project out there that proposes to recompile most programs in Linux in a sort of mixed-mode in which all the extra registers are used, but only 32-bit pointers are used. I'm interested in how this pans out because it removes the one performance disadvantage of 64-bit programs.
There is also a small (but important) subset of programs and algorithms that can make use of 64-bit registers. For example, most of the SHA-3 candidates are designed to take advantage of the ability to manipulate 64-bits of data at a time when doing bitwise operations.
Lastly, since the data paths inside the CPU are now 64-bits wide, this can also mean there is more bandwidth inside the CPU for moving things around. But I would expect this to be a benefit on 64-bit CPUs running in 32-bit mode as well.

When you run multiple processes e.g. debug session, compiler and other tools you will notice a big performance gain if you have lots of RAM in your system. I have 16GB RAM in my Win7 system and I will never go back to having less. Its a bit like when you start using dual monitors, one just isn't enough after that.

As you said, more memory can be a big advantage. For 32bit systems you'll be limited to processes max 4GB (or even 2 or 3, depending how annoying your OS is).
64bits is double the amount of bytes per instruction, so you have more bandwith internally. eg: faster everything.
see also:
http://lifehacker.com/5431284/the-lifehacker-guide-to-64+bit-vs-32+bit-operating-systems

A few Mac OS X specific answers (general ones are covered in other replies):
1) In 32 bit OSX, address space is mapped 4/4 (i.e. kernel gets the full 2^32 AND each app does), which requires flushing the TLB twice on each syscall. In 64 bit there's plenty of room to map the kernel and the application into different address ranges.
2) Objective-C programs use the new ABI/runtime on 64 bit x86 machines. This gets you C++ compatible exceptions, non-fragile instance variables, and some speedups.

Most desktop apps actually don't need to be 64 bits binaries, to the notable exception of image or video processing apps. In contrast, server apps often do.
The best advantage of running on a 64Bits machine a is that your app will have more RAM space, so it won't get swapped away when other apps will need the RAM. Yet 32 bit apps run on 64bits machine (luckily enough). I'm typing this on a 16GB Linux laptop with 2 DB (Oracle 11g and Mysql 6.0alpha), Windows in VirtualBox and a host of Java VMs, eclipse with Xmx=2GB...) and I couldn't cram all this on 4GB. Yet I still prefer to run 32bits apps when they do not need large amount of memory space.

Sorry, I kept this a bit list style, and avoided not mentioning increased memory addressing and more which had already been mentioned.
a) You'll have double the amount of registers, actually giving you three times the amount of registers at you disposal. b) General purpose registers are increased from 32 to 64 bit, meaning processing of 64 bit integers (i.e.) will be faster. c) More efficient position independent code since data can now be referenced relative to the RIP register. d) No-execute bit making the system more tolerant towards buffer overflows.

A 64-bit system has 64-bit memory addresses instead of 32-bit addresses, and so the maximum amount of memory available is 264 vs 232. This first quantity is roughly 1018 bytes, compared to the 109 bytes you can have with the latter quantity. Consequently, it's possible to have a lot more memory in a 64-bit system.

Related

Can someone explain why int takes on different sizes depending on system architecture?

Word on the street is that an int varies size depending on the system architecture (which I assume refers specifically to the processor architecture, though I'm probably wrong). That seems like that would be a really brittle setup when trying to run old software on newer processors, or as processors change in general. What was the motivation behind pegging the size of an integer to system architecture?
Also a (related) follow-up question. How does a system with say an IA-32 architecture reach a memory address that's greater than 4G?
Different CPUs have different design constraints. For example, transistors were more costly in the 80s because of this some chips only implemented a 16bit cpu word. For efficiency an int would be made to match that. Newer CPUs have a much higher transistor count at a lower cost so 'wasting' a few on passing around all those high order 0's when adding small numbers has a lower cost. In newer CPUs there is less of a problem with 32bit or potentially even 64bit integers.
Add into the mix special purpose CPUs and it can get really complex. I have heard of 24bit and 48bit CPUs for sound and video processing. I have not seen them myself but it is not hard to write code to be word size agnostic and the chips could theoretically exist.
For more details see: http://en.wikipedia.org/wiki/Word_(computer_architecture)
Physical Address Extension(PAE) is a CPU extension that allows the developer to access more memory via CPU instructions. It kept a table of memory addresses that referenced the higher regions of memory. It incurred the cost of a double pointer dereference in practice, that is usually preferable to using swap space or other disk buffer when you consider the speed of RAM and L2 cache.
Wikipedia has a decent page on it: http://en.wikipedia.org/wiki/Physical_Address_Extension

Why should we build 64 bit targets for C++ application? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
This is a very basic doubt that I have. I am not an IT or CS guy so please try to explain in simple language.
Now why I am asking that question is that because we can run 32 bit apps in 64 & 32 bit OS's. AFAIK the data types for 64 bit take double amount of memory than 32 bit apps. Also 64 bit apps can only run on 64 bit OS's.
Then why take the trouble of building 64 bit applications?
Perhaps thats why Firefox is available only in 32 bit???
Sorry if this question is not on par with the standards of SO, but I just cant control stop thinking about the same.
Thank You.
UPDATE: Somehow there seems to be a confusion.
I did not mean to question why we need a 64 bit architecture machine.
I know that 32 bit machines can only use 4GB RAM & 64 bit machines have much higher limit.
I was questioning why we need to build 64 bit Applications!
Aside from the OBVIOUS reasons given above (mainly "using more than 2-3GB of memory"), the reason to compile for 64-bit is that x86-64 has 16 registers, where x86-32 has 8. Since one of those registers is the stackpointer and often rBP is reserved for "framepointer", the actual useful number of registers is 6 and 14 respectively. The additional registers allow, for example, larger number of parameters being passed in registers, and larger number of temporary variables being held in registers within a function. This has a positive effect on the actual execution speed of the code, as every time memory is used instead of a register, AT LEAST it leads to a more complex instruction, and often to an additional instruction having to be used. This in turn makes the code larger when there isn't enough registers.
Generally, 64-bit x86 code runs some 5-15% faster with no modification to the actual algorithms, and typically has . Sometimes algorithms can be changed to gain much more [because for example you can have an array that is indexed by "telephone number", instead of hashing the phone number and then indexing on the hash, or making use of 64-bit integer values instead of 32-bit ones, meaning a speedup of 2x for "half as many operations"].
If it's performance you need from the application, you will have to benchmark (on multiple platforms). There are situations where, for example, larger pointers, mean that cache gets full more quickly and the code ends up running slower because "only half as many linked list entries fit in the cache".
In short: In most cases, 64-bit apps are faster than 32-bit apps doing the same thing.
The most important usecase is when you really want to consume more than 2 gigabytes memory for your process.
The next thing is 32-bit support will slowly decline just like you won't see many 16-bit apps now. This is a slow process though. Currently there's one version of Windows Server 2008 that doesn't have 32-bit support by default.
And finally sometimes you just have to be 64-bit - that's when you build an extension of any kind that is loaded into a 64-bit consumer process. Since 64-bit processes can't load 32-bit code you have to supply a 64-bit extension for them or craft an interop solution to have your code in a separate process - the latter is not always possible and is sometimes very inefficient.
Physical memory
A 32-bit system architecture can directly address only a 4-GB address space. A 64-bit system architecture that is running a 64-bit edition of Windows Server can support up to 1,024 GB of both physical and addressable memory.
Better parallel processing
A server that is using 32-bit architecture is limited (Windows OS) to 32 CPUs. Improvements in parallel processing and bus architectures enable 64-bit environments to support as many as 64 processors and provide almost linear scalability with each additional processor.
Faster bus architecture
A 64-bit architecture provides more and wider general-purpose registers, which contribute to greater overall application speed. When there are more registers, there is less need to write persistent data to memory and then have to read it back just a few instructions later. Function calls are also faster in a 64-bit environment because as many as four arguments at a time can be passed in registers to a function.
The size of data types does not automatically double with x64, but the size of the processors registers, just as the pointer size does. With 32 bits you are able to address 4294967295 bytes of memory (~ 4 Gb), which is not enought for some applications (like database management systems, ...).
Firefox is only available in 32-bit, because of compatibility issues. You cannot write libraries for x86 (32 bit) architectures and call them from x64 processors, because their pointers are incompatible (as described above). Creating both: x64 and x86 versions increases test-expense. If your application rarely uses more than 3.5 Gb memory, then it doesn't actually profit from x64 architectures.
Also 32 bit programms cannot simply run on x64 architectures. On Windows there is a layer for this, called Windows on Windows (WoW), or WoW64 for x64/x86 interfaces. Through various caching cases it may also be that an x86 application runs actually faster on WoW, than an native x64 application, doing the same.

Is there any real point compiling a Windows application as 64-bit?

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?
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.
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.
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.
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.
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.
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.
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.
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, ...
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.
Fastcall makes calling subroutines faster by keeping the first four parameters in registers.
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.
More data can be processed per clock cycle, which can deliver performance improvements to e.g. crypto, video encoding, etc. applications

Porting 32 bit C++ code to 64 bit - is it worth it? Why?

I am aware of some the obvious gains of the x64 architecture (higher addressable RAM addresses, etc)... but:
What if my program has no real need to run in native 64 bit mode. Should I port it anyway?
Are there any foreseeable deadlines for ending 32 bit support?
Would my application run faster / better / more secure as native x64 code?
x86-64 is a bit of a special case - for many architectures (eg. SPARC), compiling an application for 64 bit mode doesn't give it any benefit unless it can profitably use more than 4GB of memory. All it does is increase the size of the binary, which can actually make the code slower if it impacts on cache behaviour.
However, x86-64 gives you more than just a 64 bit address space and 64 bit integer registers - it also doubles the number of general purpose registers, which on a register-deficient architecture like x86 can result in a significant performance increase, with just a recompile.
It also lets the compiler assume that many extensions, like SSE and SSE2, are present, which can also significantly improve code optimisation.
Another benefit is that x86-64 adds PC-relative addressing, which can significantly simplify position-independent code.
However, if the app isn't performance sensitive, then none of this is really important either.
One possible benefit I haven't seen mentioned yet is that it might uncover latent bugs. Once you port it to 64-bit, a number of changes are made. The sizes of some datatypes change, the calling convention changes, the exception handling mechanism (at least on Windows) changes.
All of this might lead to otherwise hidden bugs surfacing, which means that you can fix them.
Assuming your code is correct and bug-free, porting to 64-bit should in theory be as simple as flicking a compiler switch. If that fails, it is because you're relying on things not guaranteed by the language, and so, they're potential sources of errors.
Here's what 64-bit does for you:
64-bit allows you to use more memory than a 32-bit app.
64-bit makes all pointers 64-bits, which makes your code footprint larger.
64-bit gives you more integer and floating point registers, which causes less spilling registers to memory, which should speed up your app somewhat.
64-bit can make 64-bit ALU operations faster (only helpful if you're using 64-bit data types).
You DO NOT get any extra security (another answer mentioned security, I'm not aware of any benefits like that).
You're limited to only running on 64-bit operating systems.
I've ported a number of C++ apps and seen about a 10% speedup with 64-bit code (same system, same compiler, the only change was a 32-bit vs 64-bit compiler mode), but most of those apps were doing a fair amount of 64-bit math. YMMV.
I wouldn't worry about 32-bit support going away any time soon.
(Edited to include notes from comments - thanks!)
Although its true that 32-bit will be around for a while in some form or another, Windows Server 2008 R2 ships with a 64-bit SKU only. I would not be surprised to see WOW64 as an install option as early as Windows 8 as more software migrates to 64-bit. WOW64 is a install, memory and performance overhead. The 3.5GB RAM limit in 32-bit Windows along with increasing RAM densities will encourage this migration. I'd rather have more RAM than CPU...
Embrace 64-bit! Take the time to make your 32-bit code 64-bit compatible, its a no brainer and straightforward. For normal applications the changes are more accurately describes as code corrections. For drivers the choice is: adapt or lose users. When the time comes you'll be ready to deploy on any platform with a recompile.
IMO the current cache related issues are moot; silicon improvements in this area and further 64-bit optimisation will be forthcoming.
If your program has no need to run under 64-bit, why would you? If you are not memory bound, and you don't have huge datasets, there is no point. The new Miata doesn't have bigger tires, because it doesn't NEED them.
32-bit support (even if only via emulation) will extend long past when your software ceases to be useful. We still emulate Atari 2600s, right?
No, in all likelyhood, your application will be slower in 64-bit mode, simply because less of it will fit in the processor's cache. It might be slightly more secure, but good coders don't need that crutch :)
Rico Mariani's post on why Microsoft isn't porting Visual Studio to 64-bit really sums it up Visual Studio: Why is there no 64 bit version? (yet)
It depends on whether your code is an application or a reusable library. For a library, keep in mind that the client of that library may have good reasons to run in 64-bit mode, so you have to ensure that your scenario works. This may also apply to applications when they are extensible via plugins.
If you don't have any real need now, and likely never will, for 64-bit mode, you shouldn't do porting.
If you don't have the need now, but may have it some day, you should try to estimate how much effort it will be (e.g. by turning on all respective compiler warnings, and attempting a 64-bit compilation). Expect that some things aren't trivial, so it will be useful to know how what problems you would likely encounter, and how long it would likely take to fix them.
Notice that a need may also arise from dependencies: if your program is a library (e.g. a DLL), it may be necessary to port it to 64-bit mode just because some host application gets ported.
For a foreseeable future, 32-bit applications will continue to be supported.
Unless there's a business reason to go to 64 bit, then there's no real "need" to support 64 bit.
However, there are some good reasons for going to 64 bit at some point, aside from all those that others have already mentioned.
It's getting harder to buy PCs that aren't 64 bit. Even though 32 bit apps will run in compatibility mode for years to come, any new PCs being sold today or in the future are likely to be 64 bit. If I have a shiny 64 bit operating system I don't really want to run "smelly old 32 bit apps" in compatibility mode!
Some things just don't run properly in comptibility mode - it's not the same thing as running on a 32-bit OS on 32-bit hardware. I've run into a few issues (e.g. registry access across the 32/64 bit registry hives, programs that fail because they're not in the folder they expect to be in, etc) when running in compatibility mode. I always feel nervous about running my code in compatibility mode - it's simply "not the real thing", and it often shows.
If you have written your code cleanly, then chances are you only have to recompile it as a 64 bit exe and it'll work fine, so there's no real reason not to give it a try.
the earlier you build a native 64 bit version, the easier it will be to keep it working on 64 bit as you add new features. That's a much better plan than continuing to develop in the dark ages for another 'n' years and then trying to jump out into the light.
When you go for your next job interview, you will be able to say that you have 64-bit expeirence and 32->64 porting experience.
You are already aware of the x64 advantages (most importantly the increased RAM size) and you are not interested in any, then don't port an executable (exe). Usually performance degrades after a port, mainly due to the increase in size of a x64 module over x86: all pointers now require double length, and this percolates everywhere, including code size (some jumps, function calls, vtables, virtual invokes, global symbols etc etc). Is not a significant degradation, but is usually measurable (3-5% speed decrease, depends on many factors).
DLLs are worth porting because you gain a new 'audience' in x64 apps that are able to consume your DLL.
Some OSs or configurations are unable to run 32-bit programs. A minimal Linux without 32-bit libc installed for example. Also IIRC I usually compile out the 32-bit support from the kernel.
If these OSs or configurations are part of your potential user base then yes, you should port it.
If you need more speed, then you should also port it (as others have said, x86-64 has more registers and cool instructions that speed it up).
Or, of course, if you want to mmap() or otherwise map a large file or lots of memory. Then 64-bit helps.
For example, if you had written 32-bit code (GNU C/++) as below
EDIT: format code
struct packet {
unsigned long name_id;
unsigned short age;
};
for network messaging, then you need to do porting while re-compiling on a 64 bit system, because of htonl/ntohl etc, communication get broken in the case of the network peer is still using the 32 bit system (using the same code as yours); you know sizeof(long) will be changed from 32 to 64 too at your side.
See more notes about 32/64 porting at http://code.google.com/p/effocore/downloads/list, document name EffoCoreRef.pdf.
It's pretty unlikely that you'd see any benefit unless you're in need of extreme security measures or obscene amounts of RAM.
Basically, you'd most likely know intuitively if your code was a good candidate for 64-bit porting.
Regarding deadlines. I would not worry, things like 32bit will be around for a good while natively and for a foreseeable future in some other form.
See my answer to this question here. I closed out that post saying that a 64-bit computer can store and retrieve much more information than a 32-bit computer. For most users this really doesn't mean a whole lot because things like browsing the web, checking email and playing Solitaire all work comfortably within the confines of 32-bit addressing. Where the 64-bit benefit will really shine is in areas where you have a lot of data the computer will have to churn through. Digital signal processing, gigapixel photography and advanced 3D gaming are all areas where their massive amounts of data processing would see a big boost in a 64-bit environment.
As for your code running faster/better, it's entirely up to your code and the requirements imposed on it.
As to performance issues, it depends on your program actually. If your program is pointer-intensive, porting to 64-bit may cause performance downgrading, since for CPU cache with the same size, each 64-bit pointer occupy more space on cache, and virtual-to-physical mappings also occupies more TLB space. Otherwise, if your program is not pointer-intensive, its performance will benefit from x64.
Of course performance is not the only reason for porting, other issues like porting effort, time scheduling should also be considered.
I would recommend porting it to 64 bit just so you are running "native" (Also, I use OpenBSD. In their AMD64 port, they do not provide any 32 bit emulation support, everything must be 64 bit)
Also, stdint.h is your best friend! By porting your application, you should learn how to code portably. Which will make your code work right when we have 128 bit processors too (in a few decades hopefully)
I've ported 2 or 3 things to 64 bit and now develop for both (which is very easy if you use stdint.h) and on my first project porting to 64 bit caused like 2 or 3 bugs to show up, but that was it. Most of it was a simple recompile and now I don't worry about the differences between 32 and 64 bit when making new code because I just automatically code portably. (using intptr_t and size_t and such)
In the case of a dll being called from a 64 bits process then the dll have to be 64 bits as well.
Then it does not matter if it's worth it, you simply have no choice.
One issue to keep in mind is the software libraries available. For instance, my company develops an application that uses multiple OpenGL libraries, and we do so on the OpenSuSE OS. In older versions of the OS, one could download a 32-bit versions of these libraries on the x86_64 architecture. Newer versions, however, don't have this. It made it easier to just compile in 64-bit mode.
64 bit will run a lot faster, when 64 bits compilers become mature, but when it will occur I dont know

How should application perform in 64-bit vs. 32-bit intel architectures?

I want to know the relative performances of a normal C++ application in the following scenarios:
Built as 32-bit app, run on Intel 64-bit processor (x64-64)
Built as 32-bit app, run on Intel 32-bit processor (x86)
Built as 64-bit app.
Also, what factors should I consider when modifying / developing the application to make it to run faster on 64-bit processors?
Short answer: you probably won't notice much of a difference.
Longer answer: 64-bit x86 has more general purpose registers, which gives the compiler more of an opportunity to optimize local variables into registers for faster access. the compiler can also assume more modern features, eg. not having to optimize code for a 386, and can assume your CPU has stuff like SSE instead of the old x87 FPU for floating point math. but pointers will be twice as wide, which is worse for the cache.
CPU-intensive programs might be noticeably faster on 64-bit. The processor has 16 instead of 8 general purpose registers available which are also twice as wide (64 instead of 32 bits).
Also the number of registers for SSE instructions is doubled from 8 to 16 which helps for multimedia-applications or other applications which do a lot of floating-point computations.
For details see x86-64 on Wikipedia.
One thing that has not been mentioned yet is that 64-bit versions of operating systems such as Windows and Linux use a different calling convention for function calls on 64-bit systems; instead of passing arguments on the stack, arguments are (preferrably) passed in registers, which is in principle faster. So software will be faster because there is less function call overhead.
The performance will very likely depend on your application, and can vary a lot, depending on whether or not you use libraries that have optimizations for 64-bit environments. If you want to count on speed up, you should focus on improving your algorithms, rather than considering the instruction set architecture.
As for preparing/developing for 64-bit... the key thing is to not make assumptions with regard to types and their respective sizes. If you need a type with a specific size, use the types defined in <stdint.h>. Whenever you see functions that use size_t or ptrdiff_t, you should use the typedefs rather than some other type.
In general, you won't find equivalent processors that differ only in their support for 64-bit operation, so it'll be hard to give any concrete comparisons between 1) and 2). On the other hand, the difference between building for 32 and 64 bit mode is entirely dependent on the application. A 64-bit version might be slightly slower or slightly faster than the 32-bit version. If your application uses a lot of temporary variables, then the increased register set of 64-bit mode can make a very large difference in performance.
From experience I've tended to find a 64-bit re-compile of a 32-bit application generally makes things about 30% faster. Its a rough figure but it holds for quite a number of applications i've ported to 64-bit. Basically its for the reasons explained above. You have more registers which is a godsend and allows for much less swapping in and out of memory (which will probably be cached anyway making the win quite small). Certain optimisations can be made much more easily as well. HOWEVER, you do suffer the problem of larger pointers that does wipe out some of the gain, not to mention that doing a context switch requires more memory to be used due to the larger register set.
Careful hand optimisation in 64-bit can provide HUGE performance wins, however.
Your best plan is to recompile as 64-bit and profile. ie See which is better.
Do you have any requirement for > 4G of memory? Exploiting gobs of memory is really the big reason to go 64-bit.
do you guys know anything about multi-channels MC concurrent data bus burst, IMC, and multi-core features of new x86_64 architectures? at least, memcpy can be optimized faster if 64 bits because of using 64 bits bus and registers regardless of concurrent burst. at least new archs are able to prefetch data from multiple memory modules into cache concurrently. and more...