I have a dual-boot system running an Intel Pentium Dual E2180 CPU (the system monitor tells me, I haven't a clue!) and have always run the 32-bit version of Ubuntu. At the moment, 11.04 Narwhal.

When I next move to a newer version, should I choose the 64-bit version? I am aware that there can be problems/disadvantages with the 64-bit version, but after a bit of Googling it is difficult to find out what these are. Many articles concerning this subject are very out of date. I wondered if any LQers could either advise me or point me in the direction of any good articles on the subject.

Am I right in thinking that the 64-bit version will enable both "sides" of the processor to work in tandem on one task, whereas at the moment they can only work on different tasks independently? Or have I got that wrong?

Thank you for any advice you can give.

You're aware of problems/disadvantages, but you can't find any evidence to support this awareness . I don't know of any articles that will help you either. I suppose if you plan to use really ancient and unsupported software, 64-bit may not be the way to go. Personally, I've been using a 64-bit, multilib OS since at least September 2006. I haven't had any significant problems. In fact, I don't remember that last time I had to deal with an ABI issue.

There are no significant issues with 64-bit OSes per se.

However, some software which are distributed only in binary form and as 32-bit executables will require the 32-bit library support. On Debian and Ubuntu based systems, this is easy to achieve with a simple . So you should have not many problems with the 64-bit version of Ubuntu.

That's wrong, or at least mangled (I think...I am not absolutely sure what you mean by 'side'; assuming that you mean the two individual CPUs). Two independant-but-on-the-same-chip CPUs are limited to working on two separate threads/processes (the difference isn't really relevant, here); this is the same as two processors in separate sockets and doesn't change whether the processors are 32 bit or 64 bit (or, twenty seven and a half bit, if there were any of those).

For some tasks (not that many, but some important 'outlier cases'), the task itself can be written so that there are several independent threads/processes, and the separate CPUs can work on several of those simultaneously, and that's not dependant on the 'bit size' of the processor.

For some processors, not including your 2180, two cores can appear as four by working on four threads 'quasi-simultaneously', but that isn't dependant on the bit-size of the processor or the bit-size of the software that it is running.

When 64 bit consumer processors first became available, there were a number of proprietary apps there were not immediately made available in 64 bit form. For this reason, 64 bit OS software was made available with a library set up that allowed the running of 32 bit software on a 64 bit OS, such that the running software 'wouldn't even know' that it was not running on a 32 bit system. while it could be tricky to figure out what was wrong, if things did go wrong, these days it is less of a problem because most proprietary software is also available in a 64 bit build, and hence can be run in native 64 bit form on a 64 bit platform.

(Open source software was less of a problem, because, in principle, at least, the source code was available, and it could be run through a compiler with the sixty four bit switch thrown. Well, and then the debugging had to begin, but if someone wanted it badly enough, it could be done.)

Did you want an answer? Well, I have not just one answer, but two!

• Yeah, why not. It shouldn't cause any real problems
• No, why do it, there aren't any big advantages

(maybe, more isn't better)

Small advantages (of 64 bit) include

• better big memory support ( >>4G)
• more secure than non-PAE kernels
• non-PAE kernels don't support > 4G memory, and PAE kernels are a bit messy and slightly slower (but not much) than other 32 bit kernels
• 'Cleaned up' instructions set makes 64 bit slightly faster than 32 bit in some applications, and software is more likely to be compiled to use all the facilities of your processor (because 64 bit is more uniform...doesn't apply to software specifically recompiled for your processor)

Small disadvantages include

• 64 bit pointers are bigger than 32 bit pointers (d'oh!) and that leads to (slightly) slower code, lower code density in memory and that leads to less effective caching, which, in turn, leads to a speed loss
• there may still be some 'hold out' apps that require 32 bit libs and that consumes extra disk space and memory space
• 64 bit apps, in general, are probably less well tested than 32 bit, due to user numbers and testing history

On the speed issue, in general, these days, the balance is probably with 64 bit, but not by very much. Of course, if you have and are needing to use memory more than 4G (and a PAE kernel doesn't do it for you), then the lack of a need to swap with 64 bit might make a significant difference to speed.

1 members found this post helpful.

That is completely wrong.

Advantages of 64-bit
1) SSE. 32-bit compilers are designed to support older 32-bit chips that don't have SSE. So they use "legacy" floating point instead of SSE floating point even though all recent 32-bit chips have both legacy and SSE floating point. Legacy floating point is trickier to program, which often results in significantly less efficient code generated by the compiler. 64-bit compilers use SSE because all x86_64 chips have SSE.
2) Number of registers. x86_64 has twice as many SSE register names and twice as many general register names as X86 (the X86_64 general registers are also each twice as big as in X86, but that is less important). In 32 bit mode the 64-bit CPU can still use all the registers (through an internal process of register renaming) so that it can overlap instruction execution (start a much later instruction that modifies a specific named register even though an earlier use of that register isn't done yet). But the compiler output is still limited to the register names of the 32 bit architecture. X86 has too few registers for a portable general purpose compiler such as GCC, so GCC often produces inefficient code due to lack of registers. To deal with 32 bit X86 well, a compiler needs to be designed from the ground up for X86 and only X86 (like now obsolete versions of Intel's ICC compiler were). But X86_64 was adjusted to be easier for more general compilers. So GCC can produce great X86_64 code despite the fact that most of GCC was designed for portability across architectures rather than focus on a specific architecture.
3) Virtual address space. X86 Linux has a 3GB per process limit on user address space and a 1GB per system limit on kernel address space. Few applications for ordinary users would use over 3GB virtual per process, so that limit is much more significant in some business uses. At around 16GB physical memory, the 1GB limit on kernel virtual becomes a serious impediment to Linux managing all of its own internal data structures. So 32-bit PAE can address 64GB physical ram, but stops being practical a little below 16GB. 64-bit has nearly unlimited kernel and user virtual address space. In some LAN uses, some NFS caching, etc. (that I don't understand myself) can make heavy use of kernel virtual space so that 1GB limit could become serious with far less than 16GB physical. But those situations seem unlikely in personal use of Linux.

Disadvantages:
1) Pointer size: Pointers are used a LOT in many applications in ways a non programmer or inexperienced programmer wouldn't understand or expect. The CPU moves around and processes 64-bit pointers just as fast as it does so for 32-bit pointers, so the bigger pointers don't directly affect speed. But, when data structures use a lot of pointers, those pointers tend to fill up the L2 cache causing more L2 cache misses and making the program run slower. That is especially true of older 64-bit processors that had L2 caches only large enough for efficient execution of 32-bit applications. Some newer 64-bit CPUs have larger L2 cache and thus take less speed hit from the difference in pointer size.
2) Instruction size: 64-bit mode has larger average instruction size. The direct execution speed of these larger instructions is the same as that of smaller 32-bit instructions. But the larger instructions can clog the path between the L1 cache and the core of the processor or even fill the L1 cache enough to cause more cache misses. So indirectly the larger code can cause slower execution. This effect is partially balanced by the fact that GCC compiles badly for 32-bit mode and that sometimes results in extra instructions in the 32-bit build that weren't needed in 64-bit. So the 64-bit build of a routine might have larger average size per instruction but the 32-bit build of the same routine might need a few extra instructions (so the code size advantage of 32 bit is smaller than the raw difference in average instruction size).

Everything about 32-bit PAE that can make it slower than 32-bit non-PAE is present at least as much (generally more so) in 64-bit. So those tiny differences might be fair to introduce in a comparison between PAE and non PAE within 32-bit, but they are irrelevant to differences of 64-bit vs. 32-bit-PAE. The biggest such difference is the time needed for TLB misses. All three modes should have the same (low) number of TLB misses (if running the same applications in the same amount of physical ram). PAE has slower TLB misses than 32-bit non-PAE. 64-bit has slower TLB misses than PAE. The memory overhead of page tables (and the resulting extra time to write the tables and extra cache misses to read them) is double for PAE vs. non PAE within 32-bit, while in 64-bit it is slightly more than in PAE.

I completely agree with both those answers. I added lots of details to maybe help the exceptional user for whom those answers don't cover it. But for typical users those are the answers.

Hmm. Well on balance then, I think I'll stick with 32-bit. But thank you all for your detailed responses.