Slashdot Mirror
Windows Reaches 64-Bits, For OEMs
thatrez writes: "Microsoft 's Windows Advanced Server, Limited Edition, is now
available for computers based on Intel's 64-bit Itanium chip. The
Itanium chip supports greater amounts of system memory and offers
stronger floating-point, or mathematical, capabilities than current
32-bit desktop processors. The extra memory support and the
floating-point capabilities increase the performance of Web hosting,
data warehousing and other applications." Now available in this case means that certain OEMs will soon be selling systems loaded with 64-bit Advanced Server, and later other manufacturers will join in. 64-bit versions of XP are expected sometime next year as well.
This release will not work on AMD SledgeHammer. This one is particularly for the IA64 instruction set, not IA32 or x86-64. The standard Windows 2000 and Windows XP will work just fine on SledgeHammer, if you want to waste all that AMD goodness on a 32-bit Microsoft OS.
Microsoft is also considering an x86-64 port of Windows XP, but they have not announced their decision yet.
Even Slashdot wants to hide some things
though the alpha was a 64bit processory, the wnt port was still 32bit.
All you would get for your trouble is a crippling licence fee (courtesy of MS), a dearth of 64-bit applications & drivers, slower 32-bit execution and double the memory and disk requirements. These are hardly compelling reasons to "upgrade".
Let's look at the numbers. Last month on MSN.support.com, there were 453,234,234 bug reports. During the same time period, there were zero bug reports for Linux on the same forum. It's obvious to anyone that can do simple troll-matic that Windows is dying.
My question is how much of an advantage does software not specifically compiled for 64bit gain?
None. In fact, they get slower. Check out this article (link pilfered from poster above).
MS's (correct) mantra about it being all about the apps is gonna bite 'em in the ass on this one. Until SQL server, IIS, and the rest of the back office stuff is also native 64 bit (along with all thier dev tools) it ain't gonna be anything but an expensive, slow box.
(killer NG = microsoft.public.windowsxp.beta.help-and-support - you guys ROCK!)
Win XP is not perfect, and not for everybody, but outpaces anything M$FT or its competitors have come up with to date. Throw 64-bit support into the mix - assuming it works ;) and you've got a real class-act. Do yourself a favor and at least give it a try and see if you don't like it, too.
The benchmarks you're referring to (the ones that placed an Itanium at a slower speed than Pentium III's or Pentium 4's) were running 32-bit code, not native 64-bit code. Intel's Itanium processor family (IA-64) are backwards compatible with their Pentium family (IA-32).. in other words, it can execute the code without any on-the-fly emulation or translation.
The problem with this is that apperently Itanium's implementation of the IA-32 execution unit is shoddy (and thus, slow). However, code written to the native IA-64 spec (which is what this release of Windows 2000 Advanced Server is) should perform MUCH faster.
Besides, an important thing to remember about Quake III is that it's not the CPU that matters really, it's the graphics card.
Once more IA-64 binaries are released I think the benefits of the architecture will become clearer. (Hopefully! I'm not saying Intel can do no wrong, but basing your assessment of their processor on it's EMULATION (basically) of IA-32 is totally off-base-- IA-64 is it's native, preferred mode. IA-32 is just there to make transitioning easier.)
All I know about Bush is I had a good job when Clinton was president.
What are you talking about? Windows is no less than the *third* OS out the door. HP-UX has been out on Itanum for several months, and Linux works just fine as well (I am currently logged into one of each).
I don't know what vendors who sell HP-UX based software are doing right now, but Debian GNU/Linux has ported a very large number of packages to IA-64 and is planning on releasing it at some point not to far from now. (you can install it from Testing and Unstable already).
Major developers know what's out there, it's only you who is in the dark.
(may or may not be the opinions of my employer, I don't speak for them)
Would you do it for some scoobie crack?
My understanding is that everything in the core OS has been recompiled as a 64-bit binary, this would include the kernel (obviously), shell (including support DLL's and EXPLORER.EXE, for example), and most likely server components such as IIS (this is my speculation here, if IIS is still a 32-bit binary, someone speak up, because that really WOULD make the entire release almost pointless).
But I've read on MSDN and elsewhere that Explorer and other basic (ie: integrated) components of Windows 2000 were ported to IA-64 for this release.
All I know about Bush is I had a good job when Clinton was president.
The big bonus is that you can access a lot more memory. A lot of databases are larger than 2GB, which means they cannot be loaded into RAM on a 32-bit system (well, 3GB if you play some tricks). Since disk access is on the order of 1000 times slower than RAM access, if you can load your 12GB database into RAM and query it from there, you should see significant performance improvements.
For editing WordPerfect documents, it's probably not that significant. :)
Hell yes! Microsoft may have an army of mercenary programmers, but that's only in the States.
The Open Source community is world-wide and outnumbers the microserfs by several orders of magnitude both in quantity and quality. Not to mention the morale. There's a whole world of a difference between a paid, "I'm doing it only for the big bucks" programmer and a dedicated Open Source warrior.
The Velocity Engine can work on up to 128 bits at a time. What it's actually doing is SIMD work on chunks of data (4 chunks of 32-bit data). A lot like MMX instructions on Pentiums.
That's what we asked when we went to 32 bits. The answer is, you can address more memory, and have more memory bandwidth. Note many grapics cards these days have 128 bit architectures.
Real world benifits? Depends on the Application and OS. Usually Databases and big imaging applications see benifits first. And remember, many machines have been 64 bits for years, Intel and Microsoft are late to this party.
I understand that when the AS400 (basically database machine) line went from 48 bit CISC to 64 bit RISC chips several years back there were significant benifits in uptime, of all things. Seems the AS400/iSeries Single Level Store memory & storage management scheme requres a unique id for each object in memory. Bigger CPU words meant more (2 to the 12th?) id numbers were available. So, reboots to reset the counter for temporary objects were now needed only (all other things equal which they weren't) 1/2^12 as often. That's a big benifit for big iron.
I've read the manuals, and I've talked to a number of CPU architects and compiler writers. They have no trouble believing how hard it is to get good performance out of the IA64 architecture.
The fundamental problem is that IA64 is an in-order design. Your code hums along, does a load from memory, misses in the cache --- and everything stops until that value comes in. In an out-of-order machine (every other high performance CPU since the Pentium Pro in 1995), while it's waiting for that value to come in from memory, it will be executing other instructions that technically are supposed to happen AFTER the load, but don't actually depend on its value.
The IA64 was supposed to get around this problem by providing speculative loads with alias masks and other tricks so the compiler could hoist the load and perform it super-early, long before the value was needed, so any delay due to cache miss would not impact execution. Intel's big bet was that this would make out-of-order execution unnecessary. They lost the bet, for two reasons: 1) real programs (as opposed to toy benchmarks) are too unpredictable. There just isn't enough information available at compile time to decide what can and should be loaded early, which order instructions should go in, etc. The decisions have to be made at run time by the CPU itself. 2) The cost of out-of-order execution was overestimated. In the last five years we've been able to build really big horrible superscalar out of order cores with really fast cycle times. OTOH, the Itanium's supposedly "simpler" core has a crap clock speed. Go figure.
95% of what you read about the IA64 architecture is marketing hype. Just because it's "new" and "different" doesn't make it better. In fact, on the numbers, it appears to be worse in most cases.