What's the Benefit to 64 over 32 bit installation
 

I was just curious if there is a real noticeable benefit to running 64 bit OS on a 64 machine, rather than running a 32 bit OS on a 64 machine. I'm not really concerned with some sort of bit transfer, Ghz altering, alternative bus travel type issues. I mean from just staring at a screen and operating the software, is there a real difference?

The reason I ask, I use an old HP Pavilion G series with AMD proc. I used Slackware 14.2 64 bit with Alien Bob's multilibs installed for several years and my old 32 windows games seem to run fine. Since then I've install 15.0 64 with AB multilibs and several games will either not run or run very poorly. I've also tried Kubuntu 19.10 64 and all the games worked fine. Now it's no longer supported I then tried Ubuntu 20.04 64. Still ify on the certain games running. I've further tried Kubuntu 22.04 64. It has serious Wifi issues, so who knows if anything would work.

So I got to thinking, maybe I'm trying to put a square peg in a round hole. If I mostly use 32 bit, why don't I just run 32 bit and not worry about 32 compatibility issues?
Thanks

The downsides to running a 32 bit x86 kernel:

1. Memory management

>4Gb memory management on 32-bit x86 is something of a hack (Physical Address Extensions - PAE). This mechanism is also in use on systems with 4Gb of memory or less, if the kernel supports a virtual address space larger than 4Gb.

In practice, this means that while a 32-bit kernel can make use of up to 64Gb of memory, a process/application can access at most 4Gb minus the address space is shares with the kernel, which is typically 2Gb, or 1Gb if the kernel is so configured. While the 3Gb userspace/1Gb kernel option may seem like the superior option, it comes with a performance penalty.

To see just how quickly you run into the 2Gb userspace barrier, just open a dozen or so web pages in Seamonkey and see how much memory it consumes. Even if the system as a whole has lots of free memory, the browser will struggle as it approaches the 2Gb (or possibly the 3Gb) mark. You mentioned "staring at the screen"; there's a risk you'll be spending quite a lot of time staring at unresponsive applications.

On embedded systems with less than 2Gb of RAM, one typically runs far fewer processes, no GUI, and a non-PAE kernel, which means this is not much of an issue. That's not exactly a typical use case for Slackware, though.

2. 64-bit software

It's become increasingly common to see projects shipping pre-compiled binaries for x86-64 only. These will obviously not run at all under a 32-bit kernel.

3. The availability of large integers in some very common programming languages.

Wait, make that HUGE integers: On x86-64, C and C++ compilers support 128-bit integers. These are surprisingly useful, not least because IPv6 addresses are indeed 128 bits in length. No workaround has (yes) been implemented for 32-bit compilers, so userspace applications that manipulate such large integers need to be specifically (re)written in order to work on 32-bit systems.

How common is this, you ask? Not very, but the popular and immensely useful SpamAssassin project has some optional modules that depend on Math::Int128, so they just won't compile or run on any 32-bit system.

I was running a 64bit RazPi 4 on a 32bit OS and didn't notice any real difference. At the time, much more was available ie 32bit packages than 64bit.

Kernels have to be compiled with PAE enabled for 32bit if you want to access memory above 4G. Guys pushing limits might notice it, but I didn't.

Most 64-bit Linux distributions ship with 32-bit libraries as well, and thus can run both 64-bit and 32-bit applications. Slackware64 is an exception.

The Raspberry Pi is based around the ARM architecture, not x86. 32-bit ARM has its own address extensions for 32-bit called "Large Physical Address Extensions" (LPAE), and while PAE on x86 extends the physical address space from 32 bits to 36 bits (64 Gb), ARM LPAE goes all the way to 40 bits, meaning you can access to up to 1024Gb (1Tb) of memory on recent 32-bit ARM CPUs.
Sounds about right. We've gotten so used to Windows, which consumes insane amounts of memory all by itself, that we may not realise that it's perfectly possible to get work done using a non-Windows system with 4Gb RAM or less.

The reason I chose Seamonkey in the example above is that, unlike some other browsers, it runs as a single process. While this may use less memory overall in a given scenario compared to the one-process-per-window approach used by Chrome, it also means it has to live within the confines of a 4Gb address space, typically with a 2Gb/2Gb userspace/kernel split, on all 32-bit platforms.

I don't think so. Fedora does provide for multilib,I believe. But IME most distros have 64bit libs in /lib & /usr/lib. So /lib/ld-linux.so points to a 64bit lib. A 32bit program will reference /lib/ld-linux.so expecting it to be a 32bit lib, and puke on what it finds. I have Mint here and wine is 64bit only. And Mint = Ubuntu with go-faster stripes.

Usually the Multilib is an option, not a default. BUT, also most Linux distributions ships systemd. Slackware is an exception.

However, I for one never needed Multilib in a 64bit system. Be it Slackware, Ubuntu or openSUSE. Or Fedora.

What? WindowsXP used to be happy with 128MB memory consumption for itself. Or even less, as I remember that long time ago I used a computer with WindowsXP which had 128MB as entire memory.

Even the today Windows 11 barely requires for itself around 2GB, which is only double of 1GB usually consumed by Plasma5. Or XFCE.

Does really matter, when the Mother of Memory Hogs is Firefox which can swallow 1GB memory only by open a media rich news site? However, I can easily arrive at a Firefox eating 12GB memory in a browsing session. ;)

And let's do not forget of Fathers of Memory Hogs which is Chromium and its inglorious bastards.

What? The legend of 2GB on 32bit systems hits again?

Excuse my sloppy memory, but it wasn't debunked by the former forum member Darth Vader long years ago, finally convincing the Slackware Team to switch the kernels to PAE on Slackware 32bit?

How much time passed since? 10 years or so?

Installed both, on partitioned 60G ssd. No problem with either of them.

64bit is good for modern browsers, they eat a lot of memory and are faster on 64bit base.
32bit is good for pure 32bit wine, if you want old windows stuff that is no longer developed.

Multilib is harder to maintain but some people depend on it, primarily steam users I think.

And Windows NT ran fine with 16 Mb. I fail to see what the memory requirements of decades-old versions of Windows have to do with Windows or Linux today.

For what it's worth, the memory requirements of the Linux kernel have ballooned as well, but not to the extent we've seen in the Windows world.
"Only" double. That's hardly impressive.

Have you tried running Windows 10 or 11 on a 2Gb system? I have, many times, as I usually install Windows in a VM or on physical hardware about 10 times a week.

And yes, I can confirm that indeed, 32-bit Windows 10 can be said to "work" on a system with 2Gb RAM as long as you have an SSD or a fast hard drive, but the fun only lasts until you start actually trying to do something with it.

Since staring at the Windows desktop isn't what people usually sit down in front of their computer to do, I'd say that for all intents and purposes, a 2Gb Windows 10 system is not really "usable" in the real sense of the word.

As for 64-bit Windows... even Windows 7 x64 consumes almost 2Gb RAM just booting up. Windows 10 requires a bit more, to the point that it can easily take in excess of 10 minutes from the desktop appears before the system becomes somewhat responsive if you use a mechanical hard drive; the slowness is due to excessive paging, and SSDs are good at masking that issue (while wearing down at a breakneck pace). Adding an extra gigabyte of RAM makes a world of difference.

Compare any of those setups with Linux, 32 or 64 bit, with a somewhat lightweight DE, running on a system with 2Gb RAM. Yes, the markedly better performance of Linux is certainly in no small part due to less background services being included in the distro, and of course the ability to select leaner desktop environments, but still: Including tons of cruft in Windows that can't be removed by the user, is the choice Microsoft made. It's therefore entirely fair in my view to refer to that entire bloated mess as "Windows."True. I see the same issues with Chrome, Chromium, Brave, Pale Moon, and Seamonkey. Except 32-bit Seamonkey doesn't get that far, as it locks up when memory consumption approaches 2Gb.

An interesting issue I've seen with multi-process browsers on Windows, is that Windows may start generating low memory warnings after a few days, even though there's plenty of free RAM. I get such errors frequently on a system with 32Gb RAM, even though 15Gb is reported as "available."

I suspect this could be due to memory fragmentation, but I haven't really investigated the issue yet. I wonder if anyone have experienced similar issues running Chrome or one of its siblings under Linux?
Which "legend" would that be? Surely not the description of PAE that you'll find in the official documentation from Intel, and also in the Documentation subfolder of the Linux kernel source?

The decades-old memory requirement is relevant in today's world in the sense that he's a troll and will use anything as an excuse to start a fight.

To answer the question since nobody else wants to... Running a 32-bit OS would probably be the simplest if all you plan on running is old games. Newer games could run into problems with a PAE kernel.

A PAE kernel only gives the OS the ability to map >4GB of RAM. The 4GB limit still applies at the application level. So if you run a 32bit OS on a 64bit CPU, Slackware will be able to make RAM available to individual applications, but those apps will still only be able to address <4GB per the limitation.

This is useful for running multiple applications since you could theoretically have 3 different apps, with each each (for example) consuming 2GB of RAM. Adding PAE to the kernel does not necessarily address the issue of memory usage at the application level.

I miss Darth!
:D

If it's just for old 32 bit Windows games, then there is an alternative.

You can have all the benefits of running a 64 bit OS without the need to install multi-lib or wine to play your old Windows games, using Conty.sh: https://github.com/Kron4ek/Conty

I have a blog entry about setting it up on Slackware64: https://www.linuxquestions.org/quest...machine-38601/

Many games will work using that method without issues. There were some tricks to get Starcraft (98 version) running properly: https://www.linuxquestions.org/quest...kware64-38602/ But now I have it running better than it ever did on Windows... no surprises there, because my hardware is significantly better than it was in 1998.

Enjoy!

32-bit Kernel and userland tends to be more buggy with way more corner cases nowadays since few developers use or dogfood 32-bit systems. For example.

The above was not an issue on 64-bit kernels.


1: https://git.kernel.org/pub/scm/linux...797589c7a5510b

Luckily, I somehow dodged this, none of my 3 test machines have been affected by this thing yet.
Athlon, Phenom, Turion, kernel 5.15.29 huge and custom, nvidia 390.147, all using acpi-cpufreq.
But I only use 64bit for networking, haven't used a 32bit network stack since kernel 2.6
Probably gonna freeze them to 5.15.29 since they're not really exposed or anything.

Agreed.

For me it's not really about advantages. It just makes sense to use a 64-bit installation over 32-bit installation on 64-bit hardware.