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.

Anything 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.

One 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.

You 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.

I hope they make SteamOS 3.0 totally 64bit yeah i know. totally 64bit system is very hard to do. :)

Even windows has still 32bit programs and such..

I hope they make SteamOS 3.0 totally 64bit yeah i know. totally 64bit system is very hard to do. :)

Even windows has still 32bit programs and such..

Actually, going from 32 bit to proper multilib with 32+64 bit was harder than going from 32-bit to 64-bit and forget about the applications not supporting 64-bit yet. Back in 2006 when I ran gentoo we didn't have any proper multilib support. We compiled the 64bit applications, and either ran 64-bit only, installed binary 32 bit libraries, or had a chroot with a separate install for 32-bit applications. After some time they changed the ebuild format so that compiled the libraries for both (or had a pure system of 64-bit only).

If I remember correctly I believe debian and ubuntu wasn't too great at multilib at that time either. Looking at the debian wiki I see a news item from 2010 backing me: "Multiarch-ready apt (v0.8) has made it into squeeze. Dpkg wasn't quite ready unfortunately."


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

We already know they're planning an overhaul of certain parts of the client, with various leaks and Valve eventually talking about it.

Is there any chance part of this overhaul will include making Steam behave in a more standard way with regard to package management? Meaning allowing package managers to handle updating Steam instead of Steam updating itself?
But either way, a 64bit client will be very cool.

Oh thank fuck. Maybe I can finally disable 32 bit compatibility on my system. It all depends on how many 32 bit games I actually want to play so I guess I should start looking at that.

Some games that say they are 64 bit, still use some 32 bit components.

An example would be GRIP
https://www.cagedelement.com/grip/

A relevant part of wine wiki:
https://wiki.winehq.org/Building_Wine#Shared_WoW64


Last edited by solar_dome on 12 August 2018 at 3:06 am UTC

Some games that say they are 64 bit, still use some 32 bit components.

An example would be GRIP
https://www.cagedelement.com/grip/

A relevant part of wine wiki:
https://wiki.winehq.org/Building_Wine#Shared_WoW64

But that's a strictly Windows problem so what does that have to do with the Linux version of steam?

But that's a strictly Windows problem so what does that have to do with the Linux version of steam?

Just a Windows problem? That is good to know.
In that case, it just concerns linux+steam+wine users.