In my experience, each time you go more bits in software, you're slowing down your system, as it's using up more system resources (same hardware). (historically going back from mid-eighties to today I mean)

Google it, and you're told everywhere about the RAM limitations being overcome.
That's actually wrong (as it is a Windows-centric answer), because 32bit (Linux) OSes use PAE (and some offer a non-PAE version for compatibility with netbooks and very old desktops).
And wo what? Whoop-tee-doo! Who needs 8TB of RAM, or 64bit hard-disk partitions 18 million-TeraBytes large... on their laptop?

What interests me is not RAM, but other things.
Like actual performance. Stability. Reliability. Multi-tasking.

I see everywhere bloggers saying 64bit is "faster", more reliable, etc... but not one of them offers any in-depth knowledge as to why, or even less any proof.

Here are some specific questions:

Does an AMDx64 running 32bit Debian-something (Debian/Ubuntu/Mint) still multi-task just as well? Does the processor's multi-tasking require a 64bit OS in order for it to be turned on? And if so, does Debian actually take full advantage? Will it run un 32bit emulation mode with a 32bit OS? Or does the processor multi-task programs despite a 32bit OS running on it?

Spectre (and Meltdown): since no 32bit processors seem to be on the vulnerability lists, is it possible that one of the conditions in order for the Spectre exploit to work, not be met, when running a 32bit OS on an AMDx64? Does the Spectre exploit rely on 64bit code to work? Or does it really not care? It may not care about the OS... but if the exploit is 64bit code, I figure you can't run it in the first place. None of this seems to be covered in the pages explaining the exploit that I have found.

Are 64bit OSes and programs (really)faster, or (actually)slower? This may sound like a "stupid" question with an "obvious" answer... but I have not been able to uncover any straight answer on this, aside from bloggers or experts just giving the easy and the obvious that comes to mind: (they presume that) it's faster.
But consider that larger chunks need to me moved, some code may be larger or larger chunks anyways - how does that translate into the x64 world?
In my practical experience in OSes and apps, although very very dated from a long-gone past, more bits can be more cumbersome, can need more RAM to do the same tasks, and as a result slower. An update on the capabilities of 64bit processors tells me things may not be the same as they once were, but the answer to me isn't all that "obvious".

Hey Timmi,

There are alot of specific questions and comments in your post and you seem to be leery of the typical answer to this question (RAM).

In a nutshell, practically speaking with today's hardware, you will likely not notice any performance improvement using most *commonplace software* whether using a 32 or 64 bit version of any given linux distro on 64-bit hardware.

That said, this will, in my opinion, become less true as hardware evolves and its capacity to, as you say, move large 64-bit wide chunks of information more quickly improves. So, in theory NOW and in practice soon, performance WILL be better with a 64-bit OS on 64-bit hardware. And even though you're tired of hearing the RAM answer, you will be able to better manage anything more than 4GB with a 64-bit system and there are real-world applications where this is useful. I myself run a machine with 32 GB of RAM on which I commonly have up to 5 VMs running simultaneously. Performance would be much worse on a 32-bit OS and stability as well (the system would freeze up running out of physical RAM since the hypervisor will not let the VMs use swap ...).

As a purely academic exercise, remember the limitations back in the late 80s, early 90s, running a 16-bit OS on emerging 32-bit hardware ...

2 members found this post helpful.

I'm not "leery" of the RAM answer, I'm tired of it being used as a cop-out because "experts"/bloggers/"reporters" don't have a bloody clue as to what else there is to it.
After all, with the amount of RAM we can address in 32bit Linux using PAE, it's quite inconsequential. Several Windoze versions are the ones that are handicapped by the 4GB RAM limitation, not Linux.

I noticed that you chose the word "should" in your statement about your VMs. They aren't using 32GB RAM each - in fact, I'm willing to bet that each one is under 4GB, which should make it readily compatible and just fine in a PAE environment. Test it if you're curious, let us know.

I really do care to know whether multi-tasking is OS-dependent in Linux, or if it is actually OS-independent. That would settle the matter. (And I have my suspicions whether Linux even takes advantage optimally and fully at all, for quite some time now, because of an intermittently stalling 64bit Linux OS that I have been using for several versions.)

And whether there is the same Spectre vulnerability in 32bit, is just taking that same question a little bit further.

After all, if you can make an argument that things don't work as well in 32bit, why would it be any different for Spectre?

And depending on the answers to both elements, there may (or may not) be strong compelling reasons to stick to 32bit for now (or not).

And yes, I remember the 32-bit versus 16-bit world (I even remember 16 bit versus 8bit). That is what I was referring to, when I was talking about things slowing down. I was in sales of IT solutions at the time. And I clearly recall operating systems, software programs, gobbling up more system resources, become "slow as molasses in January", when you switched to 32bit code. (same hardware, not different hardware - comparing different hardware does not test the comparative performance of Xbits versus Ybits software, but only highlighes performance differences between generations of hardware).

Hi again Timmi,

Apologies for my use of the word "leery" - no disrespect intended.

Physical Address Extension (PAE), in my opinion, is a transitionary paging technology (similar to the old LIM-EMS model from the 80s and 90s), which in itself requires a certain amount of performance overhead in its implementation, that is becoming less and less necessary given the preponderance of both 64-bit hardware and software, including operating systems. Several are already no longer available in 32-bit (certain linux distros, MacOS ...), so the move to full 64-bit is upon us. As such, the discussion is almost academic.

Just to be clear, my 5 VMs are mostly allocated 8 or 4 GB each, so the 32 GB is often used to 90% ...

With respect to multi-tasking, it is OS-independent. You will simply be able to do more or less of it, and the performance will vary based on a wide variety of factors, including those we are discussing today.

As for Spectre vulnerability, I am not a security expert, so I will let other more knowledgeable members here address that concern.

Cheers - hope this helps.

Yes, I remember EMS vs. Extended. But are you sure that the comparison is the correct one to make?
I believe that PAE is more akin to "extended" memory of the time, not "expanded" (ems from l-i-m), which required a special memory expansipn board, with a special set of drivers, and software that was able to use it. And as such, it came with a performance hit compared to extended... except that it was still faster than your programs doing disc-swapping. (which is kind of moot, because the original main motivator for it was to have larger spreadsheets, in RAM) PAE may page it, but it isn't the big mess that EMS was.

Listen, I am not disputing that everything's going 64bit, and that all new systems are 64bit.
But none of the people buying new computers with Windoze10 on them are scrapping that to install Linux. (0.001% maybe, so none). The average person is concerned about voiding their tech support, warranty, etc.
All the while there is this huge park of computers, collectively, that has outdated processors, that either require a 32bit OS to keep them humming, or if 64bit, have the Spectre vulnerability, and if Intel, also Meltdown.

In my experience, simpler software has always been more robust, and faster. I wouldn't be surprised if in a billion years from now, that adage would still hold true. And because of all these computers out there, if 32bit can help mitigate the vulnerability, it is certainly something to look into, and good to know about.

Oh, and the distro I had in mind, when speaking of 32bit OSes, was Linux Mint. Not so irrelevant.
Depending on how this whole discussion about 32bit turns out, Mint 32bit would certainly be more than just a decent option for any computer.

And there are other very good 32bit distros, like Bodhi, Antix, Slitaz, which are great for netbooks, and there are also highly rated MX17 and Peppermint which are good alternatives to Mint for slightly more powerful boxes. After others discontinued 32bit, all their userbases grew - and of course they're all competing in the 64bit space as well.
And many of these projects have announced that they will continue to provide 32bit for as long as it remains possible (from upstream). These are among the best of the best.

I believe that much of the migration to 64bit is a general misperception that it's faster and better. You read that everywhere - but no one is substantiating it. I am questioning that notion, as I'm suspecting that everything's still using the 32bit instruction set under the hood except for memory addressing, and there is actually very little, to the point of being very very rare, software that uses the rest of the 64bit instruction set. (for a simple reason: doesn't need to, and uniformity, easier programming and maintenance of 32 and 64 bit versions - so there has been, until now, incentive to NOT enable any 64bit instructions in software programs, even if it may have yielded a mild, probably imperceptible, performance gain. There's no incentive, and it would go against best-practices).

Where I DO suspect 64bit to be beneficial, is in design software (CAD, for example), where you'd work on parts and part assemblies, or renderings, that flirt with the 4gb page size boundary or exceeding it. But how many here do CAD? I do, but how many others? And I have to do mine on Windoze, because you can't just substitute AutoCAD, SolidWorks, Fusion360, etc. with some random free software under Linux (getting into explanations as to why will take up too much space here, and is off-topic, so I'll leave it at that). So again, a main justifier of 64bit isn't present on Linux.
To be fair, there's also video editing, which definitely benefits from more RAM. But that's not my world, and the same questions need to be asked: is the industry-standard software available in a Linux version? Or are they only making it for Mac and Windoze, for example?

As a sidenote, it doesn't really matter how many discontinued their 32bit Linux... how many do you need no your computer anyways? There are still more distros than we can shake a stick at.
The best ones (with the exception of Arch offspring) are still available in 32bit.
As far as I'm concerned, Linux could use some consolidation and less distros (which only confuses newcomers, dilutes user base, donations, and people resources (for development and support) - and none of that dilution is beneficial to the distros, or the community as a whole).

If in fact the OS had no play at all, in the multi-tasking part of it, that could mean bad news for a 32bit OS being used to mitigate Spectre.

But it is also good news, for 32bit performance.

answers to these two questions would interest me as well...

I am not sure why you think that multitasking is not OS dependent. It isn't distribution dependent. linux has always been a multitasking operating system but since one might consider it basic to its functionality then you could argue that it is.

While there are CPUs / hardware specifically designed for multitasking it is the kernel that does the work.

I thought some 32 bit CPUs were susceptible.

https://www.linuxquestions.org/quest...es-4175621536/

If one buys a modern 64 bit system and uses a modern 64 bit OS and in the OS they tend to use 64 bit currently compiled programs they could notice a decent speed increase.

32 bit tends to have a number of backwards compatible compile settings and uses in some cases a very old compiler.

Unless you are forced by hardware or some odd software issue you should run 64 bit in this day and age.

1 members found this post helpful.

Well its not stupid, just the wrong question.

When AMD first released the 64 bit instruction set, OSs were slightly slower. Now, generally, they are not. How have the OSs improved? In reality they haven't, at least not directly.

Firstly if you need a pointer, or anything that looks like a pointer to a 64 bt address, that is going to take more information than a pointer to a 32 bit address. That should mean that 64 bit is slower (and of course lower cache compactness).

What has happened since is that 64 bit compilers have improved (particularly as the AMD 64 instruction set is more regular, but there is a better register set) and that has been enough in most cases to overturn the fundamental advantage possessed by a shorter-pointer processor. at least with C probably also C++. Not sure if you write in Fortran, ADA, python, Java, Java Script, APL, Ada how much this applies to you. It possibly does, but I probably couldn't find supporting data even if I tried.

I don't know, but I suspect that no one has done much about 32 bit spectre, because 32 bit isn't considered 'serious' any more. Processors that are incapable of running 64 bit are now old and Intel has abandoned Spectre support for rather younger processors than those. On the other hand there may not be a real world exploit that runs on 32 bit.

You need to take into account that Linus has said that PAE is 'a mess' and he wishes that he'd never done it. I don't know what this equates to in terms of performance but there must some loss whether it is trivial or obvious. But, on the other hand, almost anything is faster than paging (on spinning rust).

2 members found this post helpful.

One problem in the context of AMD 32-bit processors is their lack of SSE2 instructions. The web browsers have gradually been demanding these, which apparently make Javascript better, easier, or something. The last working version of Firefox for such a system was 48.

I think I found one.

https://github.com/doitsujin/dxvk/wiki/Common-issues

Quoting forum posts that quote other forum posts (that 32bit processors are also vulnerable), isn't the utmost in reliability of information.


Here is the complete list of processors vulnerable to Spectre and Meltdown.

I haven't kept up to date over the years, with the AMD nomenclature as to what names equate with what in terms of technology (32bit, 64bit, cores, etc. etc.), but I am sure that some of you can probably tell at a glance whether any common 32bit processors are on that list. But if you look at the lists of Intel deskptop processors, of Mobile processors, there are only 64bit processors on that list (even the very few Atom processors on there are 64bit multi-core ones). Here's the lists of AMD desktop processors, and of Mobile processors susceptible to Sceptre.

PS: a processor that is internally 64-bit, with some sort of 64bit instruction set, but has a 32-bit data bus, is still a "64bit processor", even if you don't like the 32bit motherboard. It's not about what we like, it's about what code it can execute.

Interesting about the instruction set. I suspect that only some JS programs wouldn't work. Coming to mind are more complicated JS programs such as in-browser drawing apps. Come to think of it... maybe encryption too, which covers more and more these days.

However, on Firefox's website, it seems to me that I've seen the 32bit download offered alongside the 64bit not too long ago.

Not sure why this is a discussion. Is the question that progression to 64 bit from 32 bit is not really progression? I thought there were hardware limits to the amount of addressable memory with 32 bit and these limits are higher with 64 bit. As software gets more sophisticated, we need more memory. So what? Hardware is cheap. My 64 bit workstation does far more and is orders of magnitude faster (based on simple perception) than my old 486 DX2-66.

I do get that all of the old 32 bit computers in the world are probably still usable, so having a 64 bit only world makes them unusable, but candles are still usable as a light source, it's just that no one wants to use them when electricity is readily available, in most places that is. Maybe I am missing the point...