3 ms·

Itanium had a decent service life and a reasonable install base. It didn't take off because of economies of scale and Intel not really wanting to introduce a bi

Itanium had a decent service life and a reasonable install base. It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. The Itanium platform was totally unaffected by Spectre/Meltdown type attacks, you may note.

toast0 5y ago
> It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel didn't want to make 64-bit x86, but the market prefered amd64 over itanium.
jcranmer 5y ago
> It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel invested heavily into Itanium, and the 90s started seeing the deaths of competing processor architectures in part because of how hyped up the Intel Itanium was getting. It was intended to be the 64-bit version of x86, hence the abbreviation IA-64. AMD was the one who created what we now know as x86-64, and my understanding is that Microsoft more or less forced Intel to implement AMD's x86-64 specification. In its later years (let's say by 2010, since that's the midpoint of Itanium's life as a shipping product, but I don't have any clear dates as to when the shift happens), it does seem to be that Intel was reluctant to continue supporting Itanium. But that was definitely not the case beforehand.
hajile 5y ago
Intel, HP, etc invested over 10 billion dollars into Itanium (closer to 14-17 billion dollars today). For perspective, AMD's market cap in 2003 was around 5 billion. They could have built 20% of the US carrier fleet of the time with that much money. Ultimately, the compiler never materialized and I'm convinced they knew it wouldn't (but in the meantime, they almost killed all the RISC competition). The Halting problem means that at best you have heuristic optimizations that constantly fall through. The only way to solve these problems with a high degree of success is to analyze the code as it is running which is what other CPUs actually do. This is so true that later versions of Itanium (latest being released in 2017) were just VLIW wrappers around a rather traditional, speculative core.
- timschmidt 5y ago
  Languages like Rust permit sufficient analysis at compile time to make architectures like mill and itanium shine. One of the reasons Rust is so exciting beyond the oft repeated memory and thread safety.
  - colejohnson66 5y ago
    Knowing who owns what data wasn't Itanium's issue. It was that the compiler was expected to manage the pipeline ahead of time using static analysis when dynamic analysis is required for best performance. Speculative execution (ignoring the issues of Spectre/Meltdown) is a much better model than what the Itanium and Mill require. It's impossible to know ahead of time all the possible states of an arbitrary program. Because of that, branch predictors are still king.
    - timschmidt 5y ago
      I'm pretty sure that what I said about Rust in this context stands. The same math it uses to guarantee thread safety works also for speculative loading during execution. Or could with little effort. Rust requires enough information about the data to know for certain which routine will be handling it at compile time. This is sufficient for speculative loading. You are correct in as much that achieving this level of optimization through static analysis alone without cooperation in the language would be a very challenging problem. The folks at https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ are taking a stab at it nonetheless - their approach requires language extensions. I'd prefer not to ignore the issues of Spectre and Meltdown - doing so is what got us here in the first place. I still run many older machines in roles for which they are well suited and would gladly trade performance for more predictable and secure behavior.

toast0 5y ago

> It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel didn't want to make 64-bit x86, but the market prefered amd64 over itanium.

jcranmer 5y ago

> It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel invested heavily into Itanium, and the 90s started seeing the deaths of competing processor architectures in part because of how hyped up the Intel Itanium was getting. It was intended to be the 64-bit version of x86, hence the abbreviation IA-64. AMD was the one who created what we now know as x86-64, and my understanding is that Microsoft more or less forced Intel to implement AMD's x86-64 specification. In its later years (let's say by 2010, since that's the midpoint of Itanium's life as a shipping product, but I don't have any clear dates as to when the shift happens), it does seem to be that Intel was reluctant to continue supporting Itanium. But that was definitely not the case beforehand.

hajile 5y ago

Intel, HP, etc invested over 10 billion dollars into Itanium (closer to 14-17 billion dollars today). For perspective, AMD's market cap in 2003 was around 5 billion. They could have built 20% of the US carrier fleet of the time with that much money. Ultimately, the compiler never materialized and I'm convinced they knew it wouldn't (but in the meantime, they almost killed all the RISC competition). The Halting problem means that at best you have heuristic optimizations that constantly fall through. The only way to solve these problems with a high degree of success is to analyze the code as it is running which is what other CPUs actually do. This is so true that later versions of Itanium (latest being released in 2017) were just VLIW wrappers around a rather traditional, speculative core.

timschmidt 5y ago
Languages like Rust permit sufficient analysis at compile time to make architectures like mill and itanium shine. One of the reasons Rust is so exciting beyond the oft repeated memory and thread safety.
- colejohnson66 5y ago
  Knowing who owns what data wasn't Itanium's issue. It was that the compiler was expected to manage the pipeline ahead of time using static analysis when dynamic analysis is required for best performance. Speculative execution (ignoring the issues of Spectre/Meltdown) is a much better model than what the Itanium and Mill require. It's impossible to know ahead of time all the possible states of an arbitrary program. Because of that, branch predictors are still king.
  - timschmidt 5y ago
    I'm pretty sure that what I said about Rust in this context stands. The same math it uses to guarantee thread safety works also for speculative loading during execution. Or could with little effort. Rust requires enough information about the data to know for certain which routine will be handling it at compile time. This is sufficient for speculative loading. You are correct in as much that achieving this level of optimization through static analysis alone without cooperation in the language would be a very challenging problem. The folks at https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ are taking a stab at it nonetheless - their approach requires language extensions. I'd prefer not to ignore the issues of Spectre and Meltdown - doing so is what got us here in the first place. I still run many older machines in roles for which they are well suited and would gladly trade performance for more predictable and secure behavior.