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
In a 32-bit machine, each fetch from memory retrieves 4 bytes. Even if you only use one, the other three are cached. So, when reading sequentially, you get four bytes for the price of one.
In a 64-bit machine, each fetch returns 8 bytes, so you 8 for the price of one.
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*).
You can see official AMD benchmark results of various programs running on Windows XP 32-bit edition vs. Windows XP 64-bit edition beginning on page 36 of this PDF. The results have three columns: time in seconds on WinXP 32-bit w/ 32-bit executable, time in seconds on WinXP 64-bit with 32-bit executable, and time in seconds on WinXP 64-bit with 64-bit executable.
Erlang.org: wow
The big issue for me are the cases where the stupid machine just locks up and does fuck all for 20 seconds or so. CPU meter shows 3% utilization, no disk activity. What is the stupid thing doing?
Same goes for UNIX systems, its not the processing thats the issues, or even the legitimate I/O delays, its the cretinous delays built into broken device drivers and applications.
On Windows, the process locking up everything here most often seems to be explorer.exe. I've found that going into task manager, killing and running it from there (since you just lost your start menu with the run command) will restore the machine to normal.
Using that little trick every time it starts acting stupid, my windows box is running quite nicely for weeks. Doing it doesn't interrupt any of the applications or services running, the kernel is handling that just fine. Quite silly really.
Kjella
Live today, because you never know what tomorrow brings
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?"
Actually, there are a few tasks that benefit from 64-bit code: Encryption, Databases, and file-systems.
Don't forget media encoding.
Ripping that DVD will be a LOT faster with a 64-bit optimized encoder.
I don't read or respond to AC posts
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...
> Linux is just a much more mature platform for 64bit computers.
Much more mature? Perhaps you were unaware of Windows XP 64-bit Edition? Sure, it only runs on Itanium, but do you not honestly think that for Microsoft to have released it in early 2003 that they would probably have been working on it and testing it for at least a couple years prior to that?
Linux was ported to the alpha about a decade ago (this was still a 32-bit kernel, just like NT on alpha AFAIK), sometime in 1996 a real 64-bit version was released (2.0). Despite MS market share, I'd guess that there are a lot more 64-bit linux installations around than 64-bit windows.
Another important things is that since most linux software is open source and designed for portability from the start, a 64-bit kernel with a 64-bit userspace is as easy as a recompile (well, almost). MS has a big disadvantage here, because they need to wait for their ISV:s to produce 64-bit programs as well as drivers.