Looks like Valve may be preparing a 64bit version of the Steam client

with 32bit you can still access 2.5 GB memory. That's freaking many for a lotsa games. Minus MMORPGs. And very modern full HD games with HD textures. Which are way too far and few between on linux. Unfortunately.

I use a mac and linux PC both 64 bit so I'm ok with steam going 64 bit.

Here are some advantages to go 64-bit, going from better performance to increased security:
https://stackoverflow.com/questions/607322/what-are-the-advantages-of-a-64-bit-processor#607347

For people who have trouble installing the 32 bit version of steam, just use flatpack. works ok. What I am happy about here is that moving to 64 bit means at some point(hope as soon as possible) they will ditch 32bit and hopefully games will follow that trend.

Quoting: HoriAnything below 8G is inadequate for gaming, no matter the genre.
If you play older games, or small indie games you might be able to. But all modern games and even more complex indie ones require 8G for full performance.

2.5GB is too few even for just Google Chrome, let alone games.

You seem to be confusing system RAM and what a single application actually needs. I wouldn't recomment having less than 8 GB on a machine to play games either. But that's not all for the game, but for the system, caches, ... Many games are fine with accessing up to 4 GB as a 32 bit application.

Quoting: HoriOne newish game that comes to my mind is Stellaris - that one is 32bit (poor choice IMO) and can't use more than 4GB... but it REALLY needs all of those 4GBs (well maybe not in the early game, but mid-late game it certainly does).

Developers might face problems similiar to Linux support in general: Engine, middleware, whatever stuff only supporting 32 bits. If you're starting a new game not too small, I agree you should go for 64 bit nowadays. I wondered if maybe too many people are on 32 bits still, but it seems it's less than 5%.

Not so excited about the possible 64 Bit Client, but the Steam Client UI needs an overhaul. The android app is even worse.

Quoting: HoriYou CAN do with 4GB but for many games that means closing your browser and other applications while playing, as many games have 32bit engines and won't benefit from more than that anyway. But remember those 4GBs are shared between your OS, your apps, and the game

A single 32 bit process can access not more than 4GB. If your application is divided into multiple processes (which is pretty much standard by now), each process can access 4GB. It's not like you just need to spawn multiple processes to have an unlimited access to RAM, but still. As far as I understand you don't even need a 64 bit OS for that, a 32 bit OS with enabled PAE works also. Hardware support for PAE is as old as the Pentium Pro from 1995.

What games would technically need more than 4GB per process is hard to tell. "Big" games can mean a lot of things. "Big" textures are loaded into the RAM of the GPU, so those don't count. One of the biggest game I played in the recent time was Hyper Light Drifter. It fits into 4GB... and it wouldn't even need a quarter of a GB if they wanted. *

*) That is not meant as critique. They just didn't happen to have a full blown programmer on board and decided to use Game Maker for their game. That's completely fine. Awesome game! :)


Last edited by Doc Angelo on 10 August 2018 at 11:25 am UTC

The memory argument always come back in a 32 vs 64-bit discussion, but as many pointed out, it's just a limit for one process -- which can indeed be bypassed by PAE, but Linux devs would like to remove this "hack" as soon as possible because it's a reason for a lot of issues. ("the only real major failure of the x86 is the PAE crud" -- Linus Torvald

But the real main point of going full 64-bit is that all the 64-bit CPUs have a better common base of instructions, and have more registers, allowing to do some optimizations directly at compile time. It also remove a bunch of obsolete x86 extensions.

If the same program can run on a very old Pentium as well as on the latest 32-bit CPU, it is because the x86 architecture is a huge pile of extensions, so that it is always compatible. But the way it works is that for each instruction the CPU receives, it look for it through its several layers of instructions, starting from the very basic 386 instruction set layer and up to the latest AVX-512 instruction set layer. And, as much as compatibility is a good thing, in the case of a CPU there are so many extensions that it was slowing down the whole execution. See X86-64#Architectural_features.

In the case of the Steam GUI, I'm not sure this is going to change a lot of thing but it's true that it's a step into the right direction since 32-bit CPUs are going instinct now -- and I sure hope that Steam won't take more than 4GB of RAM :D

But for the case of games (which is not linked at all to Steam going 64-bit), the access to SSE and SSE2 instruction set and more registers by default can have a real impact on the games perfs.

My computer doesn't run any 32-bit code until I start steam. I think it is a bit silly to load a bunch of 32-bit libraries for steam if I just want to play a 64-bit game. I tend to forget to install some of those 32-bit libraries on new installs as well. Now that I run ubuntu it can suggest most of them, but when I was on arch it required a few minutes of looking up what the packages was called and install them.


Last edited by Ketil on 10 August 2018 at 3:40 pm UTC

64bit Client for linux/windows for steam client will be huge cuz i am only useing 64bit i am moved over. :). But yeah some programs has to be 32bit to work. :) And need to activeate 32bit architecture.