64bit vs 32bit
 

I noticed there are some distro's that offer both a 64bit and a 32bit version, what is the difference. I have a Intel dual-core processor, can I run the 64bit version or do I need the 32bit one?

The 32 bits version runs on a 64 bits box
The 64 version do not run a 32 bits box
I do have a Intel dual core box so I run 64 bits version


all the best

64bit Vs 32bit
 

Roughly speaking this refers to the transfer rate of data and so a 64 bit operation is faster and so I would choose this type. Packages (programms) come as both 32 and 64, thus if you choose 32 you may have problems installing a 64bit package but not the other way. Others maybe able to explain in more detail.

Fred.

I recommend 64-bit. Lots of people will tell you that it doesn't make any difference. All the more reason, IMO. All hardware now being manufactured is 64-bit. Software is following as fast as it can. Install 64-bit, you get the OS of tomorrow, and you lose nothing today.

I think all the Intel dual-core processors support 64bit. But I'm not certain.

If your CPU supports 64bit, it probably doesn't make much difference whether you choose a 64 bit or 32 bit distribution. Either will run on a 64bit CPU.

32bit applications will run with a 64bit kernel (64bit applications won't run with a 32bit kernel). But probably you would use almost entirely applications with the same 32 vs. 64 choice as the kernel. Package management would get trickier otherwise.

64bit uses larger pointers, so applications that internally use a lot of pointers will need more memory to run in 64bit and will have more cache misses so they will run a little slower.

64bit has twice as many ordinary registers and twice as many XMM registers as 32 bit. The GCC compiler doesn't deal very well with the small number of registers in 32bit mode. In many types of source code, the GCC compiler will generate more complicated and slower machine code because of the shortage of registers. In applications where that happens inside important loops, 64bit will be faster. But it's hard to guess which applications those would be from just the external description of applications.

32bit supports a wide variety of CPU models, each of which would benefit from model specific optimizations of compiled code. If you install precompiled binaries or even compile on your own machine without restricting the optimization to be for the local machine, you will have code that isn't well optimized for your machine.
64bit doesn't yet have nearly as wide a variety in model specific optimizations. Precompiled 64bit packages are well optimized for any existing x86_64 CPU. This effect is most significant in applications that do complicated floating point computations. So if you make significant use of such applications and want to use precompiled packages, that gives an advantage to 64bit.

Some of thoe above factors balance out. Others are minor for ordinary users. So it all nets back to probably no significant difference. But of course, your mileage may vary.

If you have a LOT of ram and hope to get a lot of performance boost from using ram for file caching, the 64bit has a big advantage. The 64bit kernel can directly manage an almost unlimted file cache. The 32bit kernel cannot. I have 8Gb and I expect this issue is the biggest performance boost I get from the 64bit kernel (but I haven't run any comparisons). So my above guess of "probably no significant difference" assumes either you have 4G or less of ram, or that ram will be filled by multiple large processes, not by either a single large process or a lot of file caching. (I have performance tested Windows XP32 with 3G vs. XP64 with 8G and found the better file caching of XP64 makes a dramatic difference. XP32 cannot do any more file caching with over 3G of ram than it can with 3G of ram. I don't think the same is true of Linux 32bit. So Linux 32bit with 8G of ram would be closer to Linux 64bit with 8G of ram than XP32 could be to XP64. But I still expect a significant difference in file caching performance).

There are very few program that actually use 64bit integers. In 32bit mode, 64bit integers are much slower than 32bit integers (more than 2 times slower for the simplest operations, sometimes up to 30 times slower). In 64bit model, 64bit integers are only a little slower than 32bit integers. So if your application uses 64bit integers, 64bit mode is much better.

A few application need more than 3G of virtual address space. Those won't work at all (at any speed) with a 32bit kernel. So if you expect to run such things, you'll need a 64bit kernel.
For many applications, there are alternate algorythms that could run faster and use less virtual memory by using more virtual address space. Such designs rarely make sense with a 3G limit on virtual address space. As 64bit kernels become common, some programmers may decide to put those algorythms in with conditional code, so the applications use the fast algorythm in 64bit mode and the slower one in 32bit mode. Then there will be a new reason for 64bit to be faster.

I recommend 32-bit. For almost any everyday use, I doubt if you will see any speed difference. Plus, there can be SW issues--e.g. the java applet:
http://www.java.com/en/download/manual.jsp

I second rickh. AFAIK all mainstream Linux-64bit distros come with 32-bit support, no extra magic needed to run 32-bit apps. For instance, I'm writing this in 64-bit Firefox, which happily uses 32-bit plugins. Plus, there are some RAM addressing issues with 32-bit. E. g. Cinelerra developers state their 32-bit version is less stable due to this.

I believe that 64-bit is the way to go. I agree with richk. The 64-bit can run 32-bit
with no problems. But 32-bit can have problems running 64-bit,but if your a standard user it doesn't really matter

Go 64bit. It's faster, and all of the incompatibilities that you'll have can most likely be fixed with a small workaround. (Like flash)

Well, no, it's not faster. Not in a general sense, at least. Databases, multimedia processing and scientific calculations, those do benefit from 64 bit but. As for the rest, those will actually suffer. Not much but they will.
For the general user, the advantages and disadvantages probably cancel each other out so you aren't off any worse but you won't see any dramatic improvements either. However, it is worth bearing in mind that many 32 bit packages are not optimized for today's processors. If you look into distros like Gentoo or FreeBSD, you'll find that they offer options to compile 32 bit packages specifically for dual cores - those will always run better than ready-made packages that are targeted at a Pentium III or IV.
If you have more than 3GB of RAM, or you need applications to access more than 2GB of RAM at once or you regularly use the sorts of application I pointed out, then 64 really is the better choice. As for it being the future, yes, it is - but you'd better take that with a pinch of salt. Even Windows 7 (scheduled for 2010) will still have a 32 bit version and over 80% of Vista users today are running 32 bit. So as far as proprietary applications go, you won't have to worry about certain things not being available in 32 bit, not for the next 10 years at least. Neither will it be an open source issue any time soon. There are plenty of users who don't see the point of dumping a working 32 bit system just to be able to run something more trendy. That many developers now use 64 bit systems is totally irrelevant. They fall exactly in the category of scientific/database users who tend to do many things at once so you shouldn't be surprised if they do.

I'd go with 32-bit, as pixellany suggested. I have run into a lot of software compatibility issues with 64-bit. Things like JAVA, Firefox, Truecrypt, and WINE, have problems. You have to make tweaks to get them working. Also, compiling some programs also don't work if they do not support the 64-bit architecture. And don't forget you will need 32-bit libraries if you try to build a program that only works with a 32-bit system.

The only reasons I have gone 64-bit on my servers is because they have more than 8GB of RAM and aren't using "common" applications. On my workstations, I only use 32-bit, even though my Intel Q6600 Quad core can support 64-bit.

Ellaborate please. If more bits in a single stream don't mean more speed, then why did we get up to 32 bit operating systems? Why wouldn't we just stick to 16 or 8 bit systems?

While I think it is a coin toss on systems with less than 3gb of ram, I do run 64bit on my 2gb machine. As far as a speed difference on "normal" apps (firefox, thunderbird, etc) there will be no noticeable difference in speed. When you do see a huge difference in speed is in apps like video conversion (avi->mpg) or anything that would bring a 1ghz PIII to its knees. Then you can see (30%?) differences.

Because most programming languages use 32 bit integers by default so if your system is only 8 or 16 bit, it has to put in extra work to cut them up and reassemble them. To understand why 64 bit is not necessarily (and in most cases is not) better than 32 bit, see the post by johnsfine above.

Yes, lazlow, 30% is in line with expectations. This is what you will get out of specific types of application while many other ones will perform somewhat worse. As you point out, the difference is hardly noticeable but that would apply to using 64 bit for databases/multimedia processing as well unless you handle large chunks at once.

That being said, I am a 64 bit user myself. I program quite a bit and I frequently use the sorts of application that run faster in 64 bit. Not to mention that it is the easiest and most efficient way to access all of my RAM (32 bit has a limit of just over 3GB physical RAM). In short, it depends on your hardware and on the sort of uses your computer is put to.

Not at all. Almost every data rate inside and outside of the CPU is identical in 32bit and 64bit mode.

It refers primarily to the size of a pointer. But there are other differences.

What is "more bits in a single stream" supposed to mean?

8bit systems primarily used 8 bit data and 16 bit addresses. The integers used in ordinary problems rarely fit in 8 bits, so most integers needed to be processed in multiple steps. 16 bit data was much faster because it reduced those multiple steps.

16bit systems primarily used 16 bit data and 16+ bit compound addresses. Many integer values didn't fit in 16 bits so those needed to be processed in multiple steps. The compound addressing was needed because 65K of data (addressable by 16 bits) wasn't enough for typical problems. The compound addressing was slower than simple addressing. But even with the compound addressing some problems were too big to fit.

32bit systems primarily use 32 bit data and 32 bit addresses, but have internal data paths that are 64 bits or wider (mainly to compensate for the fact that the CPU is so much faster than the caches, which are so much faster than the memory). Also, 32 bit systems have full support for 64bit floating point.

Few applications need more than the 3Gb that can be used (after kernel overhead) with 32 bit addressing. Even fewer need more than 32 bit integers. This represents a serious difference from the 16->32 transition. When the 16->32 transition occurred, 32 bit integers were already common in 16bit programs and many 16bit programs were difficult to squeeze into the space provided by the compound addressing. But on the 32->64 transition, 64 bit integers are very rare in 32bit programs and few programs are difficult to fit in 32bit addressing. Typical problem sizes have grown a lot since the 16->32 transition, but they haven't grown as much as the effective difference between 16 bit and 32 bit.

64bit systems primarily use 32 bit (integer) data and 64 bit addresses. Those CPUs could have been designed to make 64 bit data the default type. Then 32 bit integers would be slightly slower than 64 bit integers in 64 bit mode, just as 16 bit integers are slower than 32 bit integers in 32 bit systems. But the designers recognized that few problems need integers bigger than 32 bits. Significant use of 64 bit integers where 32 bit would do, would waste cache space and make the design slower.

The continuing growth in typical problem sizes will soon make problems that don't fit in 3Gb common (MUCH sooner than integers that don't fit in 32 bits become common). So it makes good design sense for the next major architectural step beyond x86 to have a default pointer size of 64 bits. But at the same time another flaw in x86 was addressed:
X86 has too few registers, especially for use with compilers that are mostly portable (most compiler modules architecture independent and only a few modules designed just for x86).

When an ordinary user switches to 64bit mode, the most likely benefits are from the increased number of registers. Using 64 bit addresses instead of 32bit addresses is typically a drawback, not an advantage.

It wouldn't have made sense to change x86 to first double the number of registers (plus other minor advantages of AMD64) and a few years later double the default address size. There is too much effort (especially in a Microsoft dominated software industry) to making such changes just a few years apart. Also, some applications already need 64 bit addressing. So the x86_64 design makes sense, even though it gives most users 64 bit addressing before that is really a good thing.