Slashdot Mirror
Windows XP 64-Bit Customer Preview Program
MBCook writes "I just notice that Microsoft has a new Windows XP 64-Bit Customer Preview Program starting today (February 3rd). If you have a AMD Opteron or Athlon64, you can go to the download page to get your copy. It's a pre-release copy that will expire in 360 days (which probably means the final will be out by then). Now Intel just changed their 64-bit plans, and all of a sudden this appears. Speculate away!"
There were linux benchmarks which made /. recently, comparing the speed of 32-bit code and 64-bit code on the Opteron. 32-bit code ran measurably faster.
Mielipiteet omiani - Opinions personal, facts suspect.
Looks like someone needs to double-check that with Bill, then:
"Important: Windows XP 64-Bit Edition for 64-Bit Extended Systems is only compatible with 64-bit AMD Opteron- or Athlon 64-based computers. It cannot be successfully installed on 64-bit Intel Itanium-based systems."
I don't see any mention of an upcoming Intel it will run on, either.
I don't know what kind of crack I was on, but I suspect it was decaf.
Microsoft has had a 64-bit version of NT since almost the start. Also sizeof (int) == 4 on AMD64, same as IA32. Just the pointers are larger.
FLR
char is 8-bit, nearly by definition
short is 16-bit
int is 32-bit (DOS and Xenix are not modern)
long is 32-bit on all Windows OSes
long is the same size as a pointer Linux, BSD, Mac
void* is the natural size for the machine
long long is 64-bit
So 32-bit Windows and 32-bit UNIX have the
same sizes a each other. 64-bit systems differ,
because Windows sets sizeof(long)==4 and a
UNIX system sets sizeof(long)==sizeof(void*).
Go their benchmarks aslo show a marked improvement for Linux on 64bit.
Some tests scored about as much as a 20% improvement in performance, athough it's more realistic to expect a 8-10% average improvement across the board.
Of course windows likely will run slower since it's so optimized for the older 32bit platform.
Linux is just a much more mature platform for 64bit computers. I mean we've had Suse 64bit (aviable for free from Suse's ftp install stuff) for almost a year now.
So the processor spends less clock ticks doing 64-bit arithmatic for file offsets. Cryptography can benefit too. In particular the DH key agreement protocol and RSA public-private key cipher both require the use of "big numbers" (as in 1024 bits and up). And doing these operations 64-bits at a time rather than 32-bits can result in a performance impact. SSL session negotiation may be improved significantly, so that could be a boon to SSL webservers (not that IIS makes a great webserver).
Databases also need 64-bit numbers. Even low-end databases frequently have ID numbers that are 64-bits. For large databases the ability to compute page offsets (which are typically 64-bits) more efficiently can help.
And perhaps a subtle improvement may be in the handling of bitmaps. For example doing a bitwise operation 64-bits at a time will process more pixels than a 32-bit operation in the same amount of time.
But all of those things are really just noise for the special case of amd64. The x86 has always been a register-starved architecture. Going to 64-bit mode gives you 8 more general purpose registers. That alone may very well counter any of the performance loss due to 64-bit integers.
Lots of people on Slashdot have said 64-bit code is slower but haven't pointed out why. Probably the most important thing is cache coherency. 64-bit data structures are (surprise) larger than their 32-bit counterparts. That means that the effective rate of the cache is reduced. As an added bummer, address translation on 64-bit values is slower when there are more levels of translation.
Here: http://www.microsoft.com/windowsserver2003/64bit/e xtended/trial/default.mspx
Beta of course.
"TK-421, why aren't you at your post?"
It depends on what you're doing. I recently gave myself a 1.8 GHz Opteron system for Christmas and have been running some performance tests comparing 32 and 64 bit versions of the same applications.
Using LAME compiled from source with the default compiler options and "--alt-preset standard" encoding settings, it took 4m20s to encode an 11 minute MP3 with the 32 bit version and 2m51s to encode using the 64 bit version - about 30% faster. However, comparing some of the filters in a 64 bit GIMP 1.3.23 compiled from source with default settings to the GIMP 1.3.23 from the Debian distribution was quite different - running the "Diffraction Patterns" filter with default options on a 512x512 image took 11 seconds with the 32 bit version and 16 seconds with the 64 bit version - about 50% slower!
Of the other tests I ran, MP3 decoding with mpg123, bzip2 compression and AES encryption with OpenSSL were faster in 64 bit mode, and 3DES encryption with OpenSSL was faster in 32 bit mode. Of course, one of the advantages of having a hybrid 32/64 bit processor is that you can run whichever version is faster for a given task, onlike on the Itanium which until recently had only software emulation for 32 bit code.
I have also heard that 64 bit Windows on Opteron is slower at running 32 bit code than 32 bit Windows on Opteron, which has made me want to rerun my 32 bit tests under a 32 bit kernel. I also want to run the same tests on a Mac G5 and a Pentium 4 for comparison. Some other time...
On Win2K and higher, you can split out the file system browsing from the desktop instance of Explorer.exe. Run Explorer and select Tools->Folder Options->View->"Launch folder windows in a separate process". It uses a little more memory but prevents a slow device from slowing down the rest of the GUI.
You're right, though; Explorer blocks waiting for I/O way more often than it ought to. Most of the multithreading in GUIs is pretty good on Windows, so I'm not sure why Explorer tends to block on floppy I/O, network I/O, etc. Fortunately, it usually doesn't affect other running apps.