Most active commenters
  • kjs3(5)
  • p_l(3)

←back to thread

331 points giuliomagnifico | 16 comments | | HN request time: 0.755s | source | bottom
Show context
bigstrat2003 ◴[] No.45377613[source]
I remember at the time thinking it was really silly for Intel to release a 64-bit processor that broke compatibility, and was very glad AMD kept it. Years later I learned about kernel writing, and I now get why Intel tried to break with the old - the compatibility hacks piled up on x86 are truly awful. But ultimately, customers don't care about that, they just want their stuff to run.
replies(5): >>45377925 #>>45379301 #>>45380247 #>>45385323 #>>45386390 #
1. drewg123 ◴[] No.45380247[source]
It didn't help that Itanium was late, slow, and Intel/HP marketing used Itanium to kill off the various RISC CPUs, each of which had very loyal fans. This pissed off a lot of techies at the time.

I was a HUGE DEC Alpha fanboy at the time (even helped port FreeBSD to DEC Alpha), so I hated Itanium with a passion. I'm sure people like me who were 64-bit MIPS and PA-RISC fanboys and fangrirls also existed, and also lobbied against adoption of itanic where they could.

I remember when amd64 appeared, and it just made so much sense.

replies(3): >>45380466 #>>45381576 #>>45381749 #
2. EasyMark ◴[] No.45380466[source]
This, if intel's compilers and architecture had been stellar and provided a x5 or x10 improvement it would have caught on. However no one in IT was fool enough to switch architectures over a 30-50% performance improvement that require switching hardware, compilers, and software and try to sell it to their bosses.
replies(2): >>45381389 #>>45381907 #
3. axiolite ◴[] No.45381389[source]
> if intel's compilers and architecture had been stellar and provided a x5 or x10 improvement it would have caught on.

That sounds like DEC Alpha to me, yet Alpha didn't take over the world. "Proprietary architecture" is a bad word, not something you want to base your future on. Without the Intel/AMD competition, x86 wouldn't have dominated for all these years.

replies(1): >>45388196 #
4. antod ◴[] No.45381576[source]
Wasn't much of the Athlon designed by laid-off DEC Alpha engineers that AMD snapped up? Makes sense that AMD64 makes sense to an Alpha fanboy :)
replies(1): >>45381795 #
5. kjs3 ◴[] No.45381749[source]
PA-RISC fanboys and fangrirls

Itanic wasn't exactly HP-PA v.3, but it was a kissing cousin. Most of the HP shops I worked with believed the rhetoric it was going to be a straightforward if not completely painless upgrade from the PA-8x00 gear they were currently using.

Not so much.

The MIPS 10k line on the other hand...sigh...what might have been.

I remember when amd64 appeared, and it just made so much sense.

And you were right.

replies(2): >>45382385 #>>45385448 #
6. kjs3 ◴[] No.45381795[source]
Yeah...look up Jim Keller. And AMD basically recycled the later Alpha system bus as the K7 bus to the extent there was very short lived buzz about having machines that could be either x86-64 or Alpha.
7. kjs3 ◴[] No.45381907[source]
I dunno if you meant it this way, but I've heard waaaay too many people say things like this meaning "if Intel compiler guys didn't suck...". They didn't, and don't (Intel C and Fortran compilers are to this day excellent). The simple fact is noone has proven yet that anyone can write compilers good enough to give VLIW overwhelmingly compelling performance outside of niche uses (DSPs, for example). I remember the Multiflow and Cydrome guys giving the same "it's the compiler, stupid" spiel in the mid-80s, and the story hasn't changed much except the details. We bought a Multiflow Trace...it was really nice, for certain problems, but not order-of-magnatude-faster, change-the-world nice, which was how it was sold.

Now, to be clear, a lot of these folks and their ideas moved the state-of-the-art in compilers massively ahead, and are a big reason compilers are so good now. Really, really smart people worked this problem.

replies(2): >>45385436 #>>45388333 #
8. hawflakes ◴[] No.45382385[source]
Did the PA-RISC shops run their old PA-RISC code with the Aries emulator?

One of the selling points for HP users was running old code via dynamic translation and x86 would just work on the hardware directly.

Another fun fact I remember from working at HP was that later PA-RISC chips were fabbed at Intel because the HP-Intel agreement had Intel fabbing a certain amount of chips and since Merced was running behind... Intel-fabbed PA-RISC chips!

https://community.hpe.com/t5/operating-system-hp-ux/parisc-p...

replies(1): >>45425900 #
9. p_l ◴[] No.45385436{3}[source]
My understanding is that Itanium was also stupidly strict on VLIW, making compilers even harder. Microsoft blogs had examples of some really funky bugs caused by it, too.

In comparison, Multiflow was not so bad.

10. p_l ◴[] No.45385448[source]
First generations of Itanium used same bus and support chips as last HP-PA, thus way simpler migration path involved - some servers even allowed to swap HP-PA for Itanium without replacing most of the server (similar as with rare VAX 7000 and VAX 10000, which could have CPU boards replaced with Alpha ones)
replies(1): >>45426176 #
11. cameldrv ◴[] No.45388196{3}[source]
The DEC Alpha actually did provide very good performance, and you could even run Windows NT on it. As far as I can tell, the biggest problem was just that Alpha systems were very expensive, and so they had a limited customer base. There were some quirks, but the main thing was just that you'd be paying $2000 for a PC and $10,000 for an Alpha based system, and most people didn't need the performance that badly.
replies(1): >>45398448 #
12. acdha ◴[] No.45388333{3}[source]
I think Itanium would have had a better chance if Intel had made their compilers and optimized libraries free, but your larger point is really important: Intel’s performance numbers for the Itanium seem to have been broadly extrapolated from a few very FPU-intensive benchmarks and I don’t think it was ever realistic to expect anything like that level of performance for branchy business logic or to decisively change the price-performance ratio to become compelling. I worked with some scientists who did have a ton of floating point-heavy code, so they were definitely interested but their code also had a lot of non-linear memory access and the Itanium never managed a performance lead at all, much less one big enough that it wouldn’t have been cheaper and faster to buy 2-4 other servers for each Itanium box. In contrast, when AMD released the Opteron it decisively took the lead in absolute performance as well as price/performance and so we bought them by the rack.
13. axiolite ◴[] No.45398448{4}[source]
> Alpha systems were very expensive, and so they had a limited customer base.

That's the usual chicken & egg problem... If they sold more units, the prices would have come down. But people weren't buying many, because the prices were high.

Itanium, like Alpha, or any other alternative architecture, would also have trouble and get stuck in that circle. x86-64, being a very inexpensive add-on to x86, managed to avoid that.

14. kjs3 ◴[] No.45425900{3}[source]
I didn't personally know of anyone using Aries in anger (production), but it looked like a neat trick.
15. kjs3 ◴[] No.45426176{3}[source]
Yes, that was an interesting option, though not nearly as cheap on a lifecycle basis as one might hope. I don't know of anyone who upgraded this way, but obviously someone did. My clients who converted ran the HP-PA machines, brought in Itaniums, migrated and retired the HP-PA when they were amortized (or kept running code that didn't get the merced treatment).
replies(1): >>45435760 #
16. p_l ◴[] No.45435760{4}[source]
I think HPPA->Itanium replacement without replacing the entire server was limited to Superdomes.

But it made it cheaper for HP to produce Itanium servers, though I bet they didn't pass those savings...