12 ms·

So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popu

So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO core uses for internal bookkeeping, just exposed architecturally). I just think the arch has a similarity to archs like cell where it was planned for a world without the end of dennard scaling and just stopped making sense when we weren't targeting scaling to 10Ghz consumer CPUs and beyond. The relatively fixed clock period that makes sense post ~2006 also means that the CPU architecture of that made the most sense ~2006 (Tomasulo OoO cores) continues to make sense, with most of the process gains going to just making bigger, wider cores.

deleted 2mo ago
[deleted]
twoodfin 2mo ago
It was also planned for a world where high-end CPUs were differentiated by their ability to run floating-point-heavy workloads with relatively predictable memory access patterns. The rise of the web—and databases behind it—as the dominant high-end, high-margin workload obsoleted that assumption. There’s a great presentation floating around where a Compaq-acquired-DEC engineer is trying to justify how great the OpenVMS port from Alpha to Itanium is going, despite benchmarks showing Alpha smoking Itanium running Apache.
- eej71 2mo ago
  I worked for a company that had a fairly large OpenVMS installation and had to make the transition from Alpha to Itanium. It required a considerable amount of work and the early iterations of Itanium did not provide a clear performance improvement over the final Alpha EV7z that we had been using in some GS1280s. Going by my faulty memory, I'd say it wasn't until Tukwila that it was a clear win over Alpha EV7z. By the time Tukwila arrived, it was pretty clear that Itanium's goose was already cooked.
  - p_l 2mo ago
    EV7 were introduced after customers refused to upgrade to Integrity over crap performance.
- wbl 2mo ago
  If only the Alpha had hung on.
  - icedchai 2mo ago
    I have an AlphaServer in my collection (DS10.) For a 25+ year old system, it still feels pretty snappy!
    - hypercube33 2mo ago
      I think I read at one point alpha had a 64bit cpu in the 90s that could have hit 1ghz but some bug held it back. I am having so much trouble finding these articles and stories about processors these days with AI and shitified Google. The other one I can't find I swear was a former AMD engineer talking about how Intel bet the farm on one ibm mainframe design but AMD went with an older architecture (under the hood of x86 for both) that was harder to deal with but ultimately runs faster and that's how we got ryzen. Maybe I'm just losing my mind.
      - touisteur 2mo ago
        I think the "Jim Keller" story around Zen is a bet on modularity, core-complexes, then chiplets. Smaller, less monolithic designs and a clean re-design of the x86 cores for compacity, ease of validation and scalability (in core count).
  - shawn_w 2mo ago
    My college was a DEC shop; I learned programming and how to use unix in labs full of dumb X terminals connected to Alpha servers. Still have a lot of nostalgia for the architecture.
acdha 2mo ago
There was also a long piece by a former Intel chip designer who was incredulous about how much the Itanium team was promising numbers based on a very few hand-scheduled routines for FPU-limited code. I think there’s a solid argument that the design just wasn’t based on a correct understanding of what most CPUs did and over-indexed on the most performance-sensitive HPC code. I once helped run some HPC code on a test Itanium system and even there it was just so easy to fall out of the only patterns which performed well and end up slower than older Pentiums even before factoring price into the evaluation. > 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". https://www.sigmicro.org/media/oralhistories/colwell.pdf https://www.sigmicro.org/media/oralhistories/colwell.pdf > Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis. http://courses.cs.washington.edu/courses/csep590/06au/projects/history-64-bit.pdf http://courses.cs.washington.edu/courses/csep590/06au/projec...
- kmeisthax 2mo ago
bluedino 2mo ago
I wonder if most people kept them around just so they don't have to port their apps or migrate to something new. I worked at an HP shop, and Itanium ran HP/UX so they kept running their business on their PickBASIC (and whatever database that I've forgotten the name of) system
jcranmer 2mo ago
I recall opening up the Itanium manual, and by the end of the architecture description, just despairing of the thought of trying to write a compiler for it. Itanium, I think, was ultimately a victim of its weirdness: it's too weird to really comfortably write assembly by hand; the compilers weren't really capable with its weirdness, so "regular" code was worse off than you'd normally expect. Raymond Chen has pointed out in several articles how the hardware took advantage of C's UB to do some really weird things--and this is an era where most developers expected UB to really be just implementation-defined behavior. Combine that with the fact that the hardware development process seems to have been compromised from the start (if you told me the hardware architects never looked at anything other than 30-instruction traces of BLAS kernels, I'd believe you), and the insane hype that was built up for it... it's not surprising that it had an extremely underwhelming launch.
alphabeta3r56 2mo ago
It's more simple. Online bin packing problem is simpler to solve and has more optimal solutions with smaller chunks

deleted 2mo ago

[deleted]

twoodfin 2mo ago

It was also planned for a world where high-end CPUs were differentiated by their ability to run floating-point-heavy workloads with relatively predictable memory access patterns. The rise of the web—and databases behind it—as the dominant high-end, high-margin workload obsoleted that assumption. There’s a great presentation floating around where a Compaq-acquired-DEC engineer is trying to justify how great the OpenVMS port from Alpha to Itanium is going, despite benchmarks showing Alpha smoking Itanium running Apache.

eej71 2mo ago
I worked for a company that had a fairly large OpenVMS installation and had to make the transition from Alpha to Itanium. It required a considerable amount of work and the early iterations of Itanium did not provide a clear performance improvement over the final Alpha EV7z that we had been using in some GS1280s. Going by my faulty memory, I'd say it wasn't until Tukwila that it was a clear win over Alpha EV7z. By the time Tukwila arrived, it was pretty clear that Itanium's goose was already cooked.
- p_l 2mo ago
  EV7 were introduced after customers refused to upgrade to Integrity over crap performance.
wbl 2mo ago
If only the Alpha had hung on.
- icedchai 2mo ago
  I have an AlphaServer in my collection (DS10.) For a 25+ year old system, it still feels pretty snappy!
  - hypercube33 2mo ago
    I think I read at one point alpha had a 64bit cpu in the 90s that could have hit 1ghz but some bug held it back. I am having so much trouble finding these articles and stories about processors these days with AI and shitified Google. The other one I can't find I swear was a former AMD engineer talking about how Intel bet the farm on one ibm mainframe design but AMD went with an older architecture (under the hood of x86 for both) that was harder to deal with but ultimately runs faster and that's how we got ryzen. Maybe I'm just losing my mind.
    - touisteur 2mo ago
      I think the "Jim Keller" story around Zen is a bet on modularity, core-complexes, then chiplets. Smaller, less monolithic designs and a clean re-design of the x86 cores for compacity, ease of validation and scalability (in core count).
- shawn_w 2mo ago
  My college was a DEC shop; I learned programming and how to use unix in labs full of dumb X terminals connected to Alpha servers. Still have a lot of nostalgia for the architecture.

acdha 2mo ago

There was also a long piece by a former Intel chip designer who was incredulous about how much the Itanium team was promising numbers based on a very few hand-scheduled routines for FPU-limited code. I think there’s a solid argument that the design just wasn’t based on a correct understanding of what most CPUs did and over-indexed on the most performance-sensitive HPC code. I once helped run some HPC code on a test Itanium system and even there it was just so easy to fall out of the only patterns which performed well and end up slower than older Pentiums even before factoring price into the evaluation. > 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". https://www.sigmicro.org/media/oralhistories/colwell.pdf https://www.sigmicro.org/media/oralhistories/colwell.pdf > Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis. http://courses.cs.washington.edu/courses/csep590/06au/projects/history-64-bit.pdf http://courses.cs.washington.edu/courses/csep590/06au/projec...

kmeisthax 2mo ago

bluedino 2mo ago

I wonder if most people kept them around just so they don't have to port their apps or migrate to something new. I worked at an HP shop, and Itanium ran HP/UX so they kept running their business on their PickBASIC (and whatever database that I've forgotten the name of) system

jcranmer 2mo ago

I recall opening up the Itanium manual, and by the end of the architecture description, just despairing of the thought of trying to write a compiler for it. Itanium, I think, was ultimately a victim of its weirdness: it's too weird to really comfortably write assembly by hand; the compilers weren't really capable with its weirdness, so "regular" code was worse off than you'd normally expect. Raymond Chen has pointed out in several articles how the hardware took advantage of C's UB to do some really weird things--and this is an era where most developers expected UB to really be just implementation-defined behavior. Combine that with the fact that the hardware development process seems to have been compromised from the start (if you told me the hardware architects never looked at anything other than 30-instruction traces of BLAS kernels, I'd believe you), and the insane hype that was built up for it... it's not surprising that it had an extremely underwhelming launch.

alphabeta3r56 2mo ago

It's more simple. Online bin packing problem is simpler to solve and has more optimal solutions with smaller chunks