Question: Any reason to stick with 32-bit OS if you are 64-bit capable?
 

Never had to make this decision before, because I've always run Linux on 32-bit CPUs. But now I have a choice.

The only downside I can see, and it is a very minor one, is if my 64-bit system has some hardware failure and I want to temporarily move the disk to a different computer and boot from the OS on the moved disk. Obviously that second computer would have to be 64-bit as well (which is not the case in my house - I tend to hang onto old computers). Workaround would be to boot from a 32-bit LiveCD and then mount the drive. Couldn't run 64-bit programs from it, but I could access my personal files.

Are there any downsides to running 64-bit Linux at this point in time? I will be installing LinuxMint13 Maya Xfce, as 13 is the most recent LTS release and I prefer the clean and simple Xfce over the other desktops.

[edit] p.s. - The system has 4Gb memory and I have no plans to upgrade further, so that is not a 64-bit vs. 32-bit concern for me. There are ways a 32-bit system can get around the memory limit anyway. [/edit]

None that I can think of, or that I've ever run into during the last year or so running on 64 bit hardware. I think there were concerns early on about software compatibility, but at this point pretty much everyone is onboard with 64.

64-bit uses 20-30% more RAM, but performance can be many times greater for things like multimedia encoding, encryption, etc.
http://www.phoronix.com/scan.php?pag...204_3264&num=1

If you want to run 32-bit programs on 64-bit, using multilib is a bit more of a hassle, but nothing too difficult.

I can't see any real reason to use 32-bit except for hardware not supporting it or laziness and indifference on the user's part.

There are still a few things which don't run on a pure 64 bit OS, but as mentioned above it is pretty easy to run a multilib setup for those.

It will be several more years before everyone and everything converts to 64 bit. A 20 year old industry standard doesn't just up and die.

The industry isn't dieing, it is changing, and for the better at least in the case of 64-bit. I think 64-bit will last a lot longer than the 32-bit reign.

"The system has 4Gb memory"

It would end up more of a convenience to you. You won't get any real gain for either choice. What you gain from 64 bit will also be lost in lack of resources. In an odd way, you would easily prove the 32 bit will be faster. A common user may run out of ram faster on 64 bit and cause swap to be used. That would negate any advantage of 64 bit.

I make a kind of simple rule. On systems with 6 gig and good specs. I use 64 bit. With less I tend to still stay with 32 bit. Many distro's still suggest it as the proper choice.

I disagree. You would always gain with 64-bit. I don't have any swap and my 2GB of RAM never runs out except when some program screws up and hogs all the RAM, and then it is killed by the OOM killer ... which is very rare. You cannot prove that 32-bit will ever be faster than 64-bit except when you cheat (like use 32-bit only assembly).

Probably true.

You must have a very strange meaning for "prove". The performance difference is very hard to measure accurately and harder to predict theoretically and varies with usage.

A common user with 4GB has no real need for 4GB. A tiny amount of swap ought to get used and that does not indicate any performance problem.

We are almost always not talking about "running out of ram" on such systems. A 64-bit Linux will actively use a little more ram, meaning there is a little less room for caching, which occasionally means a few extra disk accesses. The resulting performance impact is typically too small to measure.

My simple rule is use 64-bit Linux and not 32. Usually it makes no noticeable performance difference. In systems/uses where the difference is noticeable, 64-bit wins. 2GB is plenty for 64-bit Linux for ordinary home use. I no longer consider a system with less than 2GB to be a computer. I know that with significant effort (and 32-bit Linux) you can get a computer with less than 2GB to be effective and useful. But I also know people frequently discard perfectly working computers better than your typical under 2GB PC. Finding a better computer that someone else is throwing away may be less effort than getting your old computer to be useful.

The word "ever" makes your statement false. I have extensively performance tested one of the (closed source) products I work on. On most problems the 32-bit build runs slightly faster than the 64-bit build. The only assembly code is a tiny but key section of 64-bit only assembler that I wrote when trying to port the 64-bit build from icc to gcc (It made a big improvement in the gcc build and a small improvement in the icc build, so I left it in even though I never followed through on switching to gcc). But the same function in the 32-bit build is still the original C++ code.
The obsolete copy of icc we use for 32-bit builds produces faster running code than any 32-bit gcc or any newer 32-bit icc. But I don't think that is "cheating". Like many applications, this one frequently has its performance dominated by L2 cache misses. On the same CPU, running the same problem, a 32-bit build of almost any application will have fewer L2 cache misses than a 64-bit build. Usually, that effect is overbalanced by the fact that gcc is not good at optimizing 32-bit x86 but is good at optimizing 64-bit x86. Sometimes that effect is also overbalanced by the fact that 32-bit x86 uses legacy floating point by default even on systems with new floating point, while 64-bit uses new floating point. Sometimes the fact that 64-bit has twice as many registers wins. On older CPUs, with smaller L2 caches, our 32-bit build had an even larger performance advantage over 64-bit. Even with a very big L2 cache, there will still be some examples in which the L2 cache advantages of a 32-bit application outweigh all other factors and 32-bit is faster.

I think both that RAM disadvantage of 64-bit and performance advantage are big exaggerations of differences that are usually much smaller. I have looked at phoronix benchmarks on that topic in the past (but your link didn't work for me today). Their results include such glaring impossibilities that I am sure they failed to control for at least one important variable skewing the results. A controlled comparison between 32-bit and 64-bit performance takes quite a lot of care. The differences to be measured are small and bigger differences from other factors almost impossible to eliminate.

Well, I've done my own benchmarks in the past and every single program was slightly or sometimes a lot faster on 64-bit. The only program that was slower on 64-bit was imagemagick, and when I tested with graphicsmagick (newer and better) 64-bit was faster. Yes, it depends on a lot of things, but if you can eliminate factors like the compiler, the processor, and any assembly optimizations I think that 64-bit will almost always win.

Some more examples:
http://benchmarksgame.alioth.debian.org/u32q/c.php
http://benchmarksgame.alioth.debian.org/u64q/c.php
http://benchmarksgame.alioth.debian....s.php?lang=gcc
http://benchmarksgame.alioth.debian....s.php?lang=gcc

Just a comment on "eliminating" factors.

What is "eliminating" the compiler as a factor? Most people in this forum use gcc. gcc is one of the best optimizing x86-64 compilers. It is much less competitive among 32-bit x86 compilers. So is selecting a matching version of gcc eliminating the compiler or biasing in favor of 64-bit?
The best version of icc for 32-bit was before they added 64-bit support. So selecting that version makes an impossible comparison. The newest icc is not as good at 32-bit as that old version, but still vastly better than gcc. That same new icc is only slightly better than gcc for 64-bit. Would selecting that same new version of icc for both be fair? (A very different fair from selecting gcc). Or is it still biased in favor of 64-bit? To release our closed source product, we selected the best 32-bit x86 compiler we had tested and the best 64-bit. Those were very different versions of icc. To compare 32-bit to 64-bit performance, I used those very different compiler versions. Is that introducing the compiler as an uncontrolled variable of the comparison? Of course. But so is every other choice. You can't eliminate the compiler as a factor.

Increasing the size of L2 cache makes a bigger difference to 64-bit builds than to 32-bit. Obviously it is unfair to compare performance with the 32-bit running on a different CPU than the 64-bit. So use the same CPU. But which one? Select one with an unusually high L2 cache size and you have biased in favor of 64-bit. With an unusually low L2 cache size and you biased in favor of 32-bit.

When benchmarking, always remember the low numbered (outer edge) disk sectors have faster transfer rates and lower relative seek times than high numbered sectors. Are disk access speeds affecting your benchmark? Did you control for the physical positions of the files?

There are also a wide variety of cache alignment and TLB alignment factors (details differ greatly by CPU model). Combine that with the various address randomizations (done to make various exploits less effective) and you have a formula for large random performance changes independent of any factors you could control for.

FWIW, I went with 64-bit. One thing that appears different are the fonts. They looked better in 32-bit LinuxMint13 installed on this same hardware. What I'm looking at now reminds me of the days years ago when you had to do a lot of twiddling to get "Linux to look as good as Windows", and you still never got it 100% there. I had no concerns about the fonts from a 32-bit LinuxMint13 intallation, but this 64-bit install has me wanting to "fix those ugly Linux fonts" again. Maybe there was some package I installed on the old 32-bit that I have neglected on this new 64-bit install. I didn't have to twiddle xorg.conf (or whatever it is called these days) for 32-bit LinuxMint13 to look good like I used to have to do years ago with older distros.