Reasons for 64 bit Linux OS on 64 bit hardware?

Is 64 a bit Linux OS on 64 bit hardware superior than 32 bit Linux run by that same 64 bit hardware?

I'm aware of the 4GB RAM limit for 32 bit but is there anything else? The 64 bit MSOffice thread has really made me want to put the time into finding the pros & cons from one architecture to the other.

I've not found much to form a conclusion on. Some say 32 bit operates faster and some say 64 is more secure. I remember also reading that video encoding via 64 bit is quicker too.

That's the crux of the argument I've gathered from a few places on the internet so far. What do NBR Linux users have to say?

 

If you have 64bit hardware, you should likely be running 64bit Linux. There are more registers available to software, larger memory space even for 32bit apps, and various other processor features only available in 64bit mode. And since you can still run basically all 32bit apps, there's really no good reason to not have 64bit. The only thing I could see is if you're running with like, 2GB of RAM or something along those lines.

 

Thanks Pitabread. So to look at it from another standpoint, would there be any negatives at all to doing full 64 bit, regardless of how they're outweighed by the positives?

 

First of all there is no 4GB RAM limit on 32bit OSes. Just because Windows has that stupid limiation doesn't mean that this goes for all operating systems.

Another Windows myth? I never heard of that. 64bit addresses are of course bigger that 32bit addresses, so 64bit systems usually need more memory. But in general there is no difference in speed or security.
There are however some proprietary softwares that perform very poorly in a 64bit environment. The most popular ones are surely Adobe's flash player and Skype. But the reason why they are even worse on 64bit than they are on 32bit anyway is not the architecture but their poor implementation.

That's true. amd64 has some nice CPU features enabled that i686 doesn't have due to compatibility reasons. First of all these are the advanced SSE instructions.
The same goes for the security question. i686 kernels often have NX support disabled for compatibility reasons. But nobody stops you from activating it in your own kernel.

 

Wow, I had no idea the 4GB max thing was Windows only! Another + in the right direction.

I assume that when adding NX support to an i686 kernel, this must be done when compiling or is there a patch or module that's added?

From what I read, 64 bit flash in Linux has come a long way but Skype seems to be a lost cause, especially now after the MS buyout.

 

For which applications? When my main work application switched from 32-bit to 64-bit, we were required to perform some tests. I found that for what I was doing, the improvement in speed was 30% (assuming the task was not bottlenecked by I/O). When things are programmed properly and the application is CPU-bound, 64-bit is significantly faster.

 

That's not entirely true. Certain version of Windows also support PAE, which is how 32-bit linux support more than 4gb of ram. Besides, your program will still be limited to 2GB. If you have 64-bit capable cpu, just use 64-bit version of OS.

 

PAE is an ugly hack. Apps are still limited to 2GB address space (or maybe 3 if you do a 3/1 split, which can make the system unstable), and it's not universally compatible. If you don't believe me, listen to Linus Torvalds, who has probably forgotten more about hardware and Linux than either of us ever knew

Agreed. And the hacks to run the 32bit version in a 64bit browser are even uglier.

You can still activate it, but again... there's no reason to really run a 32bit OS. You can still run the 32bit Flash and a 32bit browser and be fine, or get one of the 64bit flash betas that seem to do decently for me. 64bit systems are backwards compatible, so you can still generally run those apps anyway, and Linux does the backwards compatible MUCH more elegantly than Windows does.

 

True. But not as ugly on Linux as on Windows.

I agree with the advice: use a 64-bit OS unless you have a very, very good reason not to.

 

I run 64 bit Linux, but the only point is to use more than 3GB of ram. I find 64 bit everything to be a lot buggier if it exists at all. Unfortunate really.

 

Let me guess: Your applications heavily rely on number crunching. In that case 64bit adresses will indeed improve performance.
But in general I/O is the bottleneck (the biggest one being the one between keyboard and chair frantically looking for runaway keys. ).

 

Odd. It's quite rare for much of a typical user's open source software stack to have any appreciable difference in quality between 32 and 64-bit binaries.

Closed-source software, now, that's another story... (I'm lookin' at you, Adobe!)

It's not just the addressing. The additional registers and the more capable baseline instruction set that most 64-bit binaries target may also be responsible for some of the performance difference.

 

Yes PAE support exists for both Windows and Linux, but I believe the userbase using PAE on linux is more compared to Windows and hence I'd believe it would be stable and performing better at least to a decent extent.... In fact in my work place - we use i686 version of CentOS with 12GB RAM and it is pretty fast in performance....

On linux (in the PC segment) most of the programs would be open source and mostly built using the open source toolchain gcc and gcc compiles code fairly good enough for both i686 and x86_64.

Flash, skype and other proprietary programs - I have no idea why they have such poor compatibilty issues with x86_64 - especially for such a long time (almost more than 3 yrs since x86_64 became a mainstream).

I've come across cases where x86_64 programs/scripts were producing wrong results compared to the i686 ones (I've seen a few perl scripts) but these are not problems with the compiler - but with the way in which the script was written and making assumptions about the CPU word-size. IOW if these are open source programs it will/can be fixed

 

So for the Flash issues, is a good solution just to use a 32 bit browser in the 64 bit OS when/if possible?

 

No the solution is to install adobe's most recent 64bit flash beta. It works really well in Ubuntu anyway.

A few years ago I think a case could have been made against 64 bit. Nowadays there is very little reason not to be running 64bit linux OS.

 

My solution was just to not use Flash.

Amazingly, I have yet to run into a scenario where my productivity depended on it. About the only thing that I miss is the occasional "OMG check this YouTube" link from friends/family... and I'm not sure that's really such a bad thing. (Oh, and since VLC can play YouTube videos just fine, I *could* use that if for some reason I honestly did need to watch something from YouTube... but I'm not keen to let said friends/family know that.)

The other benefit to not using Flash is that it's got a terrible security track record, and without it your system presents a much smaller attack surface. That's *always* a good thing.

 

there is little reason not to run 64 bit on linux. The key argument to stick to 32 bit in Windows is that most apps have gone through a much larger field test in 32 bits. This is not the case in linux. With its heavy skew towards server, 64 bit(key applications anyway) has been field tested for a long period of time. As for desktop oriented application, they didn't go through too much field test anyway(even in 32 bit) given the small population using it, so it doesn't matter.

 

My 64bit Ubuntu has crashed everytime I installed it. Perhaps that's just Unity.

 

Also also, Linux has been 64 bit for a much longer time than Windows. 64 bit linux predates 64 bit intel / amd chips by many years, so by the time AMD figured out the 64 bit instruction set that's now the standard, linux had been running on 64 bit alphas and other server class machines for 5 or more years.

 

Before amd64 64bit architectures were usually addressed in big endian format (alpha, itanium and sparc are actually bi-endian but due to comopatibility reasons they are usually treated as big endian). So even if the address range of 64bit was already tested before amd64 this experience didn't mean very much when porting software to amd64 since the instruction set is totally different.
Actually i386 and amd64 have much more in common than alpha and amd64.

 

I get your point, but honestly if you have to pay attention to endieness when using a C/C++ compiler something's wrong with your libraries. It's far more likely you'll have to pay attention to whether you're on a 64 bit or 32 bit machine

 

I think it would have been more of an issue with their code being compatible with both little and big endian rather than a compiler issue... It is very much likely that you'd have issues with endian-ness in your code - unless the code was being maintained and tested for both little and big endian machines... (especially for codes doing low level work where registers, bit masks, bit shifts are all pretty much common)...

I have come across this issue quite commonly in the embedded systems platforms I work on.... Problems usually arise in 2 specific cases:
1. Improper assumptions made during conversion from network byte order to host byte order.
2. Improper assumptions made when typecasting binary data as structures to access the bit fields (here even different compilers behave differently as the C standards only define the behaviour of compilers handling structures only at byte level and not at bit-level when using bit fields).