64 bits or 32 bits on AMD athlon x2 ram 4gb?
 

My question is: is it really much difference between 64 and 32 having 4GB of ram?
I know that AMD Athlon processors are 64-bit, but I want to know, is it really much advantage having only 4GB of ram?
---
If not much difference would you prefer a 32-bit because they are more compatible and have more applications ... etc.
---
Which is better option?
I use fedora 15 & debian squeeze.

Procesor: AMD 64 Athlon X2, 4GB RAM, DD ATA 320, ATI RADEON HD SERIES

what is the diffrent between 32bit & 64bit in linux system.

As far as I know, standard 32 bit kernels don't support more than 3GB memory. You need a PAE kernel for that. 64 bit does not have that limitation. According to http://www.phoronix.com/scan.php?pag...ty_pae64&num=1, performance of 64 bit is (far) better.

I've run 32-bit Ubuntu LTS versions for a long time. After a failed upgrade to 10.04 LTS, I decided to give 64 bit a go. For my (mostly) limited needs it's fine. My feel however is that 32 bit is still the better option with regards to application choice. I tried to install Songbird yesterday and it failed; not sure why, might be because of 64 bit.

Which one is the better option? I don't know.

There is no reason not to use 64-bit if you have the hardware.
Been doing it (almost exclusively) for years. All this angst over Flash (who cares) and games or whatever. FWIW the 64-bit Flash Beta from Adobe seems to work o.k., but I just use it to look at mind-less sites like the BBC.

There is no benefit to sticking to a 32-bit OS anyway. Most applications have 64-bit compile options and prebuilt packages, and the others that don't are easy supplemented out for those that do.

Some systems do offer a multilib option, but realistically you'll never really benefit from using it.

I use Slackware64 13.37 without multilib and I honestly have zero usage or need for installing the multilib packages and 32-bit software.

Example of comparison: ZSnes vs bsnes

Zsnes is 32-bit only x86 assembly. Project is dead for all anyone knows since it's no longer open source. It's deprecated, outdated, and useless because bsnes has support for 64-bit using C++ coding, is modern, is open source, and is currently maintained. So why use an old outdated garbage program when I can run a newer better one?

Yes, in 64 bit mode your processor can use more of its features. In binary distros you will also benefit from 64 bit, because of the compile options. All 64 bit x86 CPUs can make use of SSE2 features, so the 64 bit binaries are compiled with that feature, for example. To get the most speed out of your CPU you have to build your binaries yourself.

32 bit systems do not have more applications. The only compatibility problems are with some external devices that don't have 64 bit drivers. Such devices are rather rare nowadays, I would think.

That depends on how you use the system. If you only are surfing the net, doing some office work and watching some videos you will not notice a difference of speed or the lack of a part of the RAM. If you are doing more "number crunching" work, like encoding videos, working with large images or rendering 3D images/videos you will see a good speed-up on 64 bit. You also will benefit from more usable RAM if you plan to use virtual machines.

Try to install and use Wine or Virtualbox on a 64 bit system without multilib, you will not come very far.

This is true for the default kernel of a 32bit distribution which is compiled without "HIGHMEM", if you build your kernel with HIGHMEM it can support up to 64GB of RAM. The restriction remains that it can use a maximum of 3GB for one process.
For Virtualbox there is not restriction without multilib on 64bit systems. One can even use 32- and 64bit guests on a pure 64bit Virtualbox.

To the OP's question:
It is more difficult to maintain a multilib environment than a pure 32bit or a pure 64bit system. So if you're new to Linux and need 32bit packages (for example wine) than I'd recommend to go for a pure 32bit system. :twocents:

Markus

Are you sure? I get this when I try to install Virtualbox via sbopkg on a pure 64 bit system:If you can confirm that Virtualbox can be compiled and run (even with 32 bit guests) I will open a new thread about this issue to not derail this thread.


I don't know for Fedora, but for Debian this is not true. The package manager will automatically install 32 bit libraries if necessary.

I'm running virtualbox on a pure Slackware64-current system but I'm using the installer from the Oracle-site http://www.virtualbox.org/wiki/Linux_Downloads ("All Distributions - AMD64").

Well, it depends.
For Slackware one has to be careful with updates when using multilib. Other systems do it more automatically but one can have issues when compiling for 32bit systems (I installed Arch with multilib and thought about this thread: http://www.linuxquestions.org/questi...achine-896859/)

But you are right, with "userfriendly" distributions like Ubuntu or Mint and if one does not compile anything it doesn't matter if it's pure 64bit or multilib.

Markus

64bit tends to be slightly faster, even for normal 'desktop' tasks. For some tasks like audio ripping, video encoding, etc 64bit can be a lot faster-

http://www.tuxradar.com/content/ubun...bit-benchmarks

BTW, those are 2 year old benchmarks run using only 2GB of RAM. I'd expect that is there has been much change over the last 2 years 64bit would be faster still.

No. For most uses, the performance difference would be small.
No. Applications, add-ons, device drivers, etc. that are harder to install in 64 bit are rare, and those that won't work at all in 64-bit even rarer. You probably won't have any compatibility issues with 64 bit.

So if you have 4GB ram and want 32-bit Linux, select a PAE kernel. That isn't a big deal. It shouldn't complicate the 32-bit vs. 64-bit decision.

Also to clarify that phrase "don't support more than 3GB":
1) With or without PAE a 32 bit Linux supports only 3GB virtual memory per process. That is usually not an issue for ordinary users. More than 3GB physical is useful despite that limit because of caching and running multiple tasks.
2) Without PAE, the amount of physical ram supported by 32-bit Linux is determined by details of BIOS design. It varies a lot among BIOSs. I recall seeing as low as 2.75GB and as high as 3.75GB. (I probably have seen even higher and lower and forgotten). Around 3.5GB is common.

Most 64-bit distributions of Linux are multilib. I've never used one that wasn't. I expect there would be a few more applications that aren't available if you choose a non multilib distribution.

Some applications run faster in 32-bit mode than 64-bit mode. In Windows, where I've done more testing, such applications run fastest as a 32-bit app in a 64-bit OS; slightly slower as 32-bit app in 32-bit OS, and even slower as 64-bit app in 64-bit OS. I expect the same is true in Linux, but I'm not sure.

If you have a 64-bit multilib Linux and heavily use a specific application that uses a lot of CPU time, you can easily install a 32-bit version and check to see if it is faster and keep it if it is faster. With 32-bit Linux or non multilib 64-bit Linux, you can only use the app bit size that matches the OS bit size.

For ordinary users, none of that matters. You probably have no CPU heavy application that you use a lot, unless it is something like video editing for which so many experts are certain the 64-bit build will be faster that retesting that is probably a waste of effort.

I'm sure there is some distribution in which multilib is more difficult to maintain than pure 64bit. But multilib support in Debian is very smooth. You don't need to be aware of it except when you make special use of it and then it is pretty easy. Multilib support in Red Hat based distributions, including Fedora, is even smoother than in Debian.

I tend to suggest that a 32 bit system is the way to go unless you have way more than 4 gig.

Some people think 64 bit is better or faster somehow or maybe newer but it really only has it use in the proper place. That place is for systems that have and NEED to use a lot of ram and systems where the apps can take advantage of that extra ram. Otherwise you are actually loosing ram to unusable data.

Quote from Linus Torvalds, and here the topic is not faster execution of some 64 bit applications, the topic is the access of RAM and the advantages of 64 bit in that:So this is not only an issue with the applications you run, but also with the kernel itself. Which simply means that 32 bit systems even with less then 4GB of RAM tend to be slower than 64 bit systems.
And why should one buy a fast processor and then running a system that is slower that it can be. Sounds like buying a sports car and don't use the highest gear. But as always, just my :twocents:

In tests they are only slower by a very slim amount. They are slower only because there is no legacy issues in the 64 bit kernel and the fact that newer compilers tend to be used.

As to speeds, almost no one could tell in a blind test. One would have to use very dramatic tests to ever have any noticeable effect. Sure, a handbrake rip of 10 minutes to 11 would be some common ratio I'd guess. Many apps not fully using processor would never show up.