3GB memory 32 or 64 bit??

[eternalone]

I have 3Gb's of memory each module is a Gig so thats 3 modules in total. Should I go 32 bit or 64 bit windows 7?? Might buy another 2Gigs this black friday, not sure. Also will the combination of 3Gigs single modules and a 2gb module be compatible. In another words will it show up as 5gb.?? I might just stay with 3GB seems like more than enough but I would just like some opinions.

 

[Bill Brasky]

If you plan on upgrading past 3Gb, you will need a 64 bit OS to utilize the additional RAM. Are there programs your using currently that require more memory? Photohop for example?

 

[eternalone]

If you plan on upgrading past 3Gb, you will need a 64 bit OS to utilize the additional RAM. Are there programs your using currently that require more memory? Photohop for example?

Gaming and light photoshopp. But Im wondering if there will be an advantage in games 64 bit over 32 bit, with my 3Gb, single modules.

 

[strep3241]

Not to sure about gaming advantages but IMO, I would go ahead and buy 64 bit Windows. That way in the future you can add more ram.

 

[SickBeast]

64 bit apps tend to be marginally faster than 32 bit apps. That said, 32 bit Windows has a smaller memory footprint, so you will be able to use your 3gb more effectively with it. I personally have switched to 64 bit as I find things a little bit more responsive.

 

[VirtualLarry]

I would go 64-bit with 2GB or more of RAM.

 

[wpcoe]

Before making a decision, make sure all your apps run on, and your devices have drivers for, 64-bit Windows. Some legacy apps/devices never got "updated" for 64-bit.

 

[sub.mesa]

No real reason to prefer 32-bit unless your older hardware has no 64-bit drivers. Always go 64-bit if you have the choice.

The memory usage would be more efficient under 64-bit, since 2GiB is the usual limit for 32-bit application or kernel memory. Using 32-bit apps under 64-bit OS works great, since then your apps can never suck too much RAM (2GiB limit per app/game) and you can keep more RAM as filecache, which has very nice performance benefits.

 

[taltamir]

64bit lets your apps fully utilize your CPU.
All 32bit apps will work fine on 64bit windows with the exception of driver based apps which require you to run a 64bit version of said app (which is nowadays available for ALL of them)

64bit is faster, your CPU has extra registers and capabilities that can give up to 400-500% speedup.
Example speedups:
x264 encoding - none whatsoever
divx encoding - 60%
7z compression - 23%
hash calculation - 300 to 400% depending on the hash type.

 

[dinkumthinkum]

If you plan on upgrading past 3Gb, you will need a 64 bit OS to utilize the additional RAM. Are there programs your using currently that require more memory? Photohop for example?

Not quite right, a PAE-enabled 32-bit OS can address 36-bits of physical memory. However, pointers are 32-bits, to virtual address space. This limits you to a per-process 4GB space. The customary technique of kernel implementors is to use the upper 1GB to map the kernel into every virtual address space, hence, 3GB of address space for the user's program. However, this 3GB of virtual address space can be mapped anywhere within the 36-bits of physical address space.

In other words, you can plug more than 4GB of RAM into your system and your 32-bit Windows can make use of it, but no single program can use more than 3GB of address space for itself. But if you run more than one program at at time, then you can take advantage of the additional physical memory.

 

[Voo]

Not quite right, a PAE-enabled 32-bit OS can address 36-bits of physical memory. However, pointers are 32-bits, to virtual address space. This limits you to a per-process 4GB space. The customary technique of kernel implementors is to use the upper 1GB to map the kernel into every virtual address space, hence, 3GB of address space for the user's program. However, this 3GB of virtual address space can be mapped anywhere within the 36-bits of physical address space.

Correct, but windows 32bit per default maps 2gb to the kernel not 1 (though there's a flag to change that).
But since customers rarely use more than one app at the same time (which means the rest can be swapped) PAE isn't that useful imho, especially considering the bugs in lots of drivers.

And windows client OSes don't have PAE enabled per default, so that envolves a bit of Kernel hacking. So in the end you need two "hacks" to get that running, which can be a bit of trouble (had some problems with drivers and some programs a few years ago on XP with it)


Go with the 64bit OS, the larger memory footprint is negligible and if you ever want to upgrade the RAM it'll be much easier that way. And x64 has some performance advantages over x86 code, though I haven't seen benchmarks that get such large performance deltas than taltamir (and didn't really notice the difference between xp 32 and win7 64).

@talta: Got a link to the benchmarks? Would be interesting.

 

[taltamir]

sorry, but no... 64bit has been around since April 2003 and it has been years since I last saw someone benchmark the difference. And most of those figures are from separate benchmarks. The 7z figure I actually benchmarked myself so there is no link, I am the primary source for that one

 

[Nothinman]

Not quite right, a PAE-enabled 32-bit OS can address 36-bits of physical memory. However, pointers are 32-bits, to virtual address space. This limits you to a per-process 4GB space. The customary technique of kernel implementors is to use the upper 1GB to map the kernel into every virtual address space, hence, 3GB of address space for the user's program. However, this 3GB of virtual address space can be mapped anywhere within the 36-bits of physical address space.

In other words, you can plug more than 4GB of RAM into your system and your 32-bit Windows can make use of it, but no single program can use more than 3GB of address space for itself. But if you run more than one program at at time, then you can take advantage of the additional physical memory.

As Voo says, NT defaults to a 2/2G split, not 1/3G although this can be changed. But that's not recommended as it puts strain on the kernel's address space and very few, if any, drivers are tested in that config.

And on top of that, 32-bit Windows client OSes have a hard 4G limit with regards to physical memory. You can plug as much as you want into the system and the OS will see it, but it won't touch a physical address above the 4G mark. You need Windows Server Enterprise or a 64-bit build in order to get PAE to do anything other than NX.

And windows client OSes don't have PAE enabled per default, so that envolves a bit of Kernel hacking. So in the end you need two "hacks" to get that running, which can be a bit of trouble (had some problems with drivers and some programs a few years ago on XP with it)

Actually they do as of XP SP2, however only for NX so they'll still happily ignore any physical address above the 4G mark.

 

[sub.mesa]

Since 32-bit apps need to be specially compiled to use more than 2GiB memory (3GiB on 32-bit and 4GiB on 64-bit), it's easier to just remember 32-bit is limited to 2GiB, than to explain all the exceptions which never occur in real life.

Any game or app you download that is 32-bit, is limited to 2GiB memory, that's more easy to remember than all the /LARGEADDRESSAWARE /3G compile flags allowing a little more memory to be addressed by applications compiled as such. I've not seen this used for ordinary applications, though.

Where 64-bit had driver problems awhile back, right now it should be good since it guarantees your drivers are rather new and tested properly; Microsoft requires signed drivers for the 64-bit Windows versions. This should make computers more stable; in the 32-bit age some Chinese kid made a driver that crashes windows every 20 minutes; and the company ships that. Not that great, so buying a 64-bit Windows distribution now should solve that issue.

 

[Nothinman]

Since 32-bit apps need to be specially compiled to use more than 2GiB memory (3GiB on 32-bit and 4GiB on 64-bit), it's easier to just remember 32-bit is limited to 2GiB, than to explain all the exceptions which never occur in real life.

Any game or app you download that is 32-bit, is limited to 2GiB memory, that's more easy to remember than all the /LARGEADDRESSAWARE /3G compile flags allowing a little more memory to be addressed by applications compiled as such. I've not seen this used for ordinary applications, though.

But you can still set that flag on the resulting binary manually if you want. How the app deals with those larger addresses is undefined, but as long as it doesn't do any really stupid shit it should be fine.

Where 64-bit had driver problems awhile back, right now it should be good since it guarantees your drivers are rather new and tested properly; Microsoft requires signed drivers for the 64-bit Windows versions. This should make computers more stable; in the 32-bit age some Chinese kid made a driver that crashes windows every 20 minutes; and the company ships that. Not that great, so buying a 64-bit Windows distribution now should solve that issue.

It's a nice thought, but the driver quality still seems about the same to me. The same kid is still writing drivers, the only difference is they pass through MS' driver tests first and IME that doesn't mean much about driver quality.

 

[Emulex]

if you have on board 512meg video and 2 x 1GB video card - 32bit will leave you with 2.5gb of ram - of your 3gb.

with 64bit you will get all 3gb.

Alot of drivers use alot of space (think touchscreen) - so 64bit is only logical - you can't sell someone 4gb of ram - and they only have 2gb usable because of mapped i/o.

 

[Nothinman]

if you have on board 512meg video and 2 x 1GB video card - 32bit will leave you with 2.5gb of ram - of your 3gb.

with 64bit you will get all 3gb.

Alot of drivers use alot of space (think touchscreen) - so 64bit is only logical - you can't sell someone 4gb of ram - and they only have 2gb usable because of mapped i/o.

Except that it's not a 1:1 mapping so you may not actually lose that much space to your video cards.

 

[Voo]

But you can still set that flag on the resulting binary manually if you want. How the app deals with those larger addresses is undefined, but as long as it doesn't do any really stupid shit it should be fine.

And another thing is, that 32bit apps with the flag will get 4 instead of 3gb in x64 Windows, so even for those applications there's an advantage.

And there are "lots" of programs (too many anyhow) that do pointer arithmetic of the form (a+b)/2 or use signed comparison or use the msb to tag stuff (which is still somehow excuseable depending on when the app was developed) and will run into problems *sigh*

PS: And yeah usually drivers usually implement a 256mb window for the GPU RAM and the aperture which is mapped into individual processes [not true for WDDM] (also around 256mb in modern games), so that's independent of the GPUs used..

 

[Nothinman]

And another thing is, that 32bit apps with the flag will get 4 instead of 3gb in x64 Windows, so even for those applications there's an advantage.

And there are "lots" of programs (too many anyhow) that do pointer arithmetic of the form (a+b)/2 or use signed comparison or use the msb to tag stuff (which is still somehow excuseable depending on when the app was developed) and will run into problems *sigh*

PS: And yeah usually drivers usually implement a 256mb window for the GPU RAM and the aperture which is mapped into individual processes (also around 256mb in modern games), so that's independent of the GPUs used..

Then those apps deserve to crash. Compatibility can't last forever, otherwise you end up with a giant spaghetti monster like Windows.

 

[dinkumthinkum]

Thanks for the clarifications. I was just addressing Zaitsev statement about 32-bit OSes in general. I should have mentioned that I have been using 64-bit OSes (Windows and Linux) for many years now, and there is simply no reason for a consumer not to get one.

I do my hacking in a 32-bit research OS but that is for legacy and other reasons.

 

[Voo]

Then those apps deserve to crash. Compatibility can't last forever, otherwise you end up with a giant spaghetti monster like Windows.

Yeah I may not be able to use those apps, but hey at least the other code is much prettier because of it.. which brings me - as a user - absolutely nothing.

Nope as a user I prefer backwards compatibility over "pretty code" every day of the year, but I really don't pity those poor MS ingenieurs that have to manage the code responsible for it.

 

[Nothinman]

Yeah I may not be able to use those apps, but hey at least the other code is much prettier because of it.. which brings me - as a user - absolutely nothing.

Nope as a user I prefer backwards compatibility over "pretty code" every day of the year, but I really don't pity those poor MS ingenieurs that have to manage the code responsible for it.

Those apps will also not be able to be ported to 64-bit so they'll die off eventually anyway. Do you actually have an example of an app that catastrophically breaks if you manually set the LargeAddressAware bit on it's binary?

 

[tweakboy]

Never limit yourself with RAM. This is a good lesson. Go 64 so you can upgrade in the future.