I just need to know whether it is advisable to install 64 bit version Linux distros for the foll config:

1. Intel Core 2 Duo T5470 @ 1.6 Ghz (Dell Laptop) with 4GB DDR2 RAM
2. Intel Dual Core Desktop E5400 (Desktop) @ 2.5 Ghz with 2GB DDR-2
3. AMD Athlon X2 250 with 2 GB RAM DDR-3 (Desktop)

Is there a huge improvement in performance over 32 bit ? Some people argue that the difference is barely noticeable for RAM under 4GB and unless you are planning to use huge chunks of RAM like 8GB or 16GB it is wiser to stick to 32 bit ...

http://ark.intel.com/products/31788/...800-MHz-FSB%29
http://ark.intel.com/products/40478/...800-MHz-FSB%29
http://www.amd.com/us/products/deskt...omparison.aspx

All of them support 64-bit.

The performance difference is much greater than compiler optimizations, and it mostly seen for video encoding and some other programs, ex:
http://www.phoronix.com/scan.php?pag...u_32_pae&num=1

In our time, I'd have to say that there is no wisdom in sticking with 32-bit. You can always run multilib for those obscure and obsolete programs that don't support 64-bit.

1 members found this post helpful.

The world, or at least the PC platform world, is in flux. There is a huge base of 32-bit boxes and manufacturers are cranking out 64-bit. Intel, in its ultimate wisdom is making 64-bit processors that can do virtualization and others that can't (bless their greedy little hearts) and who knows what's on the horizon.

Would you really notice the difference between a 32- and 64-bit installation on the same hardware, well, probably not in everyday use. If you're doing heavy-duty mathematics or CAD, maybe-to-probably. What you will notice is that there are a bunch of 32-bit only applications out there in the world that will not run on a 64-bit-only box -- it looks like you're a Slackware user and you can install AlienBob's multilib package so that you can run 32-bit applications on 64-bit Slackware, so that's not too much of a concern. Those would be things like GoogleEarth, Adobe Acrobat Reader and the like; 32-bit only.

Fact is, you can't have too much RAM. Memory is cheap, 4G doesn't cost much, 8G doesn't cost much more. Not being memory-bound is worth it.

One thing you may like to explore is virtualization -- VirtualBox or something similar. What that does is let you run multiple machines on the same hardware at the same time (so, yeah, you can run 32-bit Slackware in a virtual machine on a 64-bit Slackware host). You only need a couple of things for virtualization: a reasonably fast multi-core CPU, the more RAM the better and a good-size chunk of disk space. Platforms are cheap, RAM is cheap and huge disk drives are too. Gives you options.

So, how about the future? Well, 32-bit platforms will be going the way of 16-bit platforms -- never to be seen again. Not next week, probably not next year, but it's coming. The next wave will probably be 128-bit (or more) processors, obsoleting 64-bit platforms. Time and technology do not stand still. If you're happy with your hardware, you're probably going to have it for, what, five years? More? Less? This isn't Microsoft, we don't have to throw away hardware to be able to run (in order) Vist, Win7 and, ooh-boy, Win8 in a few months. And, with Slackware, you can count on long-term compatibility and, importantly, stability.

So, should you go 64-bit? I'd say, yes, you should. I'd also urge you to get the dual-sided DVD from Slackware that has 32-bit on one side and 64-bit on the other (neat, huh?). I have two 64-bit platforms and a couple of 32-bit laying around and I install and keep up-to-date Slackware on all of them. Personally, I like the 64-bit better -- it's faster on roughly the same clock speed processors on a 32-bit and a 64-bit box both with the same amount of RAM. I do know that comparing a five-year-old box with a 6-month-old box is not really relevant (not really apples and oranges but maybe two different varieties of apples) but I'm glad I made the switch and will continue to replace older stuff (when it completely gives up) with 64-bit only hardware.

So, anyway, a few thoughts.

Hope this helps some.

2 members found this post helpful.

Probably not. But it depends on how you use the system.

There is almost zero reason for the performance advantages of 64-bit to be either larger or more likely on an 8GB system than on a 2GB system. If you run typical processes on a 2GB system that don't get a benefit from 64-bit and compare that to the same activities on an 8GB system (either four times as many such processes, or more likely just having less disk I/O because you have a lot more caching) it will still be no faster in 64 bit than 32 bit.

If a specific app gets a big performance boost from SSE2 and/or having twice as many registers, it will get that same big performance boost on a system with 2GB as it would on a system with 8GB.

Some other people quote a major performance difference across a wide range of applications (see post #2 in this thread). I'm pretty sure that is also wrong. That testing must have been flawed, because the results aren't reasonable.

Still depends on internal details of the application programs that are very hard for a prospective end user to predict. A lot of heavy-duty math or CAD programs are internally more symbolic than numeric or have other reasons to work more with pointers than with numbers. If you combine that with moderately large problem size (.5GB to 3GB) you hit the strongest reason that 32 bit might be significantly faster than 64 bit: Same number of pointers manipulated but every pointer twice as large means the 64 bit app has a terribly worse miss rate on the L2 cache compared to the 32 bit app and that factor swamps out every other performance difference.

Lots of math or graphics problems get a giant benefit from SSE2 in x86_64 (32 bit mode has SSE2 but with half as many registers and the compiler typically won't use even those).

So your heavy duty math or CAD might be a lot slower or faster in 64 bit compared to 32 bit. You can't predict even the direction of that difference knowing just "heavy duty math or CAD". If you don't do a good controlled test of the specific use, you don't know which is faster.

I doubt it. 16 bits was already too little before the 8086 was invented. 32 bits had very little room for growth when the 386 was introduced. When AMD64 was introduced, its 48 bit virtual addressing had geometrically more room for growth above then current needs than the 32 bits of the 386 ever had. A linear amount of time corresponds to roughly a geometric increase in memory but only a linear increase in address size. So the jump from needing 48 bits to needing 64 bits should take as long as the jump from needing 32 bits to needing 48 bits. But that could be longer than the time between the 386 and AMD64 because the 386 was more overdue vs. memory needs when introduced than was AMD64.

As 48 bit virtual addressing becomes insufficient, CPU designers and the developers of one isolated part of each OS can shift to or toward 64 bit virtual addressing. That can happen with none of the giant changes to compilers and the rest of the OS accompanying the 32 to 64 bit transition or even bigger changes that were needed for 16 to 32.

A prediction should also factor in the fact that the market is larger and the range of needs is larger. Combine that with the greater compatibility between 48 bit addressing and 64 bit addressing as compared to 32 vs. 48. That implies 64 bit addressing will arrive much further ahead of any need by ordinary users and then coexist in the market with 48 bit much longer than 48 bit has been coexisting with 32 bit.

All that puts the step beyond 64 bit addressing too far in the future to be the "next wave". I think the next architecture shift as significant as x86 to x86_64 will be something other than an increase in address size.

I suggest you stick with 32 bit.

On paper a 64 bit OS can be faster. It was created without legacy issues. The 32 bit is almost fully supported. I doubt you have a need for the 64 bit but you are welcome to try both and see what you think.