3 ms·

I'd argue it was Linux (on x86) and the dot-com crash that destroyed the workstation market, not Itanium. The early 2000s was awash in used workstation gear, es

I'd argue it was Linux (on x86) and the dot-com crash that destroyed the workstation market, not Itanium. The early 2000s was awash in used workstation gear, especially Sun. I've never seen anyone with an Itanium box.

tyingq 1y ago
I think the idea there is that it's less direct. Intel's lack of interest in a 64-bit x86 spawned AMD x64. The failure of Itanium then let that Linux/AMD x64 kill off the workstation market, and the larger RISC/Unix market. Linux on 32 bit X86 or 64 bit RISC alone was making some headway there, but the Linux/x64 combo is what enabled the full kill off.
- p_l 1y ago
  Intel's lack of interest in delivering 64bit for "peons" running x86 also was part - I remember when first discussion in popular computer magazines showed of amd64, that intel's proposed timeline was discussed, and it very much indicated a wish to push for "buy our super expensive stuff" and trying to squeeze money. Meanwhile the decision to keep Itanium on expensive but lower-volume market meant that there simply wasn't much market growth, especially once non-technical part of killing other RISCs failed. Ultimately Itanium was left as recommended way in some markets to run Oracle databases (due to partnership between Oracle and HP) and not much else, while shops that used other RISC platforms either migrated to AMD64, or moved to other RISC platforms (even forcing HP to resurrect Alpha for last one gen)
phire 1y ago
While Linux helped, I'd argue the true factor is that x86 failed to die as projected. The common attitude in the 80s and 90s was that legacy ISAs like 68k and x86 had no future. They had zero chance to keep up with the innovation of modern RISC designs. But not only did x86 keep up, it was actually outperforming many RISC ISAs. The true factor is out-of-order execution. Some RISC contemporary designs were out-of-order too (Especially Alpha, and PowerPC to a lesser extent), but both AMD and Intel were forced to go all-in on the concept in a desperate attempt to keep the legacy x86 ISA going. Turns out large out-of-order designs was the correct path (mostly OoO has side effect of being able to reorder memory accesses and execute them in parallel), and AMD/Intel had a bit of a head start, a pre-existing customer base and plenty of revenue for R&D. IMO, Itanium failed not because it was a bad design, but because it was on the wrong path. Itanium was an attempt to achieve roughly the same end goal as OoO, but with a completely in-order design, relying on static scheduling. It had massive amounts of complexity that let it re-order memory reads. In an alternative universe where OoO (aka dynamic scheduling) failed, Itanium might actually be a good design. Anyway, by the early 2000s, there just wasn't much advantage to a RISC workstation (or RISC servers). x86 could keep up, was continuing to get faster and often cheaper. And there were massive advantages to having the same ISA across your servers, workstations and desktops.
- chasil 1y ago
  Bob Colwell mentions originally doing out of order design at Multiflow. He was a key player in the Pentium Pro out of order implementation. https://www.sigmicro.org/media/oralhistories/colwell.pdf https://www.sigmicro.org/media/oralhistories/colwell.pdf "We should also say that the 360/91 from IBM in the 1960s was also out of order, it was the first one and it was not academic, that was a real machine. Incidentally that is one of the reasons that we picked certain terms that we used for the insides of the P6, like the reservation station that came straight out of the 360/91." Here is his Itanium commentary: "Anyway this chip architect guy is standing up in front of this group promising the moon and stars. And I finally put my hand up and said I just could not see how you're proposing to get to those kind of performance levels. And he said well we've got a simulation, and I thought Ah, ok. That shut me up for a little bit, but then something occurred to me and I interrupted him again. I said, wait I am sorry to derail this meeting. But how would you use a simulator if you don't have a compiler? He said, well that's true we don't have a compiler yet, so I hand assembled my simulations. I asked "How did you do thousands of line of code that way?" He said “No, I did 30 lines of code”. Flabbergasted, I said, "You're predicting the entire future of this architecture on 30 lines of hand generated code?" [chuckle], I said it just like that, I did not mean to be insulting but I was just thunderstruck. Andy Grove piped up and said "we are not here right now to reconsider the future of this effort, so let’s move on"."
  - phire 1y ago
    > Bob Colwell mentions originally doing out of order design at Multiflow. Actually no, it was Metaflow [0] who was doing out-of-order. To quote Colwell: "I think he lacked faith that the three of us could pull this off. So he contacted a group called Metaflow. Not to be confused with Multiflow, no connection." "Metaflow was a San Diego group startup. They were trying to design an out of order microarchitecture for chips. Fred thought what the heck, we can just license theirs and remove lot of risk from our project. But we looked at them, we talked to their guys, we used their simulator for a while, but eventually we became convinced that there were some fundamental design decisions that Metaflow had made that we thought would ultimately limit what we could do with Intel silicon." Multiflow, [1] where Colwell worked, has nothing to do with OoO, its design is actually way closer to Itanium. So close, in-fact that the Itanium project is arguably a direct decedent of Multiflow (HP licensed the technology, and hired Multiflow's founder, Josh Fisher). Colwell claims that Itainum's compiler is nothing more than the Multiflow compiler with large chunks rewritten for better performance. [0] https://en.wikipedia.org/wiki/Metaflow_Technologies https://en.wikipedia.org/wiki/Metaflow_Technologies [1] https://en.wikipedia.org/wiki/Multiflow https://en.wikipedia.org/wiki/Multiflow
kjs3 1y ago
Yup. I had a front row seat. So many discussion with startups in the 2Ks that boiled down to "we can get a Sun/HP/DEC machine, or we can get 4-5 nice Wintel boxes running Linux for the same price". So at the point where everyone figured out Linux was a 'good enough' Unix for dev work and porting to the incumbents was a reasonable prospect, it was "so do we all want to share one machine or go find 500% more funding just to have the marquis brand". Once you made that leap, "we don't need the incumbents" because inevitable.
- icedchai 1y ago
  It was amazing how fast that happened. I remember one startup mainly supported Sun, late 90's, early 2000's. This was for a so called "enterprise" app that would run on-prem. They wanted me to move the app to Linux (Red Hat, I think?) so they could take it to a trade show booth without reliable Internet access. It was a pretty simple port.

tyingq 1y ago

I think the idea there is that it's less direct. Intel's lack of interest in a 64-bit x86 spawned AMD x64. The failure of Itanium then let that Linux/AMD x64 kill off the workstation market, and the larger RISC/Unix market. Linux on 32 bit X86 or 64 bit RISC alone was making some headway there, but the Linux/x64 combo is what enabled the full kill off.

p_l 1y ago
Intel's lack of interest in delivering 64bit for "peons" running x86 also was part - I remember when first discussion in popular computer magazines showed of amd64, that intel's proposed timeline was discussed, and it very much indicated a wish to push for "buy our super expensive stuff" and trying to squeeze money. Meanwhile the decision to keep Itanium on expensive but lower-volume market meant that there simply wasn't much market growth, especially once non-technical part of killing other RISCs failed. Ultimately Itanium was left as recommended way in some markets to run Oracle databases (due to partnership between Oracle and HP) and not much else, while shops that used other RISC platforms either migrated to AMD64, or moved to other RISC platforms (even forcing HP to resurrect Alpha for last one gen)

phire 1y ago

While Linux helped, I'd argue the true factor is that x86 failed to die as projected. The common attitude in the 80s and 90s was that legacy ISAs like 68k and x86 had no future. They had zero chance to keep up with the innovation of modern RISC designs. But not only did x86 keep up, it was actually outperforming many RISC ISAs. The true factor is out-of-order execution. Some RISC contemporary designs were out-of-order too (Especially Alpha, and PowerPC to a lesser extent), but both AMD and Intel were forced to go all-in on the concept in a desperate attempt to keep the legacy x86 ISA going. Turns out large out-of-order designs was the correct path (mostly OoO has side effect of being able to reorder memory accesses and execute them in parallel), and AMD/Intel had a bit of a head start, a pre-existing customer base and plenty of revenue for R&D. IMO, Itanium failed not because it was a bad design, but because it was on the wrong path. Itanium was an attempt to achieve roughly the same end goal as OoO, but with a completely in-order design, relying on static scheduling. It had massive amounts of complexity that let it re-order memory reads. In an alternative universe where OoO (aka dynamic scheduling) failed, Itanium might actually be a good design. Anyway, by the early 2000s, there just wasn't much advantage to a RISC workstation (or RISC servers). x86 could keep up, was continuing to get faster and often cheaper. And there were massive advantages to having the same ISA across your servers, workstations and desktops.

chasil 1y ago
Bob Colwell mentions originally doing out of order design at Multiflow. He was a key player in the Pentium Pro out of order implementation. https://www.sigmicro.org/media/oralhistories/colwell.pdf https://www.sigmicro.org/media/oralhistories/colwell.pdf "We should also say that the 360/91 from IBM in the 1960s was also out of order, it was the first one and it was not academic, that was a real machine. Incidentally that is one of the reasons that we picked certain terms that we used for the insides of the P6, like the reservation station that came straight out of the 360/91." Here is his Itanium commentary: "Anyway this chip architect guy is standing up in front of this group promising the moon and stars. And I finally put my hand up and said I just could not see how you're proposing to get to those kind of performance levels. And he said well we've got a simulation, and I thought Ah, ok. That shut me up for a little bit, but then something occurred to me and I interrupted him again. I said, wait I am sorry to derail this meeting. But how would you use a simulator if you don't have a compiler? He said, well that's true we don't have a compiler yet, so I hand assembled my simulations. I asked "How did you do thousands of line of code that way?" He said “No, I did 30 lines of code”. Flabbergasted, I said, "You're predicting the entire future of this architecture on 30 lines of hand generated code?" [chuckle], I said it just like that, I did not mean to be insulting but I was just thunderstruck. Andy Grove piped up and said "we are not here right now to reconsider the future of this effort, so let’s move on"."
- phire 1y ago
  > Bob Colwell mentions originally doing out of order design at Multiflow. Actually no, it was Metaflow [0] who was doing out-of-order. To quote Colwell: "I think he lacked faith that the three of us could pull this off. So he contacted a group called Metaflow. Not to be confused with Multiflow, no connection." "Metaflow was a San Diego group startup. They were trying to design an out of order microarchitecture for chips. Fred thought what the heck, we can just license theirs and remove lot of risk from our project. But we looked at them, we talked to their guys, we used their simulator for a while, but eventually we became convinced that there were some fundamental design decisions that Metaflow had made that we thought would ultimately limit what we could do with Intel silicon." Multiflow, [1] where Colwell worked, has nothing to do with OoO, its design is actually way closer to Itanium. So close, in-fact that the Itanium project is arguably a direct decedent of Multiflow (HP licensed the technology, and hired Multiflow's founder, Josh Fisher). Colwell claims that Itainum's compiler is nothing more than the Multiflow compiler with large chunks rewritten for better performance. [0] https://en.wikipedia.org/wiki/Metaflow_Technologies https://en.wikipedia.org/wiki/Metaflow_Technologies [1] https://en.wikipedia.org/wiki/Multiflow https://en.wikipedia.org/wiki/Multiflow

kjs3 1y ago

Yup. I had a front row seat. So many discussion with startups in the 2Ks that boiled down to "we can get a Sun/HP/DEC machine, or we can get 4-5 nice Wintel boxes running Linux for the same price". So at the point where everyone figured out Linux was a 'good enough' Unix for dev work and porting to the incumbents was a reasonable prospect, it was "so do we all want to share one machine or go find 500% more funding just to have the marquis brand". Once you made that leap, "we don't need the incumbents" because inevitable.

icedchai 1y ago
It was amazing how fast that happened. I remember one startup mainly supported Sun, late 90's, early 2000's. This was for a so called "enterprise" app that would run on-prem. They wanted me to move the app to Linux (Red Hat, I think?) so they could take it to a trade show booth without reliable Internet access. It was a pretty simple port.