Steam Survey Updated For February 2020 With Latest Linux Figures

[oiaohm]

off all the things to argue about, arguing about steam itself being 32 bit or 64 bit is just dumb. it's a bloody launcher.

Really is only a launcher it does not have to be code in 32 bit. Particular when you look at the steam survey of Linux and you don't see anyone using pure 32 bit Linux any more.

There are more games now in steam that are 64 bit.

So exactly why am I loading a 32 bit steam launcher to have 32 bit glibc in memory when the next thing I am going to run its a 64 bit game? The copy on write nature of Linux memory management the 32 bit steam launcher does not help a 64 bit game to launch.

Yes if you are pushing limits on memory crossing 32 bit and 64 bit is not good.

I like how you say its just a bloody launcher this is so you don't have to look and go darn that wrong. Steam should have a 32 bit and 64 bit launcher. Yes 32 bit games use 32 bit launcher and a 64 bit launcher 64 bit games. Dosbox and other things comes in 32 and 64 bit versions.

[oiaohm]

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

No sorry that is 1 of the hundreds of examples that prove a compiler bug.

https://www.phoronix.com/scan.php?page=article&item=ubuntu-1710-x8664&num=3

When you get to 2015 and new after compiler has been fixed 32 bit mode loss all the time.


What was the fix in the compiler for building 64 bit binaries that would render this idea basically crap. That right the compilers go smart enough that the would in fact use 32 bit operations in 64 bit binaries. Instead of building everything in the 64 bit binary using 64 bit operations. This closed the gap between x32-api mode pure 64 bit mode by lot but also make 64 bit mode kick the living crap out of 32 bit in performance over and over again. Yes the 64 bit only usage bug in compilers effected all 64 bit archs. Every 64 bit arch instruction set has multi word size instruction and if the compiler is not taking advantage of it you are screwed performance wise.

Basically look the modern benchmarks and what was fixed in gcc and clang to allow proper optimisation of 64 bit binaries. Only reasons today why a 64 bit binary loss in a performance competition against 32 bit binary is :
1) bad human manual optimisation.
2) using a almost 10 year old compiler.

Any other case the 64 bit binary will be faster than the 32 bit one. The x32-api that restricts memory space to 4g to reduce pointer sizes turns out not to gain performance in a lot cases because the handling of the 4G address space turns out to be costly.

EDIT: Hint, it's about word size...

This is in fact a strawmans arguement. AMD or Intel x86-64 running in 32 bit or 64 bit mode use exactly the same word sizes between caches. It part true because this was the issue when you had compilers being dumb enough to use a 64 bit add operation to add 1 to a 8 bit char data type. Yes early 2000 64 bit compilers were total idiots in assembler instruction selection.

Basically 32 being faster than 64 bit is a myth. Its a myth based in a little bit of facts people miss understood from the early benchmarks that were really showing a major 64 bit compiler defect.

There is so much wrong with what you said I doesn't make any sense to try and correct you. You wouldn't listen any damn way. Yes WoW64 -DOES- transform 32bit api calls into 64bit system calls. YES IT DOES!! Windows does -NOT- use compatibility mode -AT ALL- and THAT is the -ONLY- reason why WoW64 -needs- to exist. EVERYTHING else you said was complete nonsense.

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

Wow64win.dll's functions on the x86-64 architecture, which switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode.

You did not read what you referenced. Because it clearly states what I said. Wow64 bit on x86-64 what is a current x86 64 bit uses the amd64 compatibility mode. Compatibility modes is you 32 bit and 16 bit protected memory modes in long mode of AMD64. You cannot boot a OS in either of the Compatibility modes.

Really this in Wow64 is a counter arguement to the idea 32 bit binaries perform.

Why did Microsoft go out their way to run as much as possible with Wow64 in 64 bit mode if 32 bit mode performed? See it does not make any sense if 32 bit performed todo this.

Windows usage of LLP64 data mode this make it a lot simpler to go from 32 bit binary to 64 bit code. Linux uses LP64 yes this difference can hurt people porting code as well.\

Sorry try to correct me on what I said I will just point to reference over reference of post. Its 100 percent correct and you are being 100 percent incorrect because you are using old information or incorrect information. The old information people guessed the wrong thing as the cause of problem.

[duby229]

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.



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.



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




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.

Another completely asinine wall of nonsense from you.

There is so much wrong with what you said I doesn't make any sense to try and correct you. You wouldn't listen any damn way. Yes WoW64 -DOES- transform 32bit api calls into 64bit system calls. YES IT DOES!! Windows does -NOT- use compatibility mode -AT ALL- and THAT is the -ONLY- reason why WoW64 -needs- to exist. EVERYTHING else you said was complete nonsense.

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

[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/

[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 ?

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

[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

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

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

[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 ?