5 ms·
Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which
by microcolonel 9y ago
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.
- bogomipz 9y ago>"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.
- nickpsecurity 9y agohttp://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
- mirimir 9y agoOnly two apps that I use regularly use multiple cores: Excel and VirtualBox.
- baq 9y agoand your browser :)
- nickpsecurity 9y agoEspecially when Mozilla's Quantum hits.
- mirimir 9y agoReally? Firefox? I hadn't checked. I use browsers in VMs, which typically have one core, not in hosts.
- colejohnson66 9y agoI 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
- mirimir 9y agoYes, I see. Cool.
- nickpsecurity 9y agoOne 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. https://en.wikipedia.org/wiki/Channel_I/O https://en.wikipedia.org/wiki/Channel_I/O Even some embedded SoC's are doing this now where there's a strong core and a cheap core w/ main function and I/O split among them.
- monocasa 9y agoThat was the idea behind the Wii and the WiiU too. People called the IO processor "the real OS" because they had never seen dedicated I/O processors before.
- nickpsecurity 9y ago"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.
- bogomipz 9y agoInteresting. Do you have links for any specific SoC vendors that are offering this?
- monocasa 9y agoFreescale's Vybrids come to mind.
- mirimir 9y agoI 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 :) 0) https://github.com/maqp/tfc https://github.com/maqp/tfc
- bogomipz 9y agoWhat a great read, thanks!
- CalChris 9y agoNot sure I agree with that but the big idea from VLIW compilers, Fisher's trace scheduling [1], works just fine for superscalar schedulers as well. [1] https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d30932d7d8f4a933.pdf https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d3...
- frankpf 9y agoIt 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.