4 ms·

I started following hardware news maybe a year or two before these IBM P4 were manufactured. I remember all the buzz on sites like Geek.com and TheInquirer.net

I started following hardware news maybe a year or two before these IBM P4 were manufactured. I remember all the buzz on sites like Geek.com and TheInquirer.net about the soon to be released AMD Clawhammers, Intel constantly pushing Itanium, and the slow feature crawl of Intel Xeons marching over Big Iron regardless of what the Itanium team wanted.

hapless 7y ago
IBM flirted with Itanium. They spent a lot of money on software support for Itanium. They sold a few hardware Itanium systems to customers who really wanted one. There just wasn't enduring customer demand to make an ongoing hardware/software product out of it.
- walrus01 7y ago
  I think theregister and theinquirer helped steer a lot of people away from itanium in that era, showing the $/performance that could be achieved with a larger number of much less costly dual socket Xeon and opteron boxes. People who really wanted to centralize everything on one godly giant machine went to things like zseries mainframe, not itanium. Everyone else started running Linux on x86...
  - hapless 7y ago
    I don't think the press had anything to do with it. Customers got engineering samples in their hands and they were very, very slow.
    - chrisseaton 7y ago
      Everyone was promised sufficiently-smart compilers would make great use of them, but that never works out as a plan.
      - jacobush 7y ago
        They very much underestimated the complexity of such compilers. But the concept is fine. Itanium had a lot of raw power, but you had to do demoscene level trickery to get that performance.
        Tuna-Fish 7y ago
        > But the concept is fine. The concept is not fine. Itanium was predicated on saving transistors in the OoO machinery, and spending those on making the machine wider and thus performance. However, it turns out that without any OoO, the machine is terrible at hiding memory latency, and the only way to get this back was to ship it with heroically large and low latency caches. And implementing those caches was harder and many times more expensive than just using OoO. In the end, Itanium saved transistors and power from one side, only to have to spend much more on another side to recoup even part of the performance that was lost.
        jacobush 7y ago
        Mhm, yeah, it depends on how you look at I guess. I meant if you fine tuned your code to take advantage of the strengths, it could be very good for those workloads. But maybe they built something which from afar, if you squint a lot, has more of the strengths of a programmable GPU today, while they pitched it as a general CPU.
        notacoward 7y ago
        The concept was fine based on knowledge available at the time. Processor design occurs on a long cycle, sometimes requiring some guesswork about surrounding technology. The issue of having to hope/guess that compilers would figure out how to optimize well for "difficult" processors had already arisen with RISC and its exposed pipelines. In fact, reliance on smart compilers was a core part of the RISC value proposition. It had worked out pretty well that time. Why wouldn't it again? VLIW had been tried before Itanium. I had some very minimal exposure to both Multiflow and Cydrome, somewhat more with i860. The general feeling at the time among people who had very relevant knowledge or experience was that compilers were close to being able to deal with something like Itanium sufficiently well. Turns out they were wrong. Perhaps the concept is not fine, but we should be careful to distinguish knowledge gained from hindsight vs. criticism of those who at least had the bravery to try.
    - acje 7y ago
      The focus on vertical scale servers and FP performance was a mistake. Had they focused on single socket servers with INT performance the history might have been different. Also today’s compilers are much more capable so maybe Itanium was simply too early.

hapless 7y ago

IBM flirted with Itanium. They spent a lot of money on software support for Itanium. They sold a few hardware Itanium systems to customers who really wanted one. There just wasn't enduring customer demand to make an ongoing hardware/software product out of it.

walrus01 7y ago
I think theregister and theinquirer helped steer a lot of people away from itanium in that era, showing the $/performance that could be achieved with a larger number of much less costly dual socket Xeon and opteron boxes. People who really wanted to centralize everything on one godly giant machine went to things like zseries mainframe, not itanium. Everyone else started running Linux on x86...
- hapless 7y ago
  I don't think the press had anything to do with it. Customers got engineering samples in their hands and they were very, very slow.
  - chrisseaton 7y ago
    Everyone was promised sufficiently-smart compilers would make great use of them, but that never works out as a plan.
    - jacobush 7y ago
      They very much underestimated the complexity of such compilers. But the concept is fine. Itanium had a lot of raw power, but you had to do demoscene level trickery to get that performance.
      - Tuna-Fish 7y ago
        > But the concept is fine. The concept is not fine. Itanium was predicated on saving transistors in the OoO machinery, and spending those on making the machine wider and thus performance. However, it turns out that without any OoO, the machine is terrible at hiding memory latency, and the only way to get this back was to ship it with heroically large and low latency caches. And implementing those caches was harder and many times more expensive than just using OoO. In the end, Itanium saved transistors and power from one side, only to have to spend much more on another side to recoup even part of the performance that was lost.
        jacobush 7y ago
        Mhm, yeah, it depends on how you look at I guess. I meant if you fine tuned your code to take advantage of the strengths, it could be very good for those workloads. But maybe they built something which from afar, if you squint a lot, has more of the strengths of a programmable GPU today, while they pitched it as a general CPU.
        notacoward 7y ago
        The concept was fine based on knowledge available at the time. Processor design occurs on a long cycle, sometimes requiring some guesswork about surrounding technology. The issue of having to hope/guess that compilers would figure out how to optimize well for "difficult" processors had already arisen with RISC and its exposed pipelines. In fact, reliance on smart compilers was a core part of the RISC value proposition. It had worked out pretty well that time. Why wouldn't it again? VLIW had been tried before Itanium. I had some very minimal exposure to both Multiflow and Cydrome, somewhat more with i860. The general feeling at the time among people who had very relevant knowledge or experience was that compilers were close to being able to deal with something like Itanium sufficiently well. Turns out they were wrong. Perhaps the concept is not fine, but we should be careful to distinguish knowledge gained from hindsight vs. criticism of those who at least had the bravery to try.
  - acje 7y ago
    The focus on vertical scale servers and FP performance was a mistake. Had they focused on single socket servers with INT performance the history might have been different. Also today’s compilers are much more capable so maybe Itanium was simply too early.