Announcement
Collapse
No announcement yet.
Valve Rolls Out A New Steam Storefront
Collapse
X
-
Originally posted by TheSoulz View PostFun 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).
- 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)
Comment
-
Originally posted by mwpow3ll View Post32-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)
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.
Comment
-
Originally posted by mwpow3ll View Post32-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)
Comment
-
Originally posted by TheSoulz View Postsure 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.
Originally posted by schmidtbag View PostIt'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.
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.
Comment
-
Originally posted by schmidtbag View PostIt'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.
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.
Comment
-
Originally posted by dragorth View PostThis 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.
Comment
-
Originally posted by computerquip View PostI still cant believe we have 32 bit software. Processors have been commonly 64 bit capable since before 2000.
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.Last edited by Luke_Wolf; 23 September 2014, 05:10 PM.
Comment
-
Originally posted by dragorth View PostThe 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.
However, real games actually are bumping up against that 4GB virtual memory limit, and have been doing so for quite some time.
Comment
Comment