Hi there,

Which 'version' would be best suited to my main desktop; an AMD64 2-core with 3Gb of memory?

THanks.

For RAM less than or equal to 3Gb there is no problem with 32-bit, but since you have a 64-bit processor, why not to try a 64-bit OS?

O.K mine is a Intel Dual Core 64 Bits
I started which 4 GB RAM
Until I upgrade to 8 GB RAM there was in my case little difference in performance between a 32 bits an 64 Bits OS
Mainly in boot up the system 64 bits is quicker now

Thanks.
I admit to being at a bit of a loss as to the distinction, since both 'versions' seem to run okay on it. I'd have thought something labeled "i386" would _only_ run on x86 32 bit processors, but there seems to be some interchangeability with 64 bit procs. There's clearly something lacking in my understanding here! :-/

A 32 bit OS can run just fine on a 64 bit system. Similarly, 32 bit software can usually run on a 64 bit OS, although you can run into issues if the 64 bit OS is "pure" and doesn't have 32 bit libraries. However, 64 bit software won't run on a 32 bit OS. Similarly a 64 bit OS won't run on 32 bit hardware.

Intel design there processors to be downward compatible. As stated any program/OS that runs a 80386 will run on the latest 64 bit processor but not the reverse.

I think the first two replies to that gave the direct answer pretty well. Your CPU will work fine with either an i386 kernel or an x86_64 kernel, and when running an x86_64 kernel it can run either i386 or x86_64 programs.

The harder question is which is better and why.

So far as I understand, for most users, there isn't much net difference.

x86_64 will need some extra disk space, both because the 64 bit binary images are a little bigger than 32 bit, and because you probably want some amount of "multi lib" meaning some files would have both 32 and 64 bit versions present. With current hard disk sizes and prices, the extra disk space is insignificant. But if you are stuck with obsolete hard drives, it may matter.

x86_64 programs also need a little more ram when running. A few programs need a lot more ram when running. But with 3GB of ram, you are probably far above the point where you would even notice those differences in the type of applications a typical user would run. (For contrast, I work on a high end circuit simulator, where the 64 bit version uses a lot more ram than the 32 bit version, to the point that using the 64 bit version on a computer with just 3GB of ram would be foolish).

x86_64 programs tend to have more L2 cache misses than the same programs compiled as i386, so a large number of programs will run a little slower as x86_64.

But the x86_64 architecture has twice as many general registers as i386 and the GCC compiler can get very messed up by the register shortage in i386 and produce very slow code because of it. So some programs will run a lot faster in x86_64 because of GCC compiler issues. It's almost impossible to predict which programs.

x86_64 also has twice as many SSE registers and GCC will use SSE by default in x86_64 (where it uses legacy floating point for i386). Programs that use large amounts of very systematic math operations ought to run much faster in x86_64 because of the SSE registers. There is significant anecdotal evidence that video and audio encoders (programs to change the format or recompress video and audio) are in this category and run much faster in x86_64.

Almost. Well, in practice, this is the end effect for the user, but only because the team doing the coding has worked around the problem.

In general, it is true that the instructions sets are broadly backwards compatible, but there is one (that I can think of) oddity. In the pre-Nehalem (eg, Core 2 Duo, etc) Intel processors, Intel made barely comprehensible* decsion to leave out some of the virtualisation acceleration stuff from the 64 bit instruction set.

So there are some missing bits, but you'll never notice
you won't run across this problem if you never use virtualisation

• if you do run virtualisation, because the supplier will have written extra code to deal with the situation, your app will just run slower, and unless you do careful back-to-back testing you'll never notice anything other than its a bit slower than you had expected.
• this doesn't apply if you have a Nehalem-arch processor, as they've got it right (reg TM) in their latest release, and AMD got this aspect right from the start, if you can argue that a slower arch, but without this obvious shortcoming, is getting it right

* 'barely comprehensible' may decode to 'marketing, in your language; after all, why would you want to make your 64 bit arch (that you'd be selling, initially, for servers, etc) less capable of virt than your 32 bit one?

The thing to remember is that, from theory, you would expect the 64 bit instruction set to run more slowly (only a little), but as John has pointed out there are counteracting factors, because the instruction set has been cleaned up.

If you are worried about security (and assuming that you aren't running the 64 bit system), there is a case for running the PAE kernel over the 'plain vanilla' 32 bit one, because that gives you the NX bit, which, theoretically at least, offers a little protection against buffer overflow type attacks. Up to you whether you think this is worthwhile on a desktop, but on a server I would definitely go for it (either PAE or 64 bit).

<Edit> Bleurgh. I got carried away with replying to the reply and didn't notice that you actually have an AMD machine. Note that the comment "Intel design there processors to be downward compatible" isn't really as relevant as it might be, when you realise that the 64 bit version of the instruction set was designed by AMD (Intel were still trying to talk the world into buying Itaniums for the high end at the time, which may or may not be relevant) and copied, slightly unenthusiastically, by Intel. So, you don't have the 'crippled for virt' version of the 64 bit inst set.