Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write.
With it being borderline impossible to write good VLIW compilers, most of the instruction word was full of NOPs, which meant terrible code density, which meant I$ full of NOPs. A recipe for hot, slow computers which are depressing to program for.
It also failed because, at least 6 years before Itanium was even released (2001), there were better, faster options available.
In 1995, the Pentium Pro featured out-of-order and speculative execution[1]. This has two main advantages over the VLIW architecture (Itanium in particular):
1) The processor can use runtime information (such as past history of branches) to speculatively execute hundreds of instructions before they are needed.
2) When a stall happens due to a cache miss, in some cases the CPU can continue to execute instructions while waiting for the stall to end. This isn't possible with VLIW because the compiler can't predict cache hits/misses, this information is only available at runtime.
These two advantages combined made Itanium much slower than the then available x86 processors.
[1]: Note that Intel didn't invent these ideas. OoO was already known in the 1970s, although it was applied to mainframe supercomputers. I'm just using Pentium Pro as an example of a similar microprocessor.
>"Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write."
Wow, might you have any links regarding Knuth commenting on VLIW optimized compilers? I would love to read more about this.
What was Intel's view on the viability of it? It seems like quite a shortcoming.
One could do it mainframe style where the I/O was offloaded to one core with the rest doing compute. Those hundreds of thousands of interrupts never hit your single-CPU task. You can get a boost in performance even in your use-case.
I had thought of using multiple SoCs for compartmentalization, instead of VMs. Rather like a hardware version of Qubes. I was very inspired by Tinfoil Chat.[0] Using optoisolators, one could have a secure device with strictly text-only communication with other components.
But it's over my head. I lack knowledge and equipment for measuring RF leakage among SoCs. So it goes. Maybe the Qubes team will do it :)
" I was very inspired by Tinfoil Chat.[0] Using optoisolators, one could have a secure device with strictly text-only communication with other components."
Our discussions about physical and diode security on Schneier's blog were a small part of inspiration for Tinfoil Chat. Markus Ottela then showed up to discuss the design. He wisely incorporated each piece of feedback like switching from OTP to a polycipher and covert-channel mitigation at protocol level. Loved reading his regular updates he posted of the things he added. The design, not implementation, is one of the only things I'll call NSA proof for confidentiality and security but not availability. By NSA proof, I mean without TAO getting involved with really hands-on stuff.
One drawback was he didn't know system programming. So, reference implementation is in Python. People that know statically-verifiable C, Ada/SPARK, or Rust need to implement it on a minimal TCB. I'd start with a cut down OpenBSD first just because the NSA will go for 0-days in the lower layers and they have less. Make the implementation as portable on MIPS and ARM as possible so the hardware can be interchanged easily. Trimmed Linux next if drivers absolutely need it w/ Poly2 Architecture-style deletion of unnecessary code. If money comes in, implement it on a secure CPU such as CHERI w/ CHERIBSD.
That was my plan when I was talking to him. Lots of potential with TFC after it gets a proper review of protocol and implementation.
"People called the IO processor "the real OS" because they had never seen dedicated I/O processors before."
I didn't know that. That's funny as it's the confusion I'd expect where the old wisdom of I/O processors in non-server stuff was lost for a few generations. Then, the new one sees them to wonder if it's an extra core for apps, the OS, or whatever.
I think he was getting at how browsers nowadays put each tab in their own process. So on multi core systems, your "browser" would end up running on multiple cores
With it being borderline impossible to write good VLIW compilers, most of the instruction word was full of NOPs, which meant terrible code density, which meant I$ full of NOPs. A recipe for hot, slow computers which are depressing to program for.