Bdtyktl

Basically you can do everything to a bigger scale:

1. 
   RAM per OS: RAM limit of 4GB on x86 for the OS (most of the time)


2. 
   RAM per process: RAM limit of 4GB on x86 for processes (always). If you think this is not important, try running a huge MSSQL database intensive application. It will use > 4GB itself if you have it available and run much better.


3. 
   Addresses: Addresses are 64bits instead of 32bits allowing you to have "bigger" programs that use more memory.


4. 
   Handles available to programs: You can create more file handles, processes, ... Example on Windows x64 you can create > 2000 threads per process, but on x86 closer to a few hundred.


5. 
   Wider programs available: From an x64 you can run both x86 and x64 programs. (Example windows: wow64, windows32 on windows64 emulation)


6. 
   Emulation options: From an x64 you can run both x86 and x64 VMs.


7. 
   Faster: Some calculations are faster on a 64-bit CPU


8. 
   Dividing multiple system resources: A lot of RAM memory is very important when you want to run at least one VM which divides up your system resources.


9. 
   Exclusive programs available: Several new programs only support x64. Example Exchange 2007.


10. 
    Future obsolete x86?: Over time more and more 64-bit will be used and more and more x86 will not be used. So vendors will support only 64-bit more and more.

The 2 big types of 64-bit architectures are x64 and IA64 architectures. But x64 is the most popular by far.

x64 can run x86 commands as well as x64 commands. IA64 runs x86 commands as well, but it doesn't do SSE extensions. There is hardware dedicated on Itanium for running x86 instructions; it's an emulator, but in hardware.

As @Phil mentioned you can get a deeper look of how it works here.

The biggest impact that people will notice at the moment is that a 32bit PC can only address a maximum of 4GB of memory. When you take off memory allocated for other uses by the operating system your PC will probably only show around 3.25GB of usable memory. Move over to 64bit and this limit disappears.

If your doing serious developement then this could be very important. Try running several virtual machines and you soon run out of memory. Servers are more likely to need the extra memory and so you will find that 64bit usage is far greater on servers than desktops. Moore's law ensures that we will have ever more memory on machines and so at some point desktops will also switch over to 64bit as the standard.

For a much more detailed description of the processor differences check out this excellent article from ArsTechnica.

Nothing is free: although 64-bit applications can access more memory than 32-bit applications, the downside is that they need more memory. All those pointers that used to need 4 bytes, now they need 8. For example, the default requirement in Emacs is 60% more memory when it's built for a 64-bit architecture. This extra footprint hurts performance at every level of the memory hierarchy: bigger executables take longer to load from disk, bigger working sets cause more paging and bigger objects mean fewer fit in the processor caches. If you think about a CPU with a 16K L1 cache, a 32-bit application can work with 4096 pointers before it misses and goes to the L2 cache but a 64-bit application has to reach for the L2 cache after just 2048 pointers.

On x64 this is mitigated by the other architectural improvements like more registers, but on PowerPC if your application can't use >4G it's likely to run faster on "ppc" than "ppc64". Even on Intel there are workloads that run faster on x86, and few run more than a 5% faster on x64 than x86.

A 64-bit OS can use more RAM. That's about it, in practice.
64-bit Vista/7 use fancier safety features for where they place vital components in RAM, but that's not really 'noticable' as such.

From ChrisInEdmonton:

A 32-bit operating system on an ix86
system with PAE can address up to 64
GB of RAM. A 64-bit operating system
on x86-64 can access up to 256 TB of
virtual address space, though this may
be raised in subsequent processors, up
to 16 EB. Note that some operating
systems limit the address space
further, and most motherboards will
have additional restrictions.

Not sure I can answer all your questions without writing a whole essay (there's always Google...), but you don't need to design your apps differently for 64bit. I guess what is being referred to is that you have to be mindful of things like pointer sizes are no longer the same size as ints. And you have a whole load of potential problems with inbuilt assumptions on certain types of data being four bytes long that may no longer be true.

This is likely to trip up all kinds of things in your application - everything from saving/loading from file, iterating through data, data alignment, all the way to bitwise operations on data. If you have an existing codebase you are trying to port, or work on both, it is likely you will have a lot of little niggles to work through.

I think this is an implementation issue, rather than a design one. I.e. I think the "design" of say, a photo editing package will be the same whatever the wordsize. We write code that compiles to both 32bit and 64bit versions, and the design certainly does not differ between the two - it's the same codebase.

The fundamental "big deal" on 64bit is that you gain access to a much larger memory address space than 32bit. This means that you can really chuck in more than 4Gb of memory into your computer and actually have it make a difference.

I'm sure other answers will go into the details and benefits more than I.

In terms of detecting the difference then programatically you just check for the size of a pointer (e.g. sizeof (void*)). The answer of 4 means its 32 bits, and 8 means you are running in a 64bit environment.

A 32 Bit process has a virtual addresses space of 4 GB; this might be too little for some apps. A 64 Bit app has a virtually unlimited address space (of course it is limited, but you will most likely not hit this limit).

On OSX there are other advantages. See the following article, why having the kernel run in 64 Bit address space (regardless if your app runs 64 or 32) or having your app run in 64 Bit address space (while the kernel is still 32 Bit) leads to much better performance. To summarize: If either one is 64 Bit (kernel or app, or both of course), the TLB ("translation lookaside buffer") doesn't have to be flushed whenever you switch from kernel to use space and back (which will speed up RAM access).

Also you have performance gains when working with "long long int" variables (64 Bit variables like uint64_t). A 32 Bit CPU can add/divide/subtract/multiply two 64 Bit values, but not in a single hardware operation. Instead it needs to split this operation into two (or more) 32 Bit operations. So an app that works a lot with 64 Bit numbers will have a speed gain of being able to do 64 Bit math directly in hardware.

Last but not least the x86-64 architecture offers more registers than the classic x86 architectures. Working with registers is much faster than working with RAM and the more registers the CPU has, the less often it needs to swap register values to RAM and back to registers.

To find out if your CPU can run in 64 Bit mode, you can look at various sysctl variables. E.g. open a terminal and type

sysctl machdep.cpu.extfeatures

If it lists EM64T, your CPU supports 64 Bit address space according to x86-64 standard. You can also look for

sysctl hw.optional.x86_64

If it says 1 (true/enabled), your CPU supports the x86-64 Bit mode, if it says 0 (false/disabled), it does not. If the setting is not found at all, consider it being false.

Note: You can also fetch sysctl variables from within a native C app, no need to use the command line tool. See

man 3 sysctl

Note that addressspace can be used for more than (real) memory. One can also memory map large files, which can improve performance in more odd access patterns because the more powerful and efficient block-level VM level caching kicks in. It is also safer to allocate large memory blocks on 64-bit since the heapmanager is less likely to encounter address-space fragmentation that won't allow it to allocate a big block.

Some of the things said in this thread (like the doubling of # registers) only apply to x86-> x86_64, not to 64-bit in general. Just like the fact that under x86_64 one guaranteed has SSE2, 686 opcodes and a cheap way to do PIC. These features are strictly not about 64-bit, but about cutting legacy and remedying known x86 limitations

Moreover quite often people point to doubling of registers as the cause of the speedup, while it is more likely the default SSE2 use that does the trick (accelerating memcpy and similar functions). If you enable the same set for x86 the difference is way smaller.
(*)
(***)

Also keep in mind that there is often an initial penalty involved because the average data structure will increase simply because the size of a pointer is larger. This has also cache effects, but is more significantly noticable in the fact that the average memcpy() (or whatever the equivalent for memory copy is in your language) will take longer. This is only in the magnitude of a few percent btw, but the speedups named above are also in that magnitude.

Usually alignment overhead is also bigger on 64-bit architectures(records previously 32-bit only often become a mix of 32-bit and 64-bit values), blowing up structures even more.

Overall, my simple tests indicate they will roughly cancel each other out, if drivers and runtime libraries have fully adapted, giving no significant speed difference for the average app. However some apps can suddenly get faster (e.g. when depending on AES) or slower (crucial datastructure is constantly moved around/scanned/walked and contains a lot of pointers). The tests were on Windows though, and so the PIC optimalisation was not benchmarked.

Note that most JIT-VM languages (Java, .NET) use a significantly more pointers on average (internally) than e.g. C++. Probably their memory use increases more than for the average program, but I don't dare to equate that directly to slowing effects (since these are really complex and funky beast and often hard to predict without measuring)

Windows 64-bit defaults to using SSE2 for floating point which seems to speed up simple operations and slows down complex (sin,cos etc) operations.

(*) a little known fact is that the number of SSE registers also doubles in 64-bit mode

(**) Dr Dobbs had a nice article about it a few years ago.

Besides the obvious memoryspace issues that most people are mentioning here, I think it is worth looking at the notion of "broadword computing" that Knuth (among others) has been speaking about lately. There are a lot of efficiencies to be gained through bit manipulation, and bitwise operations on a 64-bit word go a lot further than on a 32-bit word. In short, you can do more operations in registers without having to hit memory, and from a performance perspective, that's a pretty huge win.

Take a look at Volume 4, pre-Fascicle 1A for some examples of the cool tricks I am talking about.

Aside from the ability to address more memory x86_64 also have more registers allowing the compiler to generate more efficient code. The performance improvement will usually be fairly small though.

The x86_64 architecture is backwards compatible with x86. It's possible to run unmodified 32-bit operating systems. It's also possible to run unmodified 32-bit software from a 64-bit OS. That will require all the usual 32-bit libraries though. They may need to be installed separately.

This thread is too long already, but ...

Most of the replies focus on the fact that you have a larger, 64-bit address space, so you can address more memory. For about 99% of all applications, this is totally irrelevant. Large whoop.

The real reason 64-bit is good is not that the registers are bigger, but there are twice as many of them! That means that the compiler can keep more of your values in register instead of spilling them to memory and loading them back in a few instructions later. If and when an optimizing compiler is unrolling your loops for you, it can unroll them roughly twice as much, which can really help performance.

Also, the subroutine caller/callee conventions for 64-bit have been defined to keep most of the passed parameters in registers instead of the caller pushing them onto the stack and the callee poping them off.

So a "typical" C/C++ application will get about a 10% or 15% performance improvement just by recompiling for 64-bit. (Assuming some portion of the app was compute bound. Of course, this is not guarenteed; All computers wait a the same speed. Your Mileage May Vary.)

With a 32-bit machine you only have 4,294,967,295 bytes of memory to address. With a 64-bit machine you have 1.84467441 × 10^19 bytes of memory.

Wikipedia says this

64-bit processors calculate particular tasks (such as factorials of large figures) twice as fast as working in 32-bit environments (given example is derived from comparison between 32-bit and 64-bit Windows Calculator; noticeable for factorial of say 100 000). This gives a general feeling of theoretical possibilities of 64-bit optimized applications.

While 64-bit architectures indisputably make working with large data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks. In x86-64 architecture (AMD64), the majority of the 32-bit operating systems and applications are able to run smoothly on the 64-bit hardware.

Sun's 64-bit Java virtual machines are slower to start up than their 32-bit virtual machines because Sun has only implemented the "server" JIT compiler (C2) for 64-bit platforms.[9] The "client" JIT compiler (C1), which produces less efficient code but compiles much faster, is unavailable on 64-bit platforms.

It should be noted that speed is not the only factor to consider in a comparison of 32-bit and 64-bit processors. Applications such as multi-tasking, stress testing, and clustering (for high-performance computing), HPC, may be more suited to a 64-bit architecture given the correct deployment. 64-bit clusters have been widely deployed in large organizations such as IBM, HP and Microsoft, for this reason.

Apart from the already mentioned advantages here are some more regarding security:

• x86_64 cpus do have the no-execute bit in their page tables. I.e. this can prevent secruity exploits cause by buffer overruns. 32-bit x86 cpus do only support this feature in the PAE mode.


• Bigger address space allows for better address space layout randomization (ASLR) which makes exploitation of buffer overruns harder.


• x86_64 cpus feature position-independent code i.e. data access relative to the instruction pointer register (RIP).

Another advantage that comes to mind is that the amount of virtual contiguous memory allocated with vmalloc() in the Linux kernel can be larger in 64 bit mode.

Quotation from Microsoft.com:

In the following table, the increased
maximum resources of computers that
are based on 64-bit versions of
Windows and the 64-bit Intel processor
are compared with existing 32-bit
resource maximums.

Kristof and Poshi have stated the main technical differences between 32 and 64 bit OS' the user experience is usually much different than theory.
The 64 bit consumer versions of Windows to date (XP and Vista) have large gaping holes in their driver support.
I have had many printers, scanners, and other external devices flat out not work with the 64 bit versions that work fine with 32 bit versions. These are devices that had 64 bit drivers and they still would not work.
At this point I would recommend you stay away from anything consumer based that is 64 bit from Microsoft until you hear about how Windows 7 handles this, from real end-users, not just the uber-geeks who currently have access to it. Give it 6 months at least and see what people are experiencing.
Personally I will be installing the 32 bit flavor of Windows 7 as my 64 bit versions of Vista is an expensive paper weight that I stopped using eons ago and went back to XP 32 bit.

Some game-playing programs use a bit-board representation. Chess, checkers and othello for example have an 8x8 board,
ie 64 squares, so having at least 64 bits in a machine word significantly helps performance.

I remember reading about a chess program whose 64-bit build was almost twice as fast as the 32-bit version.

The term 32-bit and 64-bit refers to the way a computer processor (also called a CPU), handles information. 64-bit versions of Windows handles large amounts of random access memory (RAM) more effectively than 32-bit systems.

speed may be different in my opinion

Another point to this in regards to Microsoft Windows is that for many years there has been the Win32 API which is intended for 32-bit operating systems and isn't optimized for 64 bit compiling. When I write some DLLs for my applications, I generally compile in Win32 which isn't the 64 bit version of things. Prior to Vista, there haven't been many successful 64 bit versions of Windows I believe as where I work my new machine has 4 GB of RAM but I'm still using 32-bit Windows XP Pro as it is a known stable O/S relative to XP64 or Vista.

I think you may want to also look back on when there was the shift from 16-bit to 32-bit for some more details on why the shift may be a big deal for some folks. The mission-critical applications that a company may run on a desktop, e.g. small accounting packages, may not run on a 64-bit operating system and thus there is the need to keep a legacy machine around, virtual or real.

Changing the size of an address can have some big ramifications and repercussions.

For most practical purposes you probably won't notice a difference.

You must have a 64-bit CPU (most CPUs in the last few years) to install a 64-bit operating system.

There are a few advantages to a 64-bit operating system:

• It will allow you to run more than 4GB of RAM (the maximum number you can address in a 32-bit OS is 2^32 = 4GB)


• It is helpful for working with large data sets (e.g. in Excel) and certain computationally intensive tasks (e.g. Photoshop and big files)


• You can only run a 64-bit program on a 64-bit OS, but you can run a 32-bit program on both (keep in mind a lot of programs come as both, so there aren't too many 64-bit only programs).

Under most scenarios, 64-bit programs use a bit more memory, but for a personal computer, this is typically not noticed.