> Man-in-the-middle attacks are very complex and > not likely to be pulled off "in the wild".
No. MITM attacks are very easy to pull off with the right tools. You can easily take control of any TCP connection made by any other machine on the same Ethernet. Even if the network is fully switched you can use ARP poisoning to get around that.
Of course, if you manage to take control of a DNS server then you can easily do MITM attacks against many machines. Heck, do you trust the employees of your ISP with your banking information?
Everyone knows usparc is slow. Let's see how Itanium stacks up against a chip that's actually fast, like a Power4 or even a Hammer or Xeon. I don't see anything about them in Intel's press release.
It's about CPU price/performance, and for that, you need volume. IBM's Power chips are fine but they don't ship in volume (nor do they need to; the price of the CPU doesn't matter so much in that market). On the other hand AMD will ship a lot of chips.
Oh, I'm also assuming that we're talking about real server workloads (integer heavy, unpredictable access patterns), not some easy regular floating-point workload like SPECfp.
(Of course Hammer will rip Itanium to shreds running 32-bit x86 code. That's no contest at all.)
I'm extrapolating from the fact that Intel and HP don't dare to benchmark Itanium 2 against a current Athlon or Xeon, and I'm assuming that Hammer in 64-bit mode will be significantly faster than either of those.
> that's cause it can take up to 4MB of level 3 > cache on die
That's nice. Yet with all that cache, it's still slower.
(In fact they need all that cache because the cache miss penalty in Itanium is absolutely horrific, since it can't reorder instructions in hardware. There's the real waste of die size.)
The Pentium Pro ran 32-bit x86 code very fast, much faster than its predecessor the Pentium. Not such a big disaster as the Itanium, which wasn't a clear improvement in any dimension over its competition, except for hype.
The Itanium 2 is faster than Itanium but not by much more than you'd expect from Moore's law. So just how many generations will it be before we're allowed to judge IA64?
So, Intel didn't try to make a competitive chip? "Yeah right". If so I hope they gave a refund to anyone who tried to use it in a real system.
Itanium 2 is coming out now. Performance is a bit better but only slightly ahead of the Moore's law curve. Intel and HP don't dare compare it to a high-end Xeon, let alone a Hammer. Will Itanium 2, too, be written off as a "developer's chip"? Just how many generations are there going to be before it's ready to use?
> > more expensive > volume and aimed at different markets
That, plus the massive die, explains why it's expensive, but they don't change the fact that it's very expensive.
> if there *had* to be a choice between x86 and > ia64, I would think ia64 would be better
IA64 cleaner than x86? Maybe, if you rip out its own x86 support a few generations down the line. But faster? No. If your shiny new architecture doesn't provide a major performance boost over the old architecture, I can't call it better.
> using SSE2 instead of x87 is a decent compromise
In fact, it's significantly faster. Latest gcc has a switch to do this.
BTW, you're ignoring the fact that x86-64 is a significant improvement over x86, not just a 64-bit stretch. 8 new general purpose registers, 8 new SSE2 registers. It starts to look a lot like a real architecture, yet compiling to it is very little different from compiling to x86.
Regarding 2), one huge problem for IA64 is that, being so hard to compile to, JIT compilers are very slow and that really hurts the performance of virtual machines.
Please port OSX to Hammer and stick AMD chips in your Macs. You can save face by pretending it's not x86 (even though it will make customers happy when they can run WINE and VMWare on OSX). Your programmers will enjoy the relatively clean 64-bit mode. You won't face the risk of being the sole customer of your CPU vendor. Best of all, you will be able to make cheap Macs with competitive performance. I promise to buy one if you do it.
> I do think the AMD architecture looks like a > piece of shit.
You obviously don't know anything about it. In 64-bit mode Hammer gives you 16 general purpose registers (RAX,..., RDI, R8,..., R15) and 16 floating point registers (you are encouraged to do all FP using SSE2 and forget about the x87 crap). The GP registers are not overlaid (e.g., the 8-bit instructions access the bottom 8 bits of each register; AH,BH,CH,DH are not available). 64-bit mode is cleaner than x86 in other ways too.
> the actual platform is beautifully elegant
Unfortunately you can't run programs on the "actual platform". You can only run programs on the slow and expensive Itanium and Itanium 2.
Compare the size of the Itanium 2 die with the dies for AMD's Hammer chips. You will soon see who has the real muscle chip. (Hint: Itanium 2 will be FOUR TIMES larger than AMD's Clawhammer --- and it will still be slower.)
Getting rid of cruft is a good move if it lets you get higher performance. But IA64 destroyed that potential performance gain with several idiotic design decisions. That shiny new no-legacy instruction set may give you a warm feeling but that's all you get.
Now, Alpha was a nice architecture. If Intel had invested in Alpha the way they've invested in IA64, they would have left every other CPU in the dust. Too bad.
> look at the pure technology aspect of it, IA64 is > a better architecture
No. There are better, cleaner architectures than x86 --- MIPS, Alpha, PPC. But IA64 is not one of them. Static scheduling simply doesn't give you the performance, not with today's compilers, not with tomorrow's, probably not ever. Some things really are done better in hardware.
Starting over is only "right" if you replace the status quo with something better. Instead, Intel replaced it with something *worse*. If Itanium performed, geeks would be all over it. It doesn't.
If your code is already 64-bit clean, you can probably just recompile it and it will run on Hammer's 64-bit mode, probably faster than it was running in 32-bit mode.
So here's an upgrade path: first you buy your Hammer box and run your 32-bit Linux on it, just treating it as a faster Athlon. Then you upgrade your Linux to a 64-bit kernel, getting a speedup, but you can still run your 32-bit user processes. For the apps you have source for, you can recompile and run faster in 64-bit mode. Eventually people will start shipping Hammer binaries.
One interesting question is what the speed advantage (or not) will be for 64bit mode. Increased cache footprint of 64bit pointers vs 64bit math, extra registers and PC-relative addressing. Hard to call.
> Linux just doesn't have any good, free > software, and that's what's needed to run a > desktop.
OpenOffice.
I use it. It's good. It has features that Office97 didn't have (last MSOffice I used) --- styles for graphic objects, a standalone drawing tool, decent snap in the drawing tool, intelligent scaling of groups of graphic objects, copy and paste in the spreadsheet that actually works right, bibliography support in the word processor, non-sucking equation editor. Probably a lot more, I haven't used it a whole lot yet. Hasn't crashed yet. Handles simple Word documents OK. Haven't tried complex ones yet.
Slashdot Mirror
> Man-in-the-middle attacks are very complex and
> not likely to be pulled off "in the wild".
No. MITM attacks are very easy to pull off with the right tools. You can easily take control of any TCP connection made by any other machine on the same Ethernet. Even if the network is fully switched you can use ARP poisoning to get around that.
Of course, if you manage to take control of a DNS server then you can easily do MITM attacks against many machines. Heck, do you trust the employees of your ISP with your banking information?
Everyone knows usparc is slow. Let's see how Itanium stacks up against a chip that's actually fast, like a Power4 or even a Hammer or Xeon. I don't see anything about them in Intel's press release.
That's partly because so much of the Mac OS had been written in assembly. That's no longer true for any important OS.
I was referring specifically to Itanium.
It's about CPU price/performance, and for that, you need volume. IBM's Power chips are fine but they don't ship in volume (nor do they need to; the price of the CPU doesn't matter so much in that market). On the other hand AMD will ship a lot of chips.
All modern x86 implementations are RISC inside. RISC really doesn't mean anything any more.
I agree that Alpha was very cool and it's very sad to see it killed.
Oh, I'm also assuming that we're talking about real server workloads (integer heavy, unpredictable access patterns), not some easy regular floating-point workload like SPECfp.
Both running optimized native code.
(Of course Hammer will rip Itanium to shreds running 32-bit x86 code. That's no contest at all.)
I'm extrapolating from the fact that Intel and HP don't dare to benchmark Itanium 2 against a current Athlon or Xeon, and I'm assuming that Hammer in 64-bit mode will be significantly faster than either of those.
> that's cause it can take up to 4MB of level 3
> cache on die
That's nice. Yet with all that cache, it's still slower.
(In fact they need all that cache because the cache miss penalty in Itanium is absolutely horrific, since it can't reorder instructions in hardware. There's the real waste of die size.)
The Pentium Pro ran 32-bit x86 code very fast, much faster than its predecessor the Pentium. Not such a big disaster as the Itanium, which wasn't a clear improvement in any dimension over its competition, except for hype.
The Itanium 2 is faster than Itanium but not by much more than you'd expect from Moore's law. So just how many generations will it be before we're allowed to judge IA64?
So, Intel didn't try to make a competitive chip? "Yeah right". If so I hope they gave a refund to anyone who tried to use it in a real system.
Itanium 2 is coming out now. Performance is a bit better but only slightly ahead of the Moore's law curve. Intel and HP don't dare compare it to a high-end Xeon, let alone a Hammer. Will Itanium 2, too, be written off as a "developer's chip"? Just how many generations are there going to be before it's ready to use?
> > more expensive
> volume and aimed at different markets
That, plus the massive die, explains why it's expensive, but they don't change the fact that it's very expensive.
Yeah. For some reason server vendors are insisting on going with the more expensive, slower, hotter, non-x86-compatible CPU.
> if there *had* to be a choice between x86 and
> ia64, I would think ia64 would be better
IA64 cleaner than x86? Maybe, if you rip out its own x86 support a few generations down the line. But faster? No. If your shiny new architecture doesn't provide a major performance boost over the old architecture, I can't call it better.
> using SSE2 instead of x87 is a decent compromise
In fact, it's significantly faster. Latest gcc has a switch to do this.
BTW, you're ignoring the fact that x86-64 is a significant improvement over x86, not just a 64-bit stretch. 8 new general purpose registers, 8 new SSE2 registers. It starts to look a lot like a real architecture, yet compiling to it is very little different from compiling to x86.
Regarding 2), one huge problem for IA64 is that, being so hard to compile to, JIT compilers are very slow and that really hurts the performance of virtual machines.
Please port OSX to Hammer and stick AMD chips in your Macs. You can save face by pretending it's not x86 (even though it will make customers happy when they can run WINE and VMWare on OSX). Your programmers will enjoy the relatively clean 64-bit mode. You won't face the risk of being the sole customer of your CPU vendor. Best of all, you will be able to make cheap Macs with competitive performance. I promise to buy one if you do it.
Sincerely,
Robert O'Callahan
> I do think the AMD architecture looks like a
..., RDI, R8, ..., R15) and 16 floating point registers (you are encouraged to do all FP using SSE2 and forget about the x87 crap). The GP registers are not overlaid (e.g., the 8-bit instructions access the bottom 8 bits of each register; AH,BH,CH,DH are not available). 64-bit mode is cleaner than x86 in other ways too.
> piece of shit.
You obviously don't know anything about it. In 64-bit mode Hammer gives you 16 general purpose registers (RAX,
> the actual platform is beautifully elegant
Unfortunately you can't run programs on the "actual platform". You can only run programs on the slow and expensive Itanium and Itanium 2.
Compare the size of the Itanium 2 die with the dies for AMD's Hammer chips. You will soon see who has the real muscle chip. (Hint: Itanium 2 will be FOUR TIMES larger than AMD's Clawhammer --- and it will still be slower.)
Getting rid of cruft is a good move if it lets you get higher performance. But IA64 destroyed that potential performance gain with several idiotic design decisions. That shiny new no-legacy instruction set may give you a warm feeling but that's all you get.
Now, Alpha was a nice architecture. If Intel had invested in Alpha the way they've invested in IA64, they would have left every other CPU in the dust. Too bad.
> look at the pure technology aspect of it, IA64 is
> a better architecture
No. There are better, cleaner architectures than x86 --- MIPS, Alpha, PPC. But IA64 is not one of them. Static scheduling simply doesn't give you the performance, not with today's compilers, not with tomorrow's, probably not ever. Some things really are done better in hardware.
Have you compared the die size of Itanium vs a Xeon or Hammer? Itanium is much larger --- and slower --- and more expensive. Who's wasting die space?
But hey, at least it's pure!
Starting over is only "right" if you replace the status quo with something better. Instead, Intel replaced it with something *worse*. If Itanium performed, geeks would be all over it. It doesn't.
If your code is already 64-bit clean, you can probably just recompile it and it will run on Hammer's 64-bit mode, probably faster than it was running in 32-bit mode.
So here's an upgrade path: first you buy your Hammer box and run your 32-bit Linux on it, just treating it as a faster Athlon. Then you upgrade your Linux to a 64-bit kernel, getting a speedup, but you can still run your 32-bit user processes. For the apps you have source for, you can recompile and run faster in 64-bit mode. Eventually people will start shipping Hammer binaries.
One interesting question is what the speed advantage (or not) will be for 64bit mode. Increased cache footprint of 64bit pointers vs 64bit math, extra registers and PC-relative addressing. Hard to call.
I use Chase Online Banking with Mozilla ALL THE TIME. Works great.
> Linux just doesn't have any good, free
> software, and that's what's needed to run a
> desktop.
OpenOffice.
I use it. It's good. It has features that Office97 didn't have (last MSOffice I used) --- styles for graphic objects, a standalone drawing tool, decent snap in the drawing tool, intelligent scaling of groups of graphic objects, copy and paste in the spreadsheet that actually works right, bibliography support in the word processor, non-sucking equation editor. Probably a lot more, I haven't used it a whole lot yet. Hasn't crashed yet. Handles simple Word documents OK. Haven't tried complex ones yet.
Er, the Linux Flash plugin works fine.