Intel/x86 seems to have missed pretty much every major trend but somehow manages to keep up.
At the time, Intel seemed to have pinned the 64-bit future on Itanium. Which, on paper, is a much better architecture. Of course instruction parallelism should be in the hands of the compiler -- it has so much richer information from the source-code so it can do a better job. The MMU design was very clever (self-mapped linear page tables, protection keys, TLB sharing, etc). Lots of cache, minimal core. Exposing register rotation and really interesting tracing tools. But AMD released x86/64, Intel had to copy it, and the death warrant on Itanium was signed so we never got to really explore those cool features. Just now we're getting things like more levels of page-tables and protection-key type things on x86.
Intel missed virtualisation not only in x86 (understandable given legacy) but on Itanium too, where arguably they should have thought about it during green-field development (it was closer but still had a few instructions that didn't trap properly for a hypervisor to work). The first versions of vmware -- doing binary translation of x86 code the fly, was really quite amazing at the time. Virtualisation happened despite x86, not in any way because of it. And you can pretty much trace the entire "cloud" back to that. VMX eventually got bolted on.
UEFI is ... interesting. It's better than a BIOS, but would anyone hold that up as a paragon of innovation?
I'm not so familiar with the SIMD bits of the chips, but I wouldn't be surprised if there's similar stories in that area of development.
Low power seems lost to ARM and friends. Now, with the "cloud", low power is as much a problem in the data centre as your phone. So it will be interesting to see how that plays out (and it's starting to).
x86's persistence is certainly remarkable, that's for sure
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.
>"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.
Only two apps that I use regularly use multiple cores: Excel and VirtualBox.
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.
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.
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 :)