Re:When will Mozilla Innovate?
on
Mozilla 0.9.5
·
· Score: 2
Nice troll.
Here are a few more innovative open source projects for you:
-- SSH (yes, it was originally open source)
-- Original httpd (became Apache)
-- PGP
-- Perl
-- Python
-- BSD Unix
-- All of the software that formed the foundation of the Internet
> the web browser only became suitable for end
> users after Netscape tried to take it commercial
What does that have to do with innovation? The authors of innovations --- researchers, hackers, startups, skunk works projects --- are seldom lucky enough to be the ones to take their innovations mainstream. That doesn't make them any less innovative.
The case of Web browsers is clear: the (open source) Mosaic was a huge innovation, and proved the Web was suitable for end users. That led to the creation of Netscape, who capitalized on that innovation and took it mainstream. Copying someone else's ideas and then crushing their product with your competing implementation does not make you "innovative".
> expecting innovation from people who don't have
> a commercial interest in profiting from their
> innovations is unrealistic.
Many of the innovations that comprise your computing experience today originated from university researchers who had no interest in profiting from those innovations. To take your statement at face value would imply that worldwide academic CS research might as well not have happened. That is an extraordinary delusion.
Actually, Mozilla, Netscape 6.x, Konqueror, and other browsers provide a high degree of control over Javascript, including ways to turn off pop-ups, window resizing, etc. Just stop your ignorant ranting and google for "Mozilla configurable".
Kind of, if you learn about and work around all the horrible browser bugs that constitute "de facto" HTML.
> W3C specs even surpass the most obscure RFCs in
> their obtrusity.
That is true, but the specs for HTML and CSS (for example) are specifying something that is necessarily a lot more complicated than stuff usually dealt with in RFCs.
> W3C specs are usually playing catch-up with
> existing technologies.
In some places yes, in some places no. There lots of cool things in (say) CSS and SVG that haven't been widely implemented yet.
In any meaningful way Konqueror isn't complete, neither is Mozilla, and neither of them ever will be. They are both quite usable, however. Your slam against Mozilla "still being developed" completely misses the mark.
The "Chatzilla team" was just one guy (originally not at Netscape) who happened to feel like doing it. Should he have somehow been suppressed? You missed the mark again.
Netscape's code was there before Netscape opened their code, too:-).
Also, unless Trolltech was persuaded to open source Qt for Windows and the Mac (fat chance, in fact I think Qt didn't run on the Mac at all until very recently), KHTML and the rest of the KDE world could not have been an option for Netscape.
> Pages in KHTML are first rendered, and THEN the
> stylesheet is rendered. It happens all at once in
> mozilla, which is wrong.
This is nonsensical. You're objecting to the fact that Mozilla shows you the correct display immediately?
Re:IA64 is the "heir apparent"
on
Itanium Update
·
· Score: 2
> I hope AMD will do a good job (as Intel has with
> P4 and Itanium) with helping the compiler writers
> get the most out of the chip.
It's just warmed-over x86 (and I mean that in a good way). Should be dead simple to modify an x86 compiler to target x86-64... and I read it's been done for gcc.
Re:Diminishing clock speeds
on
Itanium Update
·
· Score: 2
> When you buy a machine with $2000-$5000 CPUs, you
> tend to do real research on the performance of
> the system you are buying.
Which makes you wonder who would possibly buy an Itanium (especially for non-FPU-intensive servers where Intel's pushing it).
> If Intel is putting this product on the market,
> you can bet that they've fixed the compiler
> problem.
Your faith is touching. Another possibility is that the Itanium project was way behind schedule and that they had to ship something, anything, because their competitors and the rest of the industry were laughing at them. And so they shipped a CPU with the worst SpecInt number in the industry and even warned their customers that this was really just a development chip and 'real' hardware would have to wait for the next generation.
Groups of people often act much more stupidly than their constituent members. Intel has certainly made a few stupid moves over recent years:
-- IA64
-- Rambus
-- The home wireless network standard they pushed that got beaten by 802.11
> It's not "throwing it off" to the software guys
> because it's too difficult to implement. It is
> dramatically reducing the complexity of the
> pipeline, thereby increasing throughput by
> orders of magnitude
That's what they say, yet somehow decreasing the complexity of the pipeline hasn't produced many benefits in practice. The clock speed is low and the throughput (as measured by benchmarks) hasn't increased by orders of magnitude... or whatever improvements there have been are trashed by other problems in real-world applications.
> The scheduling hardware is only capable of
> looking a few instructions at a time to decide
> how to enhance ILP
This is quite false. Modern CPUs can have over 100 simultaneously executing instructions in flight. Furthermore modern CPUs take advantage of hardware such as branch predictors which records information on hundreds or thousands of instructions in order to make better execution decisions.
Profile-based optimization is a cool idea in theory but despite decades of research, it's seldom used. I suspect that one reason why is that (in C programs) reoptimization can reveal bugs in your code that were previously hidden (like an uninitialized variable that, by luck, always happened to be zero when the code was optimized a certain way). People don't like it when their system suddenly starts exhibiting new bugs that no-one else can reproduce.
> Having more data at compile time does not
> preclude having the same branch prediction and
> memory access data in hardware, as you imply.
> Itanium still has the ability to do branch
> prediction and handle memory latency the same as
> any modern processor.
No, it does not. In the quest for increased scalability they threw out "out of order" execution. All instructions must retire in order. This cripples its ability to tolerate unpredictable memory latencies.
It's already a reality. What Intel calls hyperthreading is coming in the next generation Alpha, is already shipping in POWER-based AS/400 systems, and is also in some specialized network processors.
> It is an interesting solution to the performance
> problem: Rather than just increase clock speed
> again, figure out the performance details at
> compile time and arrange the code to help the
> processor run it more efficiently.
That is neither interesting nor a solution. People (i.e. compiler writers) have been working on this for forty years with some (limited) success.
> the IA64 will require insanely complex
> optimizations, but that is just expanding on
> what compiler writers have been doing for years.
Just because the IA64 demands heroic compiler optimization to make up for its shortcomings doesn't mean that the ability to write such compilers will suddenly spring out of nowhere.
Compiler researchers haven't just been sitting on their butts for the last forty years.
> For example, if you have an if statement and the
> compiler can determine that 95% of the time the
> TRUE block will be executed, the code can be
> arranged so the branch prediction will choose
> the more frequent route and the pipeline penalty
> won't need to be paid as frequently.
This was a bad example. Dynamic branch predictors (such as you find in any modern fast CPU) do a great job in practice, better than any known static predictors.
> I disagree completely-- the programming manuals are FAR from marketing > hype, and the amount of documentation Intel has put out to the public so far > (and so far ahead of actually releasing any working silicon) shows their
> commitment to this architecture.
Intel actually kept the details of the design secret until very late in the game. But anyway, when I wrote "most of what you read" I meant "most of what you read IN THE PRESS". Not a lot of people look at the programming manuals.
> It's the COMPILER's responsibility to order the instructions such that a cache > miss shouldn't ever occur.
You should go to college and take a computer architecture class. In that class you will learn why this is fundamentally impossible. It's like a driver trying to predict which traffic lights he will have to stop at before he even leaves the house.
> One of the hallmarks of the design is in fact that instead of doing branch\
> prediction, EVERY branch is taken (fail or pass)
This is called predicated execution and Intel did not invent it. It does help avoid some of the penalties of mispredicted branches, but it is not universally applicable. In many situations you still have to use real branches. Furthermore branches are just one of the things a compiler has to predict correctly for in-order execution to work well.
> Compilers can (and should) do multiple passes to gather all of the
> information they need, then write the most optimized and streamlined
> binary they can.
Sure, that is the goal. But in practice there are severe limits to the amount of information a compiler can get at compile time. It's all about predicting the future, and that's always hard and often fundamentally impossible. BTW, I just spent seven years working on my PhD on whole-program static analysis, which is all about this subject:-).
I understand that clock speed isn't everything. I just bought an Athlon for that very reason. But a lot of the design choices in IA64 were made to *increase* the potential clock speed, so the fact that they weren't able to get the clock speed up anyway does not bode well for the architecture.
It will take time for the architecture to mature, but most of the bad decisions are already baked into the ISA (instruction set architecture). And of course AMD (and even the Pentium 4) aren't standing around waiting for IA64 to catch up.
Yes, you can use predicated execution to avoid the need for some branches. But that only works for a few branches (where the branched-over code is a short inline block), nowhere near "all possible branches".
PS, EPIC is Intel-marketing speak. What you are talking about was called "predicated execution" long before Intel 'invented' it.
Oh yeah, I probably don't need to point out that Intel is not marketing this chip as a Photoshop/games engine, which it might be good for. They're marketing it as a server chip, something it's spectacularly unsuited for.
OK, it is 64-bit which is slightly useful for some servers. But by the time 64-bit becomes really useful for many people, AMD will have Hammer/x86-64. That is a much better processor design, 64-bit, easy to port to (just a 64-bit stretch of x86 with a few sensible goodies like more registers), and for extra points will run x86 code incredibly fast! The last point ensures it will ship in volume and hence massively undercut any other 64-bit chip on price.
SpecFP benchmarks are relatively small programs, and it's not clear whether compilation techniques used on such programs scale up to larger applications. On the other hand, you are right that the Itanium will probably perform very well on small regular FP kernels like one finds in Photoshop. I would worry, however, about applications that have irregular control flow and/or irregular memory access patterns. Some 3D rendering tasks fall into this category.
The thing is that problems of the form "multiply matrices fast" are fairly easy to make fast. Vector units, reconfigurable units (including CPU-attached FPGAs and Stanford Imagine-style coprocessors), multiple CPU cores, lots of FP units, IRAM --- they all kick butt on these problems. Even with traditional designs, you'll notice that Athlon and Pentium 4 performance on these kinds of codes has been improving rapidly. Itanium's lead in these tasks can't be considered secure. And Amdahl's law suggests that terrible integer performance (very hard to fix having given up out-of-order execution) will strangle them even for FP-intensive applications, sooner or later.
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.
It's technically true that Itanium doesn't use emulation or translation to run x86 code... but they SHOULD have, because Itanium runs that code so slowly, it would probably have been faster if they'd used software emulation.
If you look at the Spec numbers, the benefits of the architecture are already pretty clear: runs great on nice predictable toy floating point benchmarks (SpecFP), complete DOG on everything else (SpecInt). Itanium's SpecInt numbers (400) are the worst of any recently released desktop CPU. Any Athlon or Pentium 4 will blow away Itanium's performance for non-FP stuff (which includes servers). And let's not even start talking about PRICE/performance.
They don't. The problem for Intel is that Itanium's performance on everything except floating-point intensive applications is TERRIBLE. Itanium's SpecInt number is well below 400 in any configuration, which is slower than any other PC-class CPU available today. Itanium is much better on SpecFP, although it remains to be seen how good it is on REAL floating point applications.
Itanium, and in fact the entire IA64 architecture, is a disaster. They bet the company on the wrong technology*. Intel will probably survive just because their marketing machine will persuade clueless corporate buyers to take the chip.
* The numbers don't lie: for most applications, all the explicit parallelism, speculative operations, compiler engineering and transistor count in the world can't compensate for not having a real speculating, out-of-order core.
Slashdot Mirror
Nice troll.
Here are a few more innovative open source projects for you:
-- SSH (yes, it was originally open source)
-- Original httpd (became Apache)
-- PGP
-- Perl
-- Python
-- BSD Unix
-- All of the software that formed the foundation of the Internet
> the web browser only became suitable for end
> users after Netscape tried to take it commercial
What does that have to do with innovation? The authors of innovations --- researchers, hackers, startups, skunk works projects --- are seldom lucky enough to be the ones to take their innovations mainstream. That doesn't make them any less innovative.
The case of Web browsers is clear: the (open source) Mosaic was a huge innovation, and proved the Web was suitable for end users. That led to the creation of Netscape, who capitalized on that innovation and took it mainstream. Copying someone else's ideas and then crushing their product with your competing implementation does not make you "innovative".
> expecting innovation from people who don't have
> a commercial interest in profiting from their
> innovations is unrealistic.
Many of the innovations that comprise your computing experience today originated from university researchers who had no interest in profiting from those innovations. To take your statement at face value would imply that worldwide academic CS research might as well not have happened. That is an extraordinary delusion.
Actually, Mozilla, Netscape 6.x, Konqueror, and other browsers provide a high degree of control over Javascript, including ways to turn off pop-ups, window resizing, etc. Just stop your ignorant ranting and google for "Mozilla configurable".
> What is out there works.
Kind of, if you learn about and work around all the horrible browser bugs that constitute "de facto" HTML.
> W3C specs even surpass the most obscure RFCs in
> their obtrusity.
That is true, but the specs for HTML and CSS (for example) are specifying something that is necessarily a lot more complicated than stuff usually dealt with in RFCs.
> W3C specs are usually playing catch-up with
> existing technologies.
In some places yes, in some places no. There lots of cool things in (say) CSS and SVG that haven't been widely implemented yet.
In any meaningful way Konqueror isn't complete, neither is Mozilla, and neither of them ever will be. They are both quite usable, however. Your slam against Mozilla "still being developed" completely misses the mark.
The "Chatzilla team" was just one guy (originally not at Netscape) who happened to feel like doing it. Should he have somehow been suppressed? You missed the mark again.
Netscape's code was there before Netscape opened their code, too :-).
Also, unless Trolltech was persuaded to open source Qt for Windows and the Mac (fat chance, in fact I think Qt didn't run on the Mac at all until very recently), KHTML and the rest of the KDE world could not have been an option for Netscape.
> Pages in KHTML are first rendered, and THEN the
> stylesheet is rendered. It happens all at once in
> mozilla, which is wrong.
This is nonsensical. You're objecting to the fact that Mozilla shows you the correct display immediately?
> I hope AMD will do a good job (as Intel has with
... and I read it's been done for gcc.
> P4 and Itanium) with helping the compiler writers
> get the most out of the chip.
It's just warmed-over x86 (and I mean that in a good way). Should be dead simple to modify an x86 compiler to target x86-64
> When you buy a machine with $2000-$5000 CPUs, you
> tend to do real research on the performance of
> the system you are buying.
Which makes you wonder who would possibly buy an Itanium (especially for non-FPU-intensive servers where Intel's pushing it).
> If Intel is putting this product on the market,
> you can bet that they've fixed the compiler
> problem.
Your faith is touching. Another possibility is that the Itanium project was way behind schedule and that they had to ship something, anything, because their competitors and the rest of the industry were laughing at them. And so they shipped a CPU with the worst SpecInt number in the industry and even warned their customers that this was really just a development chip and 'real' hardware would have to wait for the next generation.
Groups of people often act much more stupidly than their constituent members. Intel has certainly made a few stupid moves over recent years:
-- IA64
-- Rambus
-- The home wireless network standard they pushed that got beaten by 802.11
> It's not "throwing it off" to the software guys
... or whatever improvements there have been are trashed by other problems in real-world applications.
> because it's too difficult to implement. It is
> dramatically reducing the complexity of the
> pipeline, thereby increasing throughput by
> orders of magnitude
That's what they say, yet somehow decreasing the complexity of the pipeline hasn't produced many benefits in practice. The clock speed is low and the throughput (as measured by benchmarks) hasn't increased by orders of magnitude
> The scheduling hardware is only capable of
> looking a few instructions at a time to decide
> how to enhance ILP
This is quite false. Modern CPUs can have over 100 simultaneously executing instructions in flight. Furthermore modern CPUs take advantage of hardware such as branch predictors which records information on hundreds or thousands of instructions in order to make better execution decisions.
Profile-based optimization is a cool idea in theory but despite decades of research, it's seldom used. I suspect that one reason why is that (in C programs) reoptimization can reveal bugs in your code that were previously hidden (like an uninitialized variable that, by luck, always happened to be zero when the code was optimized a certain way). People don't like it when their system suddenly starts exhibiting new bugs that no-one else can reproduce.
> Having more data at compile time does not
> preclude having the same branch prediction and
> memory access data in hardware, as you imply.
> Itanium still has the ability to do branch
> prediction and handle memory latency the same as
> any modern processor.
No, it does not. In the quest for increased scalability they threw out "out of order" execution. All instructions must retire in order. This cripples its ability to tolerate unpredictable memory latencies.
It's already a reality. What Intel calls hyperthreading is coming in the next generation Alpha, is already shipping in POWER-based AS/400 systems, and is also in some specialized network processors.
> It is an interesting solution to the performance
> problem: Rather than just increase clock speed
> again, figure out the performance details at
> compile time and arrange the code to help the
> processor run it more efficiently.
That is neither interesting nor a solution. People (i.e. compiler writers) have been working on this for forty years with some (limited) success.
> the IA64 will require insanely complex
> optimizations, but that is just expanding on
> what compiler writers have been doing for years.
Just because the IA64 demands heroic compiler optimization to make up for its shortcomings doesn't mean that the ability to write such compilers will suddenly spring out of nowhere.
Compiler researchers haven't just been sitting on their butts for the last forty years.
> For example, if you have an if statement and the
> compiler can determine that 95% of the time the
> TRUE block will be executed, the code can be
> arranged so the branch prediction will choose
> the more frequent route and the pipeline penalty
> won't need to be paid as frequently.
This was a bad example. Dynamic branch predictors (such as you find in any modern fast CPU) do a great job in practice, better than any known static predictors.
> I disagree completely-- the programming manuals are FAR from marketing > hype, and the amount of documentation Intel has put out to the public so far > (and so far ahead of actually releasing any working silicon) shows their
:-).
> commitment to this architecture.
Intel actually kept the details of the design secret until very late in the game. But anyway, when I wrote "most of what you read" I meant "most of what you read IN THE PRESS". Not a lot of people look at the programming manuals.
> It's the COMPILER's responsibility to order the instructions such that a cache > miss shouldn't ever occur.
You should go to college and take a computer architecture class. In that class you will learn why this is fundamentally impossible. It's like a driver trying to predict which traffic lights he will have to stop at before he even leaves the house.
> One of the hallmarks of the design is in fact that instead of doing branch\
> prediction, EVERY branch is taken (fail or pass)
This is called predicated execution and Intel did not invent it. It does help avoid some of the penalties of mispredicted branches, but it is not universally applicable. In many situations you still have to use real branches. Furthermore branches are just one of the things a compiler has to predict correctly for in-order execution to work well.
> Compilers can (and should) do multiple passes to gather all of the
> information they need, then write the most optimized and streamlined
> binary they can.
Sure, that is the goal. But in practice there are severe limits to the amount of information a compiler can get at compile time. It's all about predicting the future, and that's always hard and often fundamentally impossible. BTW, I just spent seven years working on my PhD on whole-program static analysis, which is all about this subject
I understand that clock speed isn't everything. I just bought an Athlon for that very reason. But a lot of the design choices in IA64 were made to *increase* the potential clock speed, so the fact that they weren't able to get the clock speed up anyway does not bode well for the architecture.
It will take time for the architecture to mature, but most of the bad decisions are already baked into the ISA (instruction set architecture). And of course AMD (and even the Pentium 4) aren't standing around waiting for IA64 to catch up.
Yes, you can use predicated execution to avoid the need for some branches. But that only works for a few branches (where the branched-over code is a short inline block), nowhere near "all possible branches".
PS, EPIC is Intel-marketing speak. What you are talking about was called "predicated execution" long before Intel 'invented' it.
Oh yeah, I probably don't need to point out that Intel is not marketing this chip as a Photoshop/games engine, which it might be good for. They're marketing it as a server chip, something it's spectacularly unsuited for.
OK, it is 64-bit which is slightly useful for some servers. But by the time 64-bit becomes really useful for many people, AMD will have Hammer/x86-64. That is a much better processor design, 64-bit, easy to port to (just a 64-bit stretch of x86 with a few sensible goodies like more registers), and for extra points will run x86 code incredibly fast! The last point ensures it will ship in volume and hence massively undercut any other 64-bit chip on price.
SpecFP benchmarks are relatively small programs, and it's not clear whether compilation techniques used on such programs scale up to larger applications. On the other hand, you are right that the Itanium will probably perform very well on small regular FP kernels like one finds in Photoshop. I would worry, however, about applications that have irregular control flow and/or irregular memory access patterns. Some 3D rendering tasks fall into this category.
The thing is that problems of the form "multiply matrices fast" are fairly easy to make fast. Vector units, reconfigurable units (including CPU-attached FPGAs and Stanford Imagine-style coprocessors), multiple CPU cores, lots of FP units, IRAM --- they all kick butt on these problems. Even with traditional designs, you'll notice that Athlon and Pentium 4 performance on these kinds of codes has been improving rapidly. Itanium's lead in these tasks can't be considered secure. And Amdahl's law suggests that terrible integer performance (very hard to fix having given up out-of-order execution) will strangle them even for FP-intensive applications, sooner or later.
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.
I'm talking about Spec benchmarks compiled for IA64, if that's not clear. Done by Intel's engineers using their own compiler.
It's technically true that Itanium doesn't use emulation or translation to run x86 code ... but they SHOULD have, because Itanium runs that code so slowly, it would probably have been faster if they'd used software emulation.
If you look at the Spec numbers, the benefits of the architecture are already pretty clear: runs great on nice predictable toy floating point benchmarks (SpecFP), complete DOG on everything else (SpecInt). Itanium's SpecInt numbers (400) are the worst of any recently released desktop CPU. Any Athlon or Pentium 4 will blow away Itanium's performance for non-FP stuff (which includes servers). And let's not even start talking about PRICE/performance.
Alpha running in 32-bit mode is NOT the same as x86. FX32 translated x86 binaries into 32-bit Alpha binaries.
They don't. The problem for Intel is that Itanium's performance on everything except floating-point intensive applications is TERRIBLE. Itanium's SpecInt number is well below 400 in any configuration, which is slower than any other PC-class CPU available today. Itanium is much better on SpecFP, although it remains to be seen how good it is on REAL floating point applications.
Itanium, and in fact the entire IA64 architecture, is a disaster. They bet the company on the wrong technology*. Intel will probably survive just because their marketing machine will persuade clueless corporate buyers to take the chip.
* The numbers don't lie: for most applications, all the explicit parallelism, speculative operations, compiler engineering and transistor count in the world can't compensate for not having a real speculating, out-of-order core.
NT drove Alpha in 32-bit mode. So that doesn't count.b
NT on Alpha does not use 64bit features. It drives the Alpha in 32bit mode only.
MS wasn't happy when Compaq pulled the plug on Alpha/NT, but with this level of support from MS, it's easy to see why Compaq made the move.