>>>>>If you have a box with 16gb of RAM why wouldn't a 64bit version of VS use more of that RAM and less disk IO? Or are you saying this is an OS issue (the addressing of RAM beyound 3gb) and is not dependant on the program itself having a 64 bit address space?
>>>>>
>>>>>If the latter, then 64bit SQL Server would be different because it is, in fact, a server and therefore is more like (part of) the OS in this regard?
>>>>
>>>>A 64-bit process may make use of more RAM than a 32-bit one. Whether it is designed to do so is another question. To avoid having 2 separate code bases the 64-bit version may just be a straight recompile of the 32-bit one.
>>>>
>>>>If you have a box with 16GB RAM and you have a few GB free, Windows will use that for a disk cache. That cache may be large enough for most or all VS components that are used but not permanently memory resident.
>>>
>>>OK, just to understand - if I have a 32 bit OS anything over 3gb is wasted , correct?
>>
>>Yes. Could actually be up to ~3.5GB depending on your graphics card.
>
>7/8 of 4096 MB to be precise in the way GB is defined. Graphics card is usually main culprit if that border is not reached, but every HW device needing a mapped area in memory space will reserve area(s) in the space being counted from top. The rest of installed memory need not be wasted: it can be used via PAE as Rick mentions, which allows it to be used for faster paging of the usual OS memory space - instead of swap file the other memory is used as paging target. It is also possible to use such memory for a pure RAM disk similar to the way DOS used extended memory. Quite useful for vfp-style datamunging, if temp files go over there or it is used for intermediate tables or a temp database in more server centered SQL types, if the backend does not allow directing into a MEMORY: type device (to describe SQLite pattern as example).

PAE always struck me as a "DOS Extender"-style hack/workaround. I never used it, nor worked with anyone else's server that had it enabled. It was really a way to give certain processes more memory in the days when 64-bit OSs (especially Windows) were not production-ready.

My understanding is not all device drivers were stable in a PAE environment, and for Windows processes to access more than 4GB of address space they had to use a special API. Or, as you say it could support some specialized uses such as a RAM disk.

These days PAE is really just a historical curiosity. Given mature 64-bit OSs and hardware, no-one should be using it any longer.

>My rule of thumb is only starting with 8192MB to always go for 64bit OS. 6144 MB my watershed: if the OS only/mostly houses VM's, use 64bit host OS, otherwise often 32 bit OS is better. On a 4GB device use 32bit, unless somthing specific like testing in 64 is needed. Even then multiboot is an option ;-)

Not sure I agree with that. Extra available physical RAM is always a huge win. Suppose you run a certain load of 32-bit apps on a 4GB machine. App memory use is about the same under either 32- or 64-bit Windows. However, on the 64-bit OS you actually get to use all of the top ~512MB for a disk cache, or as extra available real physical RAM for the apps to share. Anything over 4GB just gets better and better.

Yes, in general it's probably not wise to run 64-bit Windows apps on a machine with only 4GB because on average they're larger. But even that rule could be broken if you were running even one 64-bit app that needs, or could make good use of, anything over 2GB by itself.

>>>But if I have a 64 bit OS what you have said above applies ( with Craig's post implying that VS the same in 32 or 64 )
>
>A 64VS will need slightly more memory if only for memory pointers being doubled in size even if compiled from identical code base.
>
>>>As to SQL server, am I correct that it is optimized for 64 bit if you run 64bit on Win7 64 (or does that only matter in mult-processer scenarios etc?)
>>
>>I don't know about specific code optimization for 64 bit but it's possible. What it will do is use more RAM if it's available. Of course that's for versions other than Express, it is limited to 1GB RAM usage.
>
>DB handling just is one of the best use cases where throwing RAM at the task yields performance.