4 ms·

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 bil

by 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.

by hajile 5y ago

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.