Recommended Posts

Lots of reviews have been using Vista x64 when benchmarking newer gfx cards with different games. And really, I could be wrong, but even with x64 the CPU is still x86, I don't think Windows is actually emulating everything like some might think it is. Since the hardware can do 32bit or 64bit, it's a simple switch that needs to be done I believe.

Sorry to break it to you but unless manufacturers make x64 drivers 100% compatible with x64 and most programs avalible on the market compatible x64 only wont be an option, and there are still x86 processors out there and you still need x86 to create binarys for x64 so x64 would be a disaster, so umm dont compare x86 with x64

Every single piece of software that I use on x64 works perfectly.

That little part in bold up there...a bit uhm, well, yeah. :rolleyes: :blink: I hope you meant to say "you still need x64 to create binaries for x64" Either way, both statements are false.

What if some smart individual designs a 32bit structure that can use more then 4GB, would 64bit disappear?

impossible it is by design , unless using P.A.E. which has special requirement

32bit = 2^32 = 4,294,967,296 bit

Connect works, i'm logged in :) no Windows 7 :p

Also 7015.0.081218-1724 does not seem right.

6.1.7013.0 was built 081220-1600 - So how can Build 7015 be built before 7013 am i making sense?

So Build 7015 is 18th Dec 08

And Build 7013 is 20th Dec 08

See where i'm coming from?

v6.1.7003 was 01/12/08

v6.1.7004 was 03/12/08

v6.1.7012 was 15/12/08

7003 was not the 1st, 7004 was not the 3rd. Unless you're talking about some sub labs. I am talking about WinMain builds. And I never post information that's wrong.

Edited by creamhackered
Lots of reviews have been using Vista x64 when benchmarking newer gfx cards with different games. And really, I could be wrong, but even with x64 the CPU is still x86, I don't think Windows is actually emulating everything like some might think it is. Since the hardware can do 32bit or 64bit, it's a simple switch that needs to be done I believe.

the only case that there are emulation for 32bit softwares is using the windows IA64(intel itanium 64) edition

it is not combitable with x86 ,32bit software run with performance plenty(slowdown) by doing so .

Sorry, my bad. I mean, for x86 programs to work on x64 :

http://blogs.msdn.com/oldnewthing/archive/...22/9244582.aspx

This also means that it is slower, as it is emulation.

If I remember rightly (it's been a while since I read up on this), the 'emulation' that we are talking about here is not the same kind of emulation that you will find in the Itanium (i64) builds of Windows.

On Itanium, the processor is physically unable to run x86 code, so the WOW64 emulator completely translates the code to Itanium compatible instructions and passes these to the CPU. This is like running the PowerPC versions of Linux inside PearPC on an x86 machine (or in fact games console emulators like SNES). Complete emulation like this will obviously impact performance.

On x86-64 (x64), the WOW64 'emulator' simply redirects all calls from 32 bit application to the system registry and folder locations into a seperate area, so that the 32 bit apps cannot conflict in any way with the 64 bit apps. CPU instructions on this platform however, are not emulated, and are passed directly to the CPU, as every x64 compatible processor is capable of natively running x86. In this case, there is no slow down as there is no CPU emulation.

It seems there is a lot of confusion when people talk about x86-64 and 64-bit, as Itanium does tend to get involved.

It is possible that I am also very confused, so if anyone knows better please post :)

If I remember rightly (it's been a while since I read up on this), the 'emulation' that we are talking about here is not the same kind of emulation that you will find in the Itanium (i64) builds of Windows.

On Itanium, the processor is physically unable to run x86 code, so the WOW64 emulator completely translates the code to Itanium compatible instructions and passes these to the CPU. This is like running the PowerPC versions of Linux inside PearPC on an x86 machine (or in fact games console emulators like SNES). Complete emulation like this will obviously impact performance.

On x86-64 (x64), the WOW64 'emulator' simply redirects all calls from 32 bit application to the system registry and folder locations into a seperate area, so that the 32 bit apps cannot conflict in any way with the 64 bit apps. CPU instructions on this platform however, are not emulated, and are passed directly to the CPU, as every x64 compatible processor is capable of natively running x86. In this case, there is no slow down as there is no CPU emulation.

It seems there is a lot of confusion when people talk about x86-64 and 64-bit, as Itanium does tend to get involved.

It is possible that I am also very confused, so if anyone knows better please post :)

+100

you got it in the right track (Y)

On Itanium, the processor is physically unable to run x86 code, so the WOW64 emulator completely translates the code to Itanium compatible instructions and passes these to the CPU.

Yes, when Intel bought the DEC Alpha 64 bit CPU technology from Compaq, they acquired the FX!32 binary translation/emulation program code used to run 32 bit applications on 64 bit DEC Alpha processors. For the Itanium, Intel uses the latest, updated, rebranded version of that code.

Sorry, my bad. I mean, for x86 programs to work on x64 :

http://blogs.msdn.com/oldnewthing/archive/...22/9244582.aspx

This also means that it is slower, as it is emulation.

It's a negligible performance loss. Seriously, the 2003 FUD against 64-bit doesn't work anymore with hardware and drivers the way they are nowadays.

I'm thinking at least some info will be announced today. Typical PST time though, means it's around 2 in the morning over here in the UK.

2:30am to be exact :)

I'll be posting all the stream URLs and a Coveritlive blog up later for everyone to follow along :)

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.