WinHEC 2005 - Keynote and Day 1
by Derek Wilson & Jarred Walton on April 26, 2005 4:00 AM EST- Posted in
- Trade Shows
The Benefits of XP-64
The ability to address more memory isn't the only change with XP-64. It may be the most immediately noticeable change, but there are other reasons for the switch. So what sorts of benefits will you see by the transition to XP-64? The following slide was provided as an outline of improvements.
We've already discussed the larger memory support, but other performance improvements are still present. X86-64 (which we'll use as the generic term to encompass both AMD64 and EM64T) doubled the number of registers from eight in the 32-bit world to sixteen in the 64-bit world. Depending on the application, the additional registers could help a little or a lot. Anand is still working on benchmarks, and the change in OS has brought quite a few difficulties for our benchmarking setup, but chats with a few vendors suggest that the additional registers should bring on average somewhere around a 7% performance boost. Again, that's just a guess, but it's important to remember that hardware designers and compilers have been working around the idiosyncrasies of the x86 architecture for several decades now, and with techniques such as register renaming, additional registers aren't going to bring massive performance boosts in most scenarios.
Several of the bullets in the slide are essentially just filler material; we've heard many times about how the latest OS provides better productivity, a great platform for new software, and improved reliability. Sometimes we see those features, sometimes we don't; only time will tell. The enhanced layer of hardware protection is actually present, via the XD/NX (execute disable/no execute) bit that Intel and AMD provide in their latest processors. How successful that feature becomes - it's already enabled in XP SP2 - is still up for debate, however.
At this point in the keynote, Microsoft began to give some specific examples of the performance benefits that were possible with the shift to 64-bits. We remain somewhat skeptical in some instances, but there are definitely areas that stand to benefit. The first demonstration was of NewTek's LightWave 3D rendering software, comparing the 32-bit and 64-bit versions. We tried to take some shots, although they are blurry and dark at best.
 |
 |
The presenter, Jay Kenny, gave some example interactions and suggested that model complexities could be increased substantially with the 64-bit version. He stated that certain complex scenes that would have required 100 passes in the 32-bit version could be done in as few as 7 passes in the 64-bit version, although it appears that each pass took longer in the 64-bit version as the average speedup was claimed as around 3X. Another example given was the ability to work in more completely rendered environments rather than flat shading models, although we're not entirely sure what constraints prohibited the 32-bit version from using textures.
The next example given was of SQL Server 2005, once again running 32-bit and 64-bit versions on the respective OSes. The hardware was supposedly identical, but as you can see in the slides, the 32-bit system reports 1 GB RAM and Page File sizes while the 64-bit system reports 2 GB RAM and Page File sizes. Our impression was that there were some smoke and mirrors present, but we would still expect a large database to have substantial performance benefits by running in a 64-bit world. The demonstration showed CPU usage spiking to 100% rather rapidly in the 32-bit world, while the 64-bit world was able to handle 5X as many clients at a lower total CPU usage.
After the demonstrations, we were shown the above list of current 64-bit solutions being offered by Microsoft, as well as their plans moving forward. Not surprisingly, all of the solutions MS is focusing on are related to the server environment. MS is more dependent on 3rd party support for the desktop applications that can benefit from 64-bits, and now that XP-64 is officially released, we should see these products begin to show up at retail.
Facebook
Twitter
RSS
36 Comments
View All Comments
JarredWalton - Saturday, April 30, 2005 - link
KHysiek - part of the bonus of the Hybrid HDDs is that apparently Longhorn will be a lot more intelligent on memory management. (I'm keeping my fingers crossed.) XP is certainly better than NT4 or the 9x world, but it's still not perfect. Part of the problem is that RAM isn't always returned to the OS when it's deallocated.Case in point: Working on one of these WinHEC articles, I opened about 40 images in Photoshop. Having 1GB of RAM, things got a little sluggish after about half the images were open, but it still worked. (I wasn't dealing with layers or anything like that.) After I finished editing/cleaning each image, I saved it and closed it.
Once I was done, total memory used had dropped from around 2 GB max down to 600 MB. Oddly, Photoshop was showing only 60 MB of RAM in use. I exited PS and suddenly 400 MB of RAM freed up. Who was to blame: Adobe or MS? I don't know for sure. Either way, I hope MS can help eliminate such occurrences.
KHysiek - Friday, April 29, 2005 - link
PS. In this case making hybrid hard drives with just 128MB of cache is laughable. Windows massive memory swapping will ruin cache effectiveness quickly.KHysiek - Friday, April 29, 2005 - link
Windows memory management is one of the worst moments in history of software development. It made all windows software bad in terms of managing memory and overall performance of OS. You actually need at least 2x of memory neede by applications to work flawlessly. I see that saga continues.CSMR - Thursday, April 28, 2005 - link
A good article!Regarding the "historical" question:
Strictly speaking, if you say "an historical" you should not pronounce the h, but many people use "an historical" and pronounce the h regardless.
Pete - Thursday, April 28, 2005 - link
That's about how I reasoned it, Jarred. The fisherman waits with (a?)bated breath, while the fish dangles from baited hook. Poor bastard(s).'Course, when I went fishing as a kid, I usually ended up bothering the tree frogs more than the fish. :)
patrick0 - Wednesday, April 27, 2005 - link
If Microsoft manages graphics memory, it will sure be a lot easier to read this memory. This can make it easier to use the GPU as a co-processor to do non-graphics tasks. Now I could manage image-processing, but this doesn't sound like a no-graphcs task, does it? Anyways, it is a cpu task. Neither ATI nor nVidia has made it easy so far to use the GPU as co-processor. So I think ms managing this memory will be an improvement.JarredWalton - Wednesday, April 27, 2005 - link
Haven't you ever been fishing, Pete? There you sit, with a baited hook waiting for a fish to bite. It's a very tense, anxious time. That's what baited breath means.... Or something. LOL. I never really thought about what "bated breath" actually meant. Suspended breath? Yeah, sure... whatever. :)Pete - Wednesday, April 27, 2005 - link
Good read so far, Derek and Jarred. Just wanted to note one mistake at the bottom of page three: bated, not baited, breath.Unless, of course, they ordered their pie with anchovies....
Calin - Wednesday, April 27, 2005 - link
"that Itanium is not dead and it's not going anywhere"I would say "that Itanium is not dead but it's not going anywhere"
JarredWalton - Tuesday, April 26, 2005 - link
26 - Either way, we're still talking about a factor of 2. 1+ billion vs. 2+ billion DIMMs isn't really important in the grand scheme of things. :)23 - As far as the "long long" vs "long", I'm not entirely sure what you're talking about. AMD initially made their default integer size - even in 64-bit mode - a 32-bit integer (I think). Very few applications really need 64-bit integers, plus fetching a 64-bit int from RAM requires twice as much bandwidth as a 32-bit int. That's part one of my thoughts.
Part 2 is that MS may have done this for code compatibility. While in 99% of cases, an application really wouldn't care if the 32-bit integers suddenly became 64-bit integers, that's still a potential problem. Making the user explicitly request 64-bit integers gets around this problem. Things are backwards compatible.
Anyway, none of that is official, and I'm only partly sure I understand what you're asking in the first place. If you've got some links for us to check out, we can look into it further.