whats the point of more than 4gb on a 32bit system?

[imagoon]

Yeah, you really have to work in this day and age to get a configuration that doesn't work fine in 64bit Windows - at least as a user. For companies that can be quite different (oh all those companies with legacy 16bit programs and 15year old hardware that can't be replaced)

Of course. I always analyze my enterprise before pushing out updates (software and hardware). There will always be cases like this. In the past I have just isolated systems that run things like embedded versions of Windows and Linux that can't be upgraded. A little time with wireshark and some ACL's can normally protect those systems pretty well (assuming TCP/IP here.)

 

[allanon1965]

thanks for the comments fellas, I appreciate all the posts!

 

[taltamir]

What driver issues would these be? The only ones I've experienced have been with nVidia, and those were (a) not show-stoppers (just annoying driver crashes), and (b) got fixed 2-3 months into Windows 7 being out. Plenty of unsupported peripherals out there, but other than that, it's been quite good.

exactly, I would say that even having a 32bit version of vista and later win7 was one of the stupidest things MS ever did.
64bit vista and win7 run 32bit programs just fine. And all drivers had to be rewritten for vista+ anyway. Many many peripherals are not vista+ compatible, only a rare few are not 64bit compatible.
Although, some old peripherals eventually got 32bit vista support, it was just a waste of effort. if there was no 32bit vista they would have instead made a 64bit vista driver and be done with it.

 

[deimos3428]

Just out of curiosity, couldn't you just put a massive swap file onto a Windows XP ramdisk and effectively use all 16gb of your memory?

Chicken and egg.

If you had a ramdisk, you could certainly put a pagefile on it -- just like any other disk. It'd be fast, too. The problem is the OS can only see 4GB, so it can't build the ramdisk using the inaccessible 12GB. If it could, you wouldn't need it in the first place.

Now if you were both rich and insane, you could buy a RAM-based SSD and put a pagefile on it for some very, very expensive and fast virtual memory. It's much cheaper and more sensible to upgrade the OS to 64-bit.

 

[Nothinman]

exactly, I would say that even having a 32bit version of vista and later win7 was one of the stupidest things MS ever did.
64bit vista and win7 run 32bit programs just fine. And all drivers had to be rewritten for vista+ anyway. Many many peripherals are not vista+ compatible, only a rare few are not 64bit compatible.
Although, some old peripherals eventually got 32bit vista support, it was just a waste of effort. if there was no 32bit vista they would have instead made a 64bit vista driver and be done with it.

Actually, I believe that in order to pass WHQL a driver needs both a 64-bit and 32-bit build. So anything that doesn't support both is going to be crap anyway.

If you had a ramdisk, you could certainly put a pagefile on it -- just like any other disk. It'd be fast, too. The problem is the OS can only see 4GB, so it can't build the ramdisk using the inaccessible 12GB. If it could, you wouldn't need it in the first place.

I believe at least one ramdisk driver out there manually accesses the normally inaccessible memory so you can use it for a ramdisk. It's the ultimate version of duct tape, but it exists for the luddites that want it.

 

[Voo]

Actually, I believe that in order to pass WHQL a driver needs both a 64-bit and 32-bit build. So anything that doesn't support both is going to be crap anyway.

Iirc you can release a 64bit version alone, the 32bit version is optional. Since there's not even a 32bit server version anymore that makes sense.

@Talta: Considering the gigantic amounts of problems with 64bit drivers at the beginning, I wouldn't say that, the argument could be made that when vista was released more than 4gb RAM were not especially common (or useful for most users) and you got around enough problems that way.

 

[taltamir]

@Talta: Considering the gigantic amounts of problems with 64bit drivers at the beginning

there was never such a thing. at the begining there was a limited selection of 64bit drivers, that is all. They never had any problems.
The nvidia driver problems were not limited to 64bit, and were most likely because they were first to market with DX10 cards

furthermore, 4GB+ of ram is a strawman and is the least important thing about 64bit, by far. The most important is the extra performance because AMD64 architecture calls for extra components on the CPU, such as registers, which enable more performance.

 

[Voo]

there was never such a thing. at the begining there was a limited selection of 64bit drivers, that is all. They never had any problems.

That may be your opinion, but I've seen many compatibility problems with the 64bit drivers and had a lot less problems with the 32bit ones in the first few months, not to speak of the fact that many drivers didn't even have 64bit versions since those had to be digitally signed.

And apart from a few benchmarks the real world performance difference between 64 and 32bit is hardly that great and you can even find counterexamples where the 64bit version leads to more memory pressure and reduced performance.

 

[Nothinman]

Iirc you can release a 64bit version alone, the 32bit version is optional. Since there's not even a 32bit server version anymore that makes sense.

Probably true, my point was more that 64-bit drivers were required for WHQL qualification since Vista so there should be no problems with them, especially now 5yrs later.

 

[taltamir]

not to speak of the fact that many drivers didn't even have 64bit versions since those had to be digitally signed.

Not to speak of it? I specifically brought it up.
furthermore, if they only had 64bit then development could focus on one single driver rather then multiple, less problems all around.

And apart from a few benchmarks the real world performance difference between 64 and 32bit is hardly that great and you can even find counterexamples where the 64bit version leads to more memory pressure and reduced performance.

hash calcs are 300% to 400% faster, divx 60% faster, 7z compression 23% faster, and x264 will not benefit according to main developer.
The "reduced performance" instances due to overhead will be less than 1% reduction since its so negligible an overhead.

What it does do is take more HDD space.. but only because MS is preserving 32bit compatibility with 64bit, thus 64bit windows has 2 copies of everything, 1 in 32bit and 1 in 64bit.

I would like you to please actually name a driver that was actually buggier in 64bit than it was in 32bit... Lack of drivers I agree, buggy I disagree. And bugs 64bit architecture does not lend itself to bugs more then 32bit... if there WAS a single case where the 64bit driver was buggier it would be coincidence, just as if the 32bit driver was buggier... but if they had only 1 driver the more QA could be done overall.
Although it is possible that some companies focused QA on 32bit over 64bit.. overall the only issue you had with drivers is that they simply didn't exist. But very very few cases where they made a vista driver and not a 64bit driver... 64bit was actually around a lot longer. XP 32bit came out in 2002, xp 64bit in 2003 (based on win server 2003), and vista in 2006. I had seen a bunch of peripherals with an XP32bit and XP64bit driver but no vista driver (of any kind)

 

[Voo]

I would like you to please actually name a driver that was actually buggier in 64bit than it was in 32bit.

Uh well my HP printer driver if you ask me out of the blue - oh the fun I had with it. 64bit was still quite new for most developers, so not that big a surprise that their crept in some mistakes - there are quite a few things in C that work perfectly fine on 32bit Windows but can lead to extremely interesting results when using 64bit pointers (trivial example: assuming sizeof(void*) == sizeof(int)) and WHQL drivers don't guarantue a 100% coverage of the driver (which is incidentially the halting problem in disguise, so pretty hard to do).
Although I must say I find it quite funny how you know better than me, what problems **I** had with what drivers ;-)

hash calcs are 300% to 400% faster, divx 60% faster, 7z compression 23% faster, and x264 will not benefit according to main developer.
The "reduced performance" instances due to overhead will be less than 1% reduction since its so negligible an overhead.

Well the worst case is 50% less of your d-cache when going from 64 to 32bit and I've talked with HPC programmers who said that was an actual concern and measureable.

Also 23% faster 7z compression? I remember testing that myself some time ago and thanks to that nice inbuilt benchmark in 7z I decided to give it a fast go.
build: 7-Zip 9.20 2010-11-18
Win7 Professional 64bit SP1
e8400 at base speed
default settings for both; 15passes (was stable already there)

x64:
compression: 3225mips
decompression: 2935MIPS
total: 3075mips

x86:
compression: 2981mips
decompression: 3022MIPS
total: 3001mips

Which makes a difference of a whopping ~2.5%, which sounds much more in the usual ballpark. Most real life programs don't spend all of their time doing only one thing, so even if you get a great boost for hashing, on a whole the difference won't be that extreme.

 

[Voo]

lalala. ups

 

[taltamir]

Uh well my HP printer driver if you ask me out of the blue - oh the fun I had with it. 64bit was still quite new for most developers, so not that big a surprise that their crept in some mistakes - there are quite a few things in C that work perfectly fine on 32bit Windows but can lead to extremely interesting results when using 64bit pointers (trivial example: assuming sizeof(void*) == sizeof(int)) and WHQL drivers don't guarantue a 100% coverage of the driver (which is incidentially the halting problem in disguise, so pretty hard to do).
Although I must say I find it quite funny how you know better than me, what problems **I** had with what drivers ;-)

One driver issue doesn't make it a pervasive problem. I don't know what problems you personally had, but you said "gigantic amount of problems with 64bit", which I took to mean "widely prevalent and more common then 32bit problems or vista issues". I disagree with you that it was a universal thing. I am talking about the whole, not individual examples.
But thank you for the example driver, I am not in the least bit surprised it was an HP printer...

Well the worst case is 50% less of your d-cache when going from 64 to 32bit and I've talked with HPC programmers who said that was an actual concern and measureable.

Its a good thing than that windows 64bit is fully capable of running 32bit code.
With 64bit windows you are able to run both types of code and as such developers may use whichever runs faster. I wasn't saying that MS Should have made 64bit windows unable to run 32bit programs, I said they should not have made a 32bit version of windows.

Also 23% faster 7z compression? I remember testing that myself some time ago and thanks to that nice inbuilt benchmark in 7z I decided to give it a fast go.

I personally benchmarked it as 23% faster. I did not use the built in benchmark, I compressed the same folder with the 32bit and 64bit versions and timed it several times.
(it was a large enough folder that human error was irrelevant). And was a much earlier version.

 

[podspi]

I find 32 bit windows usually only gives me 3.2gb usable.

Someone correct me on this if I'm wrong, but I have a feeling you can use a ramdisk within 32 bit Windows. The problem is that there's not that much you can do with a ramdisk unless you leave your computer on all the time.

You can, but it is a bit unstable. For a while I was doing exactly that, 4gb + 4gb RAM disk (I was hosting a minecraft server, and was afraid the constant writing to a disk would hose my terrible SSD).

 

[Voo]

One driver issue doesn't make it a pervasive problem. I don't know what problems you personally had, but you said "gigantic amount of problems with 64bit", which I took to mean "widely prevalent and more common then 32bit problems or vista issues". I disagree with you that it was a universal thing. I am talking about the whole, not individual examples.

Well so your circumstancial evidence (at least I'ye never seen a official chart from MS that differentiated driver problems between 64 and 32bit) stands against mine as I see it - but really either way that's years behind us and not really important to the current discussion anyways.

But yes, HP is really.. fun in that regard. After they finally got stable printers they decided to find out how much mb one would download for a simple printer driver before trying to hire a hitman for whoever commited a 700mb printer driver download..

 

[Cerb]

But yes, HP is really.. fun in that regard. After they finally got stable printers they decided to find out how much mb one would download for a simple printer driver before trying to hire a hitman for whoever commited a 700mb printer driver download..

Ah, I love those.

Here's another good one:
It was a workstation with a low-end business all-in one, and it had apache w/ tomcat running as part of the HP driver, and apache wrote to a log, and forced a drive sync operation, once every second. Most of the log entries in this rolling log were pretty much, "everything is fine, move along." Nowhere could I find a way to disable it, and the non-print host-based features were needed (my choices were print-only, or the 300+MB software package). AutoCAD magically sped up, once it was finally replaced with a networked AIW, that only had a ~40MB driver (including the proprietary scanning, faxing, and OCR programs).

 

[taltamir]

Well so your circumstancial evidence (at least I'ye never seen a official chart from MS that differentiated driver problems between 64 and 32bit) stands against mine as I see it - but really either way that's years behind us and not really important to the current discussion anyways.

fair enough

 

[Emulex]

if a card was designed for 32 bit addressing it would have a challenge in a 64bit system? this is more likely old pci cards since all of that was fixed in pci-x. This might also affect pcmcia but man people still rock old systems with pci video cards. servers back then didn't even have qualified drivers. I've seen this along time ago. you gotta remember folks still rock ie6 and the machines they came on lol. the servers that were designed with extended addressing were qualified and stable. dark times those were.

 

[taltamir]

if a card was designed for 32 bit addressing it would have a challenge in a 64bit system?

no

this is more likely old pci cards since all of that was fixed in pci-x.

What was fixed?

This might also affect pcmcia but man people still rock old systems with pci video cards.

Rock?

servers back then didn't even have qualified drivers.

Huh? are you referring to WHQL? cause that is just an MS scam to milk money from hardware developers... WHQL is meaningless.
Business servers in the PCI era most definitely got their drivers qualified before being put into a production environment.

I've seen this along time ago.

You have seen what?

you gotta remember folks still rock ie6

I think you confuse "rock" for "use"... do you mean "use and it is rock stable" perhaps? IE6 is a POS and nobody should use it.

and the machines they came on lol.

Who is they? IE6 is not a they.

the servers that were designed with extended addressing were qualified and stable. dark times those were.

What?

 

[LiuKangBakinPie]

The problem is how many pure 64bit apps are out there. Most of the applications we run are 32bit apps on a 64bit OS. Now that means more I/0. Pci-e devices have less of a overhead in 64bit. But problem with windows 7 is its bundled with a half finished sound api. And it will never be finished as its been abandoned by Microsoft.
Another killer is security software. The internet suites killed Vistas rep and its the vendors stubborn approach to fix their own issues as well.

 

[Nothinman]

The problem is how many pure 64bit apps are out there. Most of the applications we run are 32bit apps on a 64bit OS. Now that means more I/0.

A 32-bit process running in a 64-bit kernel doesn't have any real additional overhead. The CPU executes it natively just like a 64-bit process and, on Windows at least, WoW64 just finds the appropriate 32-bit libraries instead of the 64-bit ones.

 

[Emulex]

if the card can't do dma 64bit you would have to double buffer. i believe that is what i was saying that some legacy cards are buggy operating in this mode and it adds more overhead (say a pci raid controller).

pci-X fixed these problems (in fact many cards use pci-E to pci-X bridge chips to date) but most consumer products never got pci-X. Not sure how AGP fits into this but its kinda irrelevant now.

PAE mode with /USERVA=2500 (or /3gb if you dare) allows win2k3 EE (and hacked XP/VISTA/WIN7) to use the ram for more buffers or ramdisk. it's not a supported hack except 2k3 EE/2k8 enterprise in 32bit mode but you can do it if you want to live with the consequences.

 

[hanspeter]

iPAE mode with /USERVA=2500 (or /3gb if you dare) allows win2k3 EE (and hacked XP/VISTA/WIN7) to use the ram for more buffers or ramdisk.

You don't have to hack your Windows to install a ramdisk.

 

[Emulex]

which ramdisk for free can access the forbidden zone 32bit highmem?

 

[hanspeter]

I bet google holds the secret to that