[SOLVED] Would it be smarter to install the 32bit version or the 64bit version?
Slackware - InstallationThis forum is for the discussion of installation issues with Slackware.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Would it be smarter to install the 32bit version or the 64bit version?
I am currently using the 32bit version of Slackware 14.1, but I was wondering if (on my hardware) there would be any benefit to using the 64bit version instead.
My hardware:
Intel 495PSN
Intel "Prescott 2M" Pentium-IV 640 (3.2Ghz)
2GB of 533MHz? of RAM (dual channel, 2x 1GB sticks)
(I don't think my video card or what drives I use matter)
I used to think that if you could run either, you should use 32-bit. Addresses are smaller, so more code should fit in cache, which means that 32-bit code ought to have fewer cache misses. So I tried running some CPU benchmarks in 32-bit mode vs. 64-bit mode. Turns out that CPUs spend a lot of time copying data, and they can move twice as many bytes per word in 64-bit mode, so realistic 64-bit benchmarks beat 32-bit benchmarks, despite having more cache misses. Now I always use 64-bit when available.
So, yes you should use the 64-bit version, unless you have a good reason not to. If you really need 32-bit apps you can use multilib to run it under 64-bit.
I used to think that if you could run either, you should use 32-bit. Addresses are smaller, so more code should fit in cache, which means that 32-bit code ought to have fewer cache misses. So I tried running some CPU benchmarks in 32-bit mode vs. 64-bit mode. Turns out that CPUs spend a lot of time copying data, and they can move twice as many bytes per word in 64-bit mode, so realistic 64-bit benchmarks beat 32-bit benchmarks, despite having more cache misses. Now I always use 64-bit when available.
good you did effort
also 64bit instructions are longer (thanks to intel)
not that they have to be used
but 64bit you get twice as much registers and most of them are twice as long, so they can do more in most cases
like you got a loop that does something to some data.. like a picture
the picture probably won't fit in the cache anyway (like i got 2MB per core, my guess is about 75% is useful for a program)
so the code itself... i mean loop unrolling can get better performance despite having more code (depending on a case ofc)
PAE shouldn't influence much
@OP
amd64 all fine unless you run out memory, not that you will save some amazing amount by going 32bit only
If you have 64-bit capable hardware, you should use 64-bit software to get the maximum capabilities from your hardware. If you need 32-bit afterwards, use multilib.
I still say ram is the choice even if you have the ability to run full 64 bit.
At 2G you are at a crossroad. I'd still consider the 32 bit version to leave a bit more real ram. 64 bit helps you with using more ram and larger program access to ram. It wouldn't help you to try to run a 64 bit application needing 4 gig of ram.
In a normal home system, I doubt you'd notice much either choice.
How long until 32-bit systems and\or software gets unsupported? I've only ever have had 4Gs RAM under my 64-bit so can't say but would look at using 32 as going backwards? They are free to try both and see or if you can up the RAM.
I tend to lag everyone else in hardware specs and was excited to get my first 64 bit machines a couple of years ago.
After initially installing 64 bit Slackware 14.0 I eventually reverted them to 32 bit 14.1, both are now running Slackware 14.1+ 32 bit (as are most of my other machines).
I see no notable performance differences (each has 2GB RAM, AMD processors).
My reasons for reverting were due to a single legacy app that requires Wine and a preference to not go multilib, another application that requires Qt3 among other things and the stack did not build well under 64, and the desire for commonality across my own systems which still includes a roomfull of 32 bit machines.
I have a new hard drive in transit for one of them and will likely set up a 64 bit install on a separate partition for fun, but I have no compelling need to run 64 bit... yet.
Conclusion: you'll probably do fine with 32 for now.
i don't blame intel, amd would probably do the same (i would)
also designing cpus is a looong process, just wish they talked to each other
I would like to blame Intel just because, and I'll admit that either could be thought of as being "to blame" but I was referring to this
Quote:
Originally Posted by page linked
In 2001, Intel launched their first 64-bit processor named Itanium with a new parallel instruction set. Instead of accepting the new Itanium instruction set, AMD developed their own 64-bit instruction set which - unlike the Itanium - was backwards compatible with the x86 instruction set. The market favored the backwards compatibility so AMD won this time and Intel had to support the AMD64, or x86-64, instruction set in their next processor.
AMD being the ones to develop the instruction set though I suppose they had their hands tied by the past.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.