I am aware of some the obvious gains of the x64 architecture (higher addressable RAM addresses, ect)... but:
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.
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.
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.
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.
Here's what 64-bit does for you:
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!)
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)
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.
However, if the app isn't performance sensitive, then none of this is really important either.
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.
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.
Would my application run faster / better / more secure in native x64 code?
32-bit applications run approximately 2% slower in the 64-bit environment than in the 32-bit one. It relates to the use of Wow64 layer. A 64-bit application runs approximately 5-15% faster than a 32-bit one. If you use "right" data types performance of 64-bit applications can be sometimes increased in 5-10% more. To learn more about performance of 64-bit applications see the articles:
I cannot tell you about safety of 64-bit systems yet. Most likely, some previous attacks will be removed but new ones can appear. I wrote a small article on this topic: Safety of 64-bit code
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.
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.
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.
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.
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.