Valve Rolls Out A New Steam Storefront

[DarkFoss]

Fun fact: on Windows, unlike Firefox and Chromium/Chrome, the most recent Internet Explorer versions are available in 64 bits.

Chrome on Windows :Version 37.0.2062.120 m (64-bit) btw works surprisingly well.
.deb's available for Debian/Ubuntu and rpm's available for Fedora/openSuse too.

[edoantonioco]

This reminds me than I have been wanting to try Kaosx (an 64 bits only distro), but the steam DRM using 32 bits library is what keeps me away from trying.

[mwpow3ll]

Fun fact: Chrome runs in 64bit on windows and soon mac and have ran in 64 in linux for awhile.

I agree 32 bit software needs to die, we should do like macs, remove every 32 bit app and force 64 bit.
Even on steam status it shows moust of the people use 64 OS's why in hell are we still using 32bit?
Its not fun having to install/load both 32bit and 64bit libs to make stuff work, makes the pc slower and uses more ram.

take skype for example, if you want it to use the icon tray and use the system themes your forced to MANUALY install the 32bit libs (facepalm).

32-bit software isn't going anywhere anytime soon.

• Although processors have been capable of 64-bit support for some time, they do not support the theoretical max of 16 exbibytes. At this time 4.256 Pebibytes is the max.
• The current physical size of RAM chips make it impossible to exceed 4 petabytes.
• Even if processors and RAM could support the theoretical max, it's far more lucrative to milk each step-up rather to blast ahead
• Consumers can't buy motherboards that support more than 64GB of RAM; therefore, developers of consumer software can't exceed 64GB of addressible space (max limit of 32-bit w/ PAE)
• Supporting 64-bit is not a one-size fits all solition because even though it allows greater addressible space, greater accuracy, and processing larger chunks, it increases the necessary overhead (pointers are longer and more alignment padding is necessary) which consumes more memory.
• The niche of software that would show 'real' benefits of exceeding 32-bit support w/ PAE is not really a consumer market (encoders / decoders, etc)

[TheSoulz]

32-bit software isn't going anywhere anytime soon.

• Although processors have been capable of 64-bit support for some time, they do not support the theoretical max of 16 exbibytes. At this time 4.256 Pebibytes is the max.
• The current physical size of RAM chips make it impossible to exceed 4 petabytes.
• Even if processors and RAM could support the theoretical max, it's far more lucrative to milk each step-up rather to blast ahead
• Consumers can't buy motherboards that support more than 64GB of RAM; therefore, developers of consumer software can't exceed 64GB of addressible space (max limit of 32-bit w/ PAE)
• Supporting 64-bit is not a one-size fits all solition because even though it allows greater addressible space, greater accuracy, and processing larger chunks, it increases the necessary overhead (pointers are longer and more alignment padding is necessary) which consumes more memory.
• The niche of software that would show 'real' benefits of exceeding 32-bit support w/ PAE is not really a consumer market (encoders / decoders, etc)

sure thats all good and such but now tell me what is the advantace of running 86-64?
all your doing is increasing overhead and using more memory on both disk and ram.
like i said the app might not need the 64bit "improvements" but removing 86-64 and doing only 64 has the advantage of less dependencies and overhead.

why complicate things?
having to build 64bit apps and 32bit only makes it harder and gives more work, choose one and stick with it.

[schmidtbag]

32-bit software isn't going anywhere anytime soon.

• Although processors have been capable of 64-bit support for some time, they do not support the theoretical max of 16 exbibytes. At this time 4.256 Pebibytes is the max.
• The current physical size of RAM chips make it impossible to exceed 4 petabytes.
• Even if processors and RAM could support the theoretical max, it's far more lucrative to milk each step-up rather to blast ahead
• Consumers can't buy motherboards that support more than 64GB of RAM; therefore, developers of consumer software can't exceed 64GB of addressible space (max limit of 32-bit w/ PAE)
• Supporting 64-bit is not a one-size fits all solition because even though it allows greater addressible space, greater accuracy, and processing larger chunks, it increases the necessary overhead (pointers are longer and more alignment padding is necessary) which consumes more memory.
• The niche of software that would show 'real' benefits of exceeding 32-bit support w/ PAE is not really a consumer market (encoders / decoders, etc)

It's not that you're wrong, but your point is somewhat irrelevant. 64 bit processors also mean programmers can use much larger numbers and in many cases has a noticeable performance improvement. I may be wrong about this, but I think it also improves the performance associated with memory bandwidth. Of course as with all architectural changes there are some performance regressions, though those are pretty minimal and rare. 64 bit computing has very little to do with maximum memory capacity and more to do with the functionality of software. PAE is simply a workaround, and in OSes where it actually matters (namely Windows), it isn't very effective. I've run PAE with Windows 7 before and encountered issues.

[mwpow3ll]

sure thats all good and such but now tell me what is the advantace of running 86-64?
all your doing is increasing overhead and using more memory on both disk and ram.
like i said the app might not need the 64bit "improvements" but removing 86-64 and doing only 64 has the advantage of less dependencies and overhead.

why complicate things?
having to build 64bit apps and 32bit only makes it harder and gives more work, choose one and stick with it.

I told you the advantages in my post before. Larger addressible space, greater accuracy, and in general larger chunks to process, but those advantages come at the price of overhead. It's widely accepted that the same amount of data stored in RAM on 64-bit architecture compared to 32-bit requires more space.

It's not that you're wrong, but your point is somewhat irrelevant. 64 bit processors also mean programmers can use much larger numbers and in many cases has a noticeable performance improvement. I may be wrong about this, but I think it also improves the performance associated with memory bandwidth. Of course as with all architectural changes there are some performance regressions, though those are pretty minimal and rare. 64 bit computing has very little to do with maximum memory capacity and more to do with the functionality of software. PAE is simply a workaround, and in OSes where it actually matters (namely Windows), it isn't very effective. I've run PAE with Windows 7 before and encountered issues.

No. if this were true it would be a no-brainer, but because of the overhead I mentioned previously, some applications under 64-bit support see no benefit.

Bottom line, 64-bit vs 32-bit is not a 'one-size fits all' option and thus why it hasn't taken over by storm.
The transition from 16-bit to 32-bit was much faster because the consumer base was a lot smaller and companies didn't have to worry about disrupting your grandmother trying to surf the web.

[dragorth]

It's not that you're wrong, but your point is somewhat irrelevant. 64 bit processors also mean programmers can use much larger numbers and in many cases has a noticeable performance improvement. I may be wrong about this, but I think it also improves the performance associated with memory bandwidth. Of course as with all architectural changes there are some performance regressions, though those are pretty minimal and rare. 64 bit computing has very little to do with maximum memory capacity and more to do with the functionality of software. PAE is simply a workaround, and in OSes where it actually matters (namely Windows), it isn't very effective. I've run PAE with Windows 7 before and encountered issues.

This is very true. Also, on 64bit processors, the processors themselves have four times the number of registers that can be used and addressed by a 64bit application, allowing for a more parallel operations at once, and newer algorithms that speed up certain operations.

Newer instructions such as AVX require 64bit instructions as well, meaning you will get the best performance with optimized code there. This is why most 3D software is now 64bit.

The programs that would benefit most for consumers are games. How so? Simple. First, addressable memory. A 32bit game is limited to essentially 2Gb of memory, even if said gamer has 32GB of ram. 3D graphics heavy titles have bandwidth constraints to the GPU. The GPU has to be filled with texture data as fast as possible to maintain 60hz+ refresh rates, but most GPU these days come with 2GB of ram, and Nvidia's latest both start with 4GB. If the game is constantly trying to fill a 4GB GPU from a 2GB buffer, it has to fill that at twice the speed that it can write to the GPU. Which it can't do, thanks to its source being the gamer's SSD or, more likely, HD. Whit a 64bit game on a system that has 32GB of ram, the game could copy most of itself to ram, and not have to strain so hard to fill the GPU buffer.

Currently, there are a large number of hacks that have made it into OpenGL and DirectX that try to minimize the amount of bandwidth to solve this speed disparity issue, and while useful, we can eliminate some of the need for them, and their code paths, by moving to 64bit.

Obviously, moving everything to ram will simply highlight the bandwidth limitations of the GPU interface. But it would mitigate a much slower bottleneck we are currently stuck with.

And, since Kronos is in the process of creating OpenGL NEXT, maybe we should make it being 64bit only a requirement, and make OpenGL ES NEXT the mobile/32bit option for businesses that need 32bit, an increasingly embedded only option.

[mwpow3ll]

This is very true. Also, on 64bit processors, the processors themselves have four times the number of registers that can be used and addressed by a 64bit application, allowing for a more parallel operations at once, and newer algorithms that speed up certain operations.

Newer instructions such as AVX require 64bit instructions as well, meaning you will get the best performance with optimized code there. This is why most 3D software is now 64bit.

The programs that would benefit most for consumers are games. How so? Simple. First, addressable memory. A 32bit game is limited to essentially 2Gb of memory, even if said gamer has 32GB of ram. 3D graphics heavy titles have bandwidth constraints to the GPU. The GPU has to be filled with texture data as fast as possible to maintain 60hz+ refresh rates, but most GPU these days come with 2GB of ram, and Nvidia's latest both start with 4GB. If the game is constantly trying to fill a 4GB GPU from a 2GB buffer, it has to fill that at twice the speed that it can write to the GPU. Which it can't do, thanks to its source being the gamer's SSD or, more likely, HD. Whit a 64bit game on a system that has 32GB of ram, the game could copy most of itself to ram, and not have to strain so hard to fill the GPU buffer.

Currently, there are a large number of hacks that have made it into OpenGL and DirectX that try to minimize the amount of bandwidth to solve this speed disparity issue, and while useful, we can eliminate some of the need for them, and their code paths, by moving to 64bit.

Obviously, moving everything to ram will simply highlight the bandwidth limitations of the GPU interface. But it would mitigate a much slower bottleneck we are currently stuck with.

And, since Kronos is in the process of creating OpenGL NEXT, maybe we should make it being 64bit only a requirement, and make OpenGL ES NEXT the mobile/32bit option for businesses that need 32bit, an increasingly embedded only option.

This is really miguided... Video cards currently utilize GDDR 5 which is much faster than DDR 3 that the desktop uses. This trend of video cards using different RAM tech will stay that way and 64-bit will not bridge that gap...

[Luke_Wolf]

I still cant believe we have 32 bit software. Processors have been commonly 64 bit capable since before 2000.

32-bit software on the desktop still exists because of a combination of Microsoft being stupid and having not gone 64-bit only and having supported XP too long, as well as idiot release engineers on everyone else's part.

Basically the real rationale behind it is that users are idiots who don't know what architecture they're running, and so instead of providing a 32-bit and a 64-bit binary and thus getting complaints from people running 32-bit windows trying to run 64-bit binaries, they pretend they're being clever by releasing a 32-bit binary that they know will work everywhere. Microsoft having supported XP so far past it's own best by date, and having continued to release 32-bit versions of windows hasn't helped matters. Additionally you get cascades resulting in the chicken and the egg problem because of the bad behavior of vendors like Mozilla, where they refuse to release an official 64-bit browser on windows which means that Adobe friends refuse to release 64-bit windows plugins because there isn't an official browser to support.

Where this gets particularly ridiculous is games which require processors capable of 64-bit and then release the binaries as 32-bit only, resulting in people being forced to modify the binary to increase the address space in order to fix performance issues that would have been solved by just releasing a 64-bit binary. I'm hoping that will change now that XP support has ended.

Alright but what's that have to do with linux? Well third party vendors are continuing to use the sloppy habits they formed from the windows ecosystem.

To those who say there's not a clear answer to 32-bit vs 64-bit you're wrong. If your application doesn't really have performance requirements release a 32-bit and a 64-bit binary, and default to the native architecture, if your application requires a 64-bit capable processor then release only a 64-bit binary.because I can basically guarantee you'll want the extra address space too.

[smitty3268]

The programs that would benefit most for consumers are games. How so? Simple. First, addressable memory.

I agree completely.

A 32bit game is limited to essentially 2Gb of memory, even if said gamer has 32GB of ram.

Although this isn't actually accurate. If a user is running a 32-bit app on a 64-bit OS, they have access to the full 4GB address space. It's only the 32-bit OS's that have to reserve memory the games can't access.

However, real games actually are bumping up against that 4GB virtual memory limit, and have been doing so for quite some time.