Steam Survey Updated For February 2020 With Latest Linux Figures

[Naquatis]

I prefer Linux for my day to day work but Steam never were able to created a Linux gaming environment I like to use. This whole survey only shows that people who using Linux playing on Windows because Steam for Linux isn't good enough. And thats not because some titles not existent. You only need Dota 2 on Linux and Dota 2 for Windows .. my winrate raises while using Windows even the Linux hardware is the latest 7nm system you can buy.

[duby229]

The issue isn't games being 32/64 bit, the issue is the steam launcher (a completely separate entity) being 32bit.

It doesn't matter if Intel cpus are slightly worse at handling 64bit integers compared to AMD's from ryzen onwards. We're not asking steam to calculate prime numbers lol Should we never run a 64bit program on intel cpus ever again incase it hurts performance?

All steam itself has to do is launch games, but it's nice that it also: showcases game news; has a storefront to purchase new ones; has social stuff to keep in touch with friends and play together and the community at large can have discussions.


There is 0 good reason why in 2020 Valve can't do exactly what they've done for macOS and RELEASE A NATIVE 64BIT STEAM CLIENT.

There are a few problems with your reasoning. The first and biggest problem is memory consumption, if an app uses less than say 3gigs of RAM then it doesn't -need- to be 64bits. 64bits is physically larger than 32bits and it will thrash cache harder. If memory consumption isn't a problem for you then 32bits is almost definitely the best option.

The -only- reason valve built a 64bit mac client was because Apple dropped support for 32bit binaries. It was -entirely- an artificial limitation placed on app devs for literally no good reason at all. In fact it was a terrible idea. All these linux distro's talking about dropping 32bit support are just as equally terrible and dumb... Why exactly would something like a shell tool (ls, cat, echo, etc) need to be 64bit? Or a graphical interface like a text editor? Very very little of a linux distro would benefit from being compiled 64bits and in fact almost all of a linux distro would hurt from being built 64bits.

EDIT: https://en.wikipedia.org/wiki/X86-64#Operating_modes

See amd64/x86-64 has two Long Modes of operation it can use to run 64bit code, The first is 64bit Mode and in that mode it can -only- run 64bit code. It's the mode that Windows uses to run and is the entire point and purpose in WoW64 emulation. Linux on the other hand uses Compatibility Mode, which allows 32bit and 16bit code to operate as well, no emulator required.



The point is, use a bit depth that adequately provides the amount of memory your application needs, but not more so otherwise building an app with 64bit pointers is just worsening cache pressure for no good reason on linux.

[oiaohm]

You might want to look at posts in this thread for possible reasons why games are still 32bit ...
https://www.phoronix.com/forums/foru...13#post1159013

This test you did is like what you see game developer did with spinlocks to make a point while missing the complete issue while being basically wrong. Div is done way less than a function call on average function call is a big change in x86. Something to remember you can do 32 bit div in 64 bit mode.

I am not saying developer should forgot about the differences between 32 bit and 64 bit there is performance to be got that way but building your program complete 32 bit hurts you. Really the next person has missed the same problem there are a set of major changes when you build for 64 bit that make major performance differences in 64 bit mode favour.

There are a few problems with your reasoning. The first and biggest problem is memory consumption, if an app uses less than say 3gigs of RAM then it doesn't -need- to be 64bits. 64bits is physically larger than 32bits and it will thrash cache harder. If memory consumption isn't a problem for you then 32bits is almost definitely the best option.

Sorry this sounds like answer but its missed something so critical so is in fact wrong.

https://en.wikipedia.org/wiki/X32_ABI

The calling convention changes when you move from 32 bit x86 userspace to 64 bit x86 userspace. Most applications are doing a lot of calls. The old calling 32 bit convention has you pushing and poping stuff on and off the stack that beats the living heck out the cache. 64 bit calling convention due to 64 bit mode having more registers avoids this way more often.

The point is, use a bit depth that adequately provides the amount of memory your application needs, but not more so otherwise building an app with 64bit pointers is just worsening cache pressure for no good reason on linux.

There is another problem here. 64bit pointers when performing syscalls to the Linux kernel syscall from 64 bit to 64 bit requires less kernel space processing that 32 bit to 64 bit be it 32 bit x86 native or x32 in 64bit mode calls. This extra code that has to be processed for the translation also worsens your cache utilisation. This here is why in particular benchmarks 64 bit x86 under linux can been 20 to 40 percent faster to x32.

If this is a issue under Linux you should be using x32 abi that is a 64 bit mode. Reality is making a 32 bit x86 application give horrible cache pressure due to the way the calling convention works. This even applies to windows and macos.

Please note I am not saying that you should not optimise you program to use 32 bit stuff in 64 bit mode because this does give a performance uplift. Stupid as it sounds the saving in cache pressure by call convention change going to 64 bit mode fairly much offsets all the 64bit mode performance cost.

https://stackoverflow.com/questions/51134045/integer-performance-30-50-times-difference-of-x32-vs-x64-jvm

Before either get the idea of arguing this calling convention hurt is not huge people working around java see it a lot. 2 to 5 times slower using a 32 bit x86 application. The calling convention issue makes most other problems look minor.

duby229 if your idea is correct for an application x32 in 64bit mode on Linux will be 40% faster than normal 64 bit mode. But there is a problem the old 32bit mode due to calling convention pain will be about half the speed or slower of the 64 bit mode program. So if you are talking performance under Linux is a arguement between x32 in 64bit mode and 64 mode not the old school 32 bit binaries.

In fact it possible to claw back by program optimisation 80-95 percent the advantage x32 in 64 bit mode has over 64 bit mode by code refactoring and of course this still keeps all the cases where 64 bit code simply out performs 32 bit code and is still way ahead of the old school 32 bit x86 binary before you started optimising it these days. Most of what Linux x32 abi(32 bit in 64 bit mode) does could be done the compiler to avoid people having to completely recode their programs specialist syscalls do help in places.

Only valid arguement for 32 bit mode x86 really has been compatibility. Performance arguement is basically bogus reality 32 bit x86 usermode does not perform. The fact 32 bit x86 usermode does not perform totally explains apple dropping it as better performing code equals less power usage by cpu so longer battery life performing the same tasks at the same speed.

See amd64/x86-64 has two Long Modes of operation it can use to run 64bit code, The first is 64bit Mode and in that mode it can -only- run 64bit code. It's the mode that Windows uses to run and is the entire point and purpose in WoW64 emulation. Linux on the other hand uses Compatibility Mode, which allows 32bit and 16bit code to operate as well, no emulator required.

This is wrong. Core Linux kernel runs in 64bit mode the same as windows. 32 bit Linux application or 32 bit windows application on 64 bit versions of Linux or Windows both run in amd64 Compatibility mode on 64 bit x86 platforms. WoW64 is not using cpu emulation on 64 bit x86 platforms to run win32 bit applications.

Reason why Linux has 16bit code support.

https://lkml.org/lkml/2014/4/29/626

Mostly that wine users/developers got really upset and Linus said to the Intel developer you cannot break userspace fix it or risk being banned from submitting code until you do fix it. Yes it was not until 2014 was a fix to the 16bit espfix issue was coded and Linux was first to get this. Microsoft with Windows 64 bit versions took the simple path drop the 16 bit stuff and only implement the 32 bit version of espfix.

OS X dropping 32 bit support allows them to also drop work around like espfix from their kernel space.

CPU instruction set bugs are nothing new. So every time a 32 bit program syscalls under 64 bit windows/Linux/BSD/OS X on x86 they have been in fact running extra code and taking a performance hit to cover up for this bug. espfix corrected issue is really old one.

There are multi places where running a 32bit program on a 64 bit x86 platforms where you performance is getting kicked in like your privates then being asked to walk in a straight line of course you cannot do that at speed and neither can a 32 bit x86 program and this is just the way it is.

[bridgman]

I just noticed that the stats page now lets you view things like CPU and GPU details by OS - Windows, Linux or Combined. Is this new, or has it always been there ?

[Raka555]

I just noticed that the stats page now lets you view things like CPU and GPU details by OS - Windows, Linux or Combined. Is this new, or has it always been there ?

It has been there for a long time.

[Raka555]

The issue isn't games being 32/64 bit, the issue is the steam launcher (a completely separate entity) being 32bit.

It doesn't matter if Intel cpus are slightly worse at handling 64bit integers compared to AMD's from ryzen onwards. We're not asking steam to calculate prime numbers lol Should we never run a 64bit program on intel cpus ever again incase it hurts performance?

All steam itself has to do is launch games, but it's nice that it also: showcases game news; has a storefront to purchase new ones; has social stuff to keep in touch with friends and play together and the community at large can have discussions.


There is 0 good reason why in 2020 Valve can't do exactly what they've done for macOS and RELEASE A NATIVE 64BIT STEAM CLIENT.

The thing is as long as the games are 32bit, it makes sense for the game client to be 32bit as well so it can pull in all the dependencies the games need.

[discordian]

The thing is as long as the games are 32bit, it makes sense for the game client to be 32bit as well so it can pull in all the dependencies the games need.

Yea sure, that's why its not possible to launch 64bit games with 32bit steam, and you can only launch python games with lutris. LOL

[oiaohm]

The thing is as long as the games are 32bit, it makes sense for the game client to be 32bit as well so it can pull in all the dependencies the games need.

https://support.steampowered.com/kb_article.php?ref=1055-ISJM-8568

Valve is releasing a 64 bit version of Steam of Mac OS because there are some 64 bit games in there software collection. Same applies to Linux. Question if all the steam games I own happen to be 64 bit versions why should I be forced to install 32 bit run-time??

The reality is games needing high performance are going to be 64 bit something because 32bit performance is horrible.

Also long term game being 32 bit does not mean the platform to run it has to be. Hangover work with wine some of that work is to allow 32 bit client application to use 64 bit host library by form of thunking. So games being 32 bit and host being 64 bit does not have to be as black and white. Of course making this would would be taking the libcapsule stuff valve using around system opengl to the next level. Instead of 32 bit to 32 bit or 64 to 64 as current libcapsule stuff does 32bit to 64 bit. In theory it possible to have a host with no 32 bit runtime yet still run 32 bit applications by providing own runtime and thunking to the 64 bit host libraries.

[Hadrian]

You don't need to fill this survey, just click a button and they take your system configuration.

Where is this button, please?
I didn't find it so far, so I never contributed to Valve's Linux statistics.

And where is the total number of PCs for this statistic? I.e. 0,80% of how many PCs ?

[duby229]

It's actually quite astounding reading the gymnastics to avoid making a what is essentially a game launcher installable without dozens of unnecessary i386 libraries.
Someone is going to have call NASA, MENSA, nay the brightest minds on the planet to solve this within the decade because steam cannot ever be 64 bit or else it would need 5GHz 128 core processors (not intel of course, they couldn't take it) and 128GB of RAM on 1.2MW generators powering it to be able to handle the raw processing power to have it function properly.

Valve won't update their client to run on e.g. x86_64 without i386 libraries because the alternative would "thrash the cache"? "Worsen cache pressure for no good reason"?
It wasn't long ago that Mozilla wouldn't do a 64bit version of firefox for Windows lol remember when they released it (an actually resource intensive web browser, not a game launcher) and millions of computers exploded?

1. RAM is a bit of strawman here. It needs to be 64bit because any other program can manage it and then not require a myriad of old library file dependencies to install it on a modern OS.
2. It's a game launcher. Do macOS users report it thrashing their memory cache? Do 64bit versions of most programs thrash compared to their 32bit counterparts? Do we die just that little bit faster because of it? Do you consider the steam client computationally intensive flinging GBs of data in and out of RAM that would become unruly all of a sudden with marginally bigger memory needs?
3. Forget RAM requirements. We both know the steam client only needs a couple 100s of MBs with all the bootstrapper + overlay + additionals but saying "it would use more RAM as a 64 bit program, therefore we can't do it" is insane.
4. I'm not for a minute advocating a 64bit version for performance reasons. As long as it isn't worse, it's a win. I don't think better performance in some way would be unexpected based on past programs feeling 'snappier' (placebo or not) in the past, and this is probably a (big) deciding factor in the similar push across OSes and software.

I'm not an Apple fan, but deprecating 32bit in favour of 64 isn't inherently a bad idea and it forced Valve's hand. Of course it's precisely because of transitions like this that we're in a limbo where this problem exists and steam needs all this extra cruft to install.
We're obviously not going backwards to 32bit only OSes, so the program has to keep up. Windows and Linux should get 64 bit steam clients.
Geez, it feels like explaining why https is a good thing even though it uses more resources than http to implement. ALL upgrades, all change as far as technology is concerned is an ARTIFICIAL limitation on deprecating the previous architecture or version to accommodate a new way of doing something.


I have dreams at night of 64 bit programs! I know they're real! I know it!

Someone adjust my straightjacket tighter please. Watch this space! Steam client 32 and 64bit releases coming 2025!!

Wow, you are so badly misinformed it's literally stupid. You have no clue what cache does do you?

EDIT: Hint, it's about word size...
https://en.wikipedia.org/wiki/Word_(..._architecture)

And here is just one of hundreds of examples proving it.
https://www.osnews.com/story/5768/ar...-bit-binaries/