Vista client screenshots and a new "trailer"

[TripleDES]

64-bit Vista (and the already-available 64-bit XP) has a neat little thing called Windows-on-Windows64 (or WOW64, if you want to get confusing). It essentially 'translates' 32-bit apps so that they can run with only a little extra overhead on 64-bit machines. What it precisely does and how heavy the overhead is depends on what you're running. Consumer-grade 64-bit P4s and AMD64 processors are much faster at 32-bit emulation than certain other IA-64 processors (mostly ones built for use in servers) since they have a 32-bit compatibility mode built in.

WOW64 doesn't really translate or emulate anything on x64. When a WOW64 process gets scheduled, it'll drop the processor down into 32bit protected mode to execute the code. The WOW64 environment offers all common 32bit DLLs as 32bit Windows does, and apart from the way kernel calls are done, they're 1:1 the same versions as in Windows Server 2003 32bit. Kernel calls get thunked, the WOW64 supervisor notified, which then switches to 64bit mode and executes the call to the 64bit kernel on behalf of the 32bit code, results get thunked back for the 32bit code. What's happening is simply passing data structures between different protection and addressing modes.

Also, in regards to speed on 64bit systems, the only thing you gain is more general purpose registers with 64bit width, which will speed up nested loops and integer arithmetic, if the 64bit compiler did the job right. The only other thing you gain is a bigger address space, which can be used for memory mapping, which makes bulk processing large datasets easier, because your application can just pretend that all data is loaded in memory and let the paging subsystem do the rest. You'll however not gain nearly double the execution speed just because there's 32 more bits.

[dwindlehop]

Engels: Can you eliminate all the systray and device driver clutter from XP 32? I bet you would achieve the same results.

I do not believe I have seen even AMD or Microsoft make claims of faster boot times or OS response, much less the independent benchmarking press.

The fast 64 bit integer operations don't help. The large page sizes are not used by default in XP 64, and the OS and user applications you are describing will not request them. At most the speedup from the extra registers is 15%, which is not noticeable in the type of operations you are describing. Also, web browsing, file transfers, and application switching aren't the types of workloads which will see a large (>5%) speedup anyway. If you're changing the OS only, then you gain no benefit from the larger address space. There's no feature in XP 64 which would account for the speedup you are describing.

[dwindlehop]

When benchmarking, I do lots of clean installs of XP, both 64 bit and 32 bit. The boot time is always amazingly fast. I get mad at my IT-managed systems which maybe manage to boot in about a day and a half. I also get mad at my home graphics driver and DHCP access, as they take for freakin' forever on boot before I get a command prompt.

[dwindlehop]

The only other thing you gain is a bigger address space, which can be used for memory mapping, which makes bulk processing large datasets easier, because your application can just pretend that all data is loaded in memory and let the paging subsystem do the rest.

Nit: the larger address space does not change the OS disk paging as you describe, it improves the hit rate in the CPU's TLB. It is unfortunate that the disk guys, DRAM guys, and CPU microarchitecture guys all use the word 'page' to describe slightly different things.

Disk pages: the mechanism for providing virtual memory by the OS
DRAM page: largest block of data that can be activated at once
microarchitectural page: changing from virtual to physical addresses, to hide the memory configuration from software

Large page sizes are reflected in the OS disk paging, as that is the fundamental unit in which the OS moves stuff from disk to memory and back. However, it doesn't change the amount of data that can be loaded into memory, nor the rate at which it is loaded. Performance there is limited by the DRAM you have in the system and your disk bandwidth, not the page size. What the larger page size does is allow the CPU to access larger datasets without missing the TLB and having to do a pagewalk, increasing the memory latency. This can be a substantial benefit on applications with such large datasets. Like I said before, though, XP 64 does not hand out large pages by default, simply because that would mean every applications' memory footprint would grow in chunks of 2MB or 4MB. An application must explicitly request a large page when allocating memory.

You can also have a larger process size in a 64 bit OS which means an application can use more memory, but that's just a hard limit. The larger process size does not make existing code faster.

[Engels]

DH,

I've got nearly identical start up processes on both OSes. Perhaps the performance boost I've seen on the IDE drive 64 bit OS over the SATA raid 0 32 bit OS is a function of the 64 bit being a newer install, with somewhat lower file fragmentation, although I have defragged the 32 bit OS often enough to drive performance up.

Regardless, it seems rather odd that the entire industry is shifting to 64 bit architechture, yet according to your descriptions, there's no discernable performance boost in the OS doing 'mundane' tasks.

[Endie]

It's not quite true to say that there's no advantage to XP64 if you run 32-bit processes.  I very often have to run with Visual Studio, Eclipse (notorious memory hog), Toad and the dev license SQL server (and a big DB).  As well as, obviously, stuff like ultraedit, various IE windows, mail client and the rest.  The fact that I can use more than 4GB of ram (and more than 2GB per app) with XP64 is a real plus.  I admit it's a bit specialised, though.

Also, XP64 is actually based on a build of the windows server 2003 codebase, rather than straght from XP32 SP2, which means that there are a few things in terms of stability, security and multiprocessor support it does better.

In all, though, dwindlehop is right: unless you're doing some pretty esoteric stuff, XP64 for pure 32-bit work is shiny and does no real harm, but really isn't needed.

[TripleDES]

Nit: the larger address space does not change the OS disk paging as you describe, it improves the hit rate in the CPU's TLB. It is unfortunate that the disk guys, DRAM guys, and CPU microarchitecture guys all use the word 'page' to describe slightly different things.

Disk pages: the mechanism for providing virtual memory by the OS

This is what I'm talking about, virtual memory paging. Having an address space bigger than 2 gigabytes of user space allows you to clutter it full with tons of memory mapped files.

Regardless, it seems rather odd that the entire industry is shifting to 64 bit architechture, yet according to your descriptions, there's no discernable performance boost in the OS doing 'mundane' tasks.

Those performance improvements in the server space come from the larger address spaces. You can address vast amounts of memory without going through stupid hacks like PAE and address windowing. A database server feels happier with 64 gigabytes of linear addressed space instead of 3 gigabyte or maybe 8 gig with PAE/AWE hacking (which eats CPU cycles).

[Arrrgh]

If you had no idea how many people raided and just based your estimate on threads like this you'd conclude 95% of players raid.

[dwindlehop]

This is what I'm talking about, virtual memory paging. Having an address space bigger than 2 gigabytes of user space allows you to clutter it full with tons of memory mapped files.

I gotcha now. That is an interesting use of a large address space. As a hardware guy, I am continually amazed by the things that people make software do.  :-D

[Engels]

Those performance improvements in the server space come from the larger address spaces. You can address vast amounts of memory without going through stupid hacks like PAE and address windowing. A database server feels happier with 64 gigabytes of linear addressed space instead of 3 gigabyte or maybe 8 gig with PAE/AWE hacking (which eats CPU cycles).

So basically you are all telling me that AMD came out with scores of 64 bit AMD chips a year and a half ago, specifically marketed for the home user and put in every AMD box out there now yet it has no bearing whatsoever on end-user OS performance ( and I myself am hallucinating) ?

[dwindlehop]

http://myeve.eve-online.com/devblog.asp?a=blog&bid=330

Timeline!

September - contracts, gang improvements, reverse engineering, mods, salvage, boosters, new ships, new regions
December - factional warfare
April 2007 - Eve Classic (DX9) graphics upgrade, intro of Eve Vista (DX10) (this is what CCP is calling what was referred to as "Eve for Vista" earlier in the thread)

And on the subject of integrated voice chat:

Sure, not everyone wants it. That's one of the main reasons why only those that do want it will have to pay for it. It's optional. There will be opportunities for a corp to enable it for all its members, which is really our main target group.

[dwindlehop]

Engels- you are not hallucinating. The speedup you describe is not due to the 64 bit nature of the OS, though.

[Yoru]

http://myeve.eve-online.com/devblog.asp?a=blog&bid=330

Timeline!

September - contracts, gang improvements, reverse engineering, mods, salvage, boosters, new ships, new regions
December - factional warfare
April 2007 - Eve Classic (DX9) graphics upgrade, intro of Eve Vista (DX10) (this is what CCP is calling what was referred to as "Eve for Vista" earlier in the thread)

And on the subject of integrated voice chat:

Sure, not everyone wants it. That's one of the main reasons why only those that do want it will have to pay for it. It's optional. There will be opportunities for a corp to enable it for all its members, which is really our main target group.

Later than what they told me, but at least they cleaned up the terminology. And, ooh, new regions. More space to dicker over.

[Engels]

Engels- you are not hallucinating. The speedup you describe is not due to the 64 bit nature of the OS, though.

Is it to do with the fact that the 64 bit OS was built around aspects of an AMD 64 chip that were unused while using regular XP pro? Because I am being 100 percent honest that the builds are near identical as far as start up processes that the user configures (The native ones I have no notion about). It also mystifies me that an OS would be zippier on an pata w/o raid than on a sata w/ raid0. Why would that be the case if it weren't the OS itself being faster, all other parameters being equal?

[TripleDES]

So basically you are all telling me that AMD came out with scores of 64 bit AMD chips a year and a half ago, specifically marketed for the home user and put in every AMD box out there now yet it has no bearing whatsoever on end-user OS performance ( and I myself am hallucinating) ?

The OS itself doesn't do nearly enough computation to notice a performance improvements. Any speed ups noticed are architecturally related and as such to be noticed on both OS variants.

You'll only notice speed ups on applications that do 64bit integer math, which can be executed completely on hardware in less cycles compared to a 32bit CPU, and on applications that do a lot of/complex integer calculations generally, because there's more general purpose registers available, which allows the compiler to reduce data movements between the CPU and memory when doing these calculations. On top of that I think there's also more FPU registers, which would speed up complex floating point math a lot, but I'm not really sure of that one.

However note that you can only access these wider and additional registers if you run in 64bit mode, which the 32bit Windows version definitely doesn't. And you need applications that were compiled with an optimizing 64bit compiler.