The Athlon64 can execute a 64bit and 32bit instruction simultaniously. But with windows xp 64, rather than executing the 32bit instructions on the Ahtlon64, wow64 converts the 32bit instruction to a 64bit instruction and executes it on the Athlon64 as a 64bit instruction. This seems to me as a bad idea, as executing 32bit instructions directly on the Athlon64 would be more efficient... as the cpu would be able to get in two intructions simultaniously (in theory, one 32bit, and one 64bit instruction).... Any thoughts on why microsoft did this?
-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
does wow64 on windows xp 64 suck?
- Thread starter TheMouse
- Start date
imported_michaelpatrick33
Platinum Member
The WOW emulator for Windows 64 from the prelimary results show that the 32bit programs (not games with beta drivers) actually run faster than their native 32bit OS's. This ensures complete 64bit usage on the OS and I would imagine keeps the complexity of having double .dll's etc for both 32bit and 64bit operations.
Microsoft states that the WOW on Windows 64 runs the 32bit programs (I can't remember exactly but I am in the ballpark) 10 percent faster. Pretty effective I would say if true
Microsoft states that the WOW on Windows 64 runs the 32bit programs (I can't remember exactly but I am in the ballpark) 10 percent faster. Pretty effective I would say if true
Originally posted by: michaelpatrick33
The WOW emulator for Windows 64 from the prelimary results show that the 32bit programs (not games with beta drivers) actually run faster than their native 32bit OS's. This ensures complete 64bit usage on the OS and I would imagine keeps the complexity of having double .dll's etc for both 32bit and 64bit operations.
Microsoft states that the WOW on Windows 64 runs the 32bit programs (I can't remember exactly but I am in the ballpark) 10 percent faster. Pretty effective I would say if true
yea, the benchmarked showed slightly better performance in all areas other than ALU. But it seems to avoid the fact that an athlon64 can run a 64bit and 32bit instruction simultaniously. If what Agamar said is true, thats a shame
imported_michaelpatrick33
Platinum Member
The reason it needed run 32bit and 64bit simultaneously was to compete with Intel until 64bit moved mainstream. When going to 64bit there are 16/64bit GPR's for native 64bit compiled programs available vs 8/32bit for all 32 bit compiled programs. That should definitely promote better performance (even more than the 64bit part, except for encoding which shows massive gains on 64bit). I believe Linux can run 64bit and 32bit programs simultaneously on the fly but I am not sure.
Why does it matter if it can run the 32bit and the 64bit simultaneously if the WOW is faster than the native 32bit OS? Do you mean that the OS can't run a native compiled 64bit app in pure mode (i.e. extra registers) at the same time as a WOW 32bit app in 64bit compatability mode?
Why does it matter if it can run the 32bit and the 64bit simultaneously if the WOW is faster than the native 32bit OS? Do you mean that the OS can't run a native compiled 64bit app in pure mode (i.e. extra registers) at the same time as a WOW 32bit app in 64bit compatability mode?
Originally posted by: michaelpatrick33
The reason it needed run 32bit and 64bit simultaneously was to compete with Intel until 64bit moved mainstream. When going to 64bit there are 16/64bit GPR's for native 64bit compiled programs available vs 8/32bit for all 32 bit compiled programs. That should definitely promote better performance (even more than the 64bit part, except for encoding which shows massive gains on 64bit). I believe Linux can run 64bit and 32bit programs simultaneously on the fly but I am not sure.
Why does it matter if it can run the 32bit and the 64bit simultaneously if the WOW is faster than the native 32bit OS? Do you mean that the OS can't run a native compiled 64bit app in pure mode (i.e. extra registers) at the same time as a WOW 32bit app in 64bit compatability mode?
I just feel that when AMD marketed the cpu, they claimed that it can run a single 32 bit instruction and a single 64 bit instruction at the exact same time in parallel... and microsoft's OS design limits that by emulating 32 bit through wow64, rather than executing it directly on the cpu.
imported_michaelpatrick33
Platinum Member
From what it appears however, Microsoft discvored that simultaneously running a pure 64bit app instruction and running a 32bit instruction in WOW was more efficient and faster than running one 32bit and ond 64 bit app at the same time in their native modes. I wonder if this is because it helps the efficiency of the processing by only having a 64bit mode running and not having 32bit driver compatability issues hanging around? Everything in 64bit mode (compatability or pure) probably is easier to implement. For example, what would happen if you had a 32bit 3d program running and then tried to run a 64bit 3d program. I would imagine the Video driver would go bonkers so Microsoft created a scheme (with no penalty no less) to bring the 32bit 3d program to "64" bit to be recognized by drivers etc. and OS without creating massive compatability issues and/or restricting the OS to 64bit only everything
i think your making it more complicated then it realy is.
People have known for a long long time that running emulated code can often result in faster performance.
That's the whole point behind something like the transmeta CPU chip. The chip itself is very alien by uses the "code morphing" technics to translate x86 instructions into something the cpu can use.
That's one of the reasons it was choosen for that "green blade" supercomputer that was built a while back. Normally that CPU is very slow for stuff like floating point instrunctions compared with the Pentiums and Althons CPUs, but in scientific number crunching your running the same algorythms and instructions over and over and over again, so this "code morphing" that it does has a chance to make the CPU very very efficient, and that combined with it's extremely low power usage made it so that you could run certain types of equations and such that would normally take a much larger/expensive/hot machine to get done in the same time period.
The reason that you get better performance is because of instruction caching. What happens is the first time you run a program initially it's much slower then running it natively. However programs run in loops, they do the same thing over and over and over again. So during the emulation it optimizes and streamlines the code, and caches it. Next time the computer is required to rerun that section of the program it just reruns the highly optimized instructions it has cached instead of the actual code.
I think that HP was the first one to discover this, they were doing some experiments and ran a emulated Alpha proccessor on a native Alpha proccessor... (I think it was a alpha could of been a risc or something like that.)
So that's probably why you'll get the slight performance increase. The AMD-64 is also more efficient the x86, it's stuff is better optimized and better designed instructions then what was originally made with the early first generation pentiums and 386/486 machines.
How WOW works is basicly you have a entire 32 bit OS running inside a 64bit OS. So your going to end up with a whole set of 32 bit DLLs combined with a whole set of 64bit DLLs needed run any program.
It's pretty much what Linux does. You have a entire 64 bit set of runtime libraries and a set of 32 bit runtime libraries for 64 bit and 32 bit programs respectively. The kernel itself is what translates the 32 bit instructions to run in normally 64 bit enviroment.
WOW stands for Windows On Windows.
People have known for a long long time that running emulated code can often result in faster performance.
That's the whole point behind something like the transmeta CPU chip. The chip itself is very alien by uses the "code morphing" technics to translate x86 instructions into something the cpu can use.
That's one of the reasons it was choosen for that "green blade" supercomputer that was built a while back. Normally that CPU is very slow for stuff like floating point instrunctions compared with the Pentiums and Althons CPUs, but in scientific number crunching your running the same algorythms and instructions over and over and over again, so this "code morphing" that it does has a chance to make the CPU very very efficient, and that combined with it's extremely low power usage made it so that you could run certain types of equations and such that would normally take a much larger/expensive/hot machine to get done in the same time period.
The reason that you get better performance is because of instruction caching. What happens is the first time you run a program initially it's much slower then running it natively. However programs run in loops, they do the same thing over and over and over again. So during the emulation it optimizes and streamlines the code, and caches it. Next time the computer is required to rerun that section of the program it just reruns the highly optimized instructions it has cached instead of the actual code.
I think that HP was the first one to discover this, they were doing some experiments and ran a emulated Alpha proccessor on a native Alpha proccessor... (I think it was a alpha could of been a risc or something like that.)
So that's probably why you'll get the slight performance increase. The AMD-64 is also more efficient the x86, it's stuff is better optimized and better designed instructions then what was originally made with the early first generation pentiums and 386/486 machines.
How WOW works is basicly you have a entire 32 bit OS running inside a 64bit OS. So your going to end up with a whole set of 32 bit DLLs combined with a whole set of 64bit DLLs needed run any program.
It's pretty much what Linux does. You have a entire 64 bit set of runtime libraries and a set of 32 bit runtime libraries for 64 bit and 32 bit programs respectively. The kernel itself is what translates the 32 bit instructions to run in normally 64 bit enviroment.
WOW stands for Windows On Windows.
Ya, I don't know if it will be faster or not. I know that it CAN be faster (I won't beleive any MS claim until I see it in the flesh, very probably it will be slower slightly), but their are many different types of emulation. The majority of the time it will be slower....
Like if you look at VMware and Virtual PC, these things run relatively close to native system speeds. see here.
Then you have stuff like Wine, which isn't realy a emulator, but has OSS versions of the Win32 API so that windows programs can run almost natively under Linux.
But then you have emulators like bosch were you have many many times slower performance then native.
Then their are others besides that.
The difference between something like bosch and VMware is that Bosch has the entire computer in emulation, everything peice of hardware is fake, in software only. The whole computer only exists in memory only. VMware on the otherhand sets up fake drivers that translate into output that runs directly on your hardware, and cpu instructions run on the actual CPU, instead of a emulated one. Sort of like having protected memory mode when dealing with dos games. (so you may have compatability problems with VMware, but not bosch.. technically. But it can take many many hours to install Win95 using Bosch even on a fast machine)
The major bad thing about running 32 bit programs in Windows 64bit is that your going to have to deal with the overhead of having 2 versions of the same libraries running, the 32bit version and the 64bit version. So if you have a bunch of 32bit programs running and a bunch of 64bit programs running your going to get pretty close to the same amount of overhead as running 2 windows OSes at the same time.
Like if you look at VMware and Virtual PC, these things run relatively close to native system speeds. see here.
Then you have stuff like Wine, which isn't realy a emulator, but has OSS versions of the Win32 API so that windows programs can run almost natively under Linux.
But then you have emulators like bosch were you have many many times slower performance then native.
Then their are others besides that.
The difference between something like bosch and VMware is that Bosch has the entire computer in emulation, everything peice of hardware is fake, in software only. The whole computer only exists in memory only. VMware on the otherhand sets up fake drivers that translate into output that runs directly on your hardware, and cpu instructions run on the actual CPU, instead of a emulated one. Sort of like having protected memory mode when dealing with dos games. (so you may have compatability problems with VMware, but not bosch.. technically. But it can take many many hours to install Win95 using Bosch even on a fast machine)
The major bad thing about running 32 bit programs in Windows 64bit is that your going to have to deal with the overhead of having 2 versions of the same libraries running, the 32bit version and the 64bit version. So if you have a bunch of 32bit programs running and a bunch of 64bit programs running your going to get pretty close to the same amount of overhead as running 2 windows OSes at the same time.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 24K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
