ARM and x86 are rather close, but the real disappointment here is the MIPS Loongson, which is basically the "original RISC ISA". Unfortunately I've encountered a huge number of people, particularly academics, who still think (and teach) that MIPS or minor variants of it are the "best" ISAs and that one can easily make cheap, fast, and power-efficient processors based on it. Looking at the current state of things, it seems the only thing MIPS has succeeded in is being cheap and pedagogical.
I think instruction density has quite some significance here too - x86 opcodes vary between 1 and 15 bytes with 2-3 being average and ARM has Thumb mode where instructions are either 2 or 4 bytes, but all MIPS instructions are 4 bytes. It also has twice as much L1 as most of the ARM and x86 processors, which apparently didn't help it much. Cache consumes power too, and thus I believe small variable-length encodings (like x86) are ultimately better since they allow for better utilisation of cache; the extra complexity in the decoder to handle this, which basically amounts to a few barrel shifters, is almost nothing in comparison to the area and power that more cache would need.
The entire reason CISC architectures emphasized complex multi-cycle instruction execution is because memory accesses were orders of magnitude slower than the processor and data storage was extremely limited.
When considering cache, these points are all true again. There's a common belief about optimising for x86 to avoid the smaller but slower "CISC" instructions, but in situations like tight loops, an instruction that's 2-3x slower individually can be better than the faster longer one(s) if it means the difference between code and data staying in cache or a 10x+ slowdown from a cache miss somewhere else. Especially on an OoO/superscalar design where the slower instruction can be executed in parallel with other nondependent ones. (Intel/AMD's focus on speeding up these small CISC instructions - which they have done - is possibly one of the reasons why x86 performance continues to improve.)
The Loongson is a 90nm part, the others are 32-45nm. No ISA is going to make up for a doubled transistor size.
Really the notable thing to me isn't the ISA nonsense at all. It's how singular a success the Cortex A9 core is. It came at exactly the right moment in history and hit exactly the right sweet spot, being significantly beefier than the A8 yet only minimally more power-hungry. Krait has followed on pretty well, but the A15 can almost be considered a failure at this point.
As mentioned in a different comment here, all the results were scaled to 45nm@1GHz, and while that's not totally accurate, there's still a big gap between it and the ARMs/x86s.
It would be interesting to see how the A7 also compares to the A8/A9, since it's supposed to be a more power-efficient version of the A15.
My rule of thumb: if something is conceptually "pure" instead of a complicated, carefully balanced mix of grey, its usually not worth considering.
I found this to be true for programming languages, ISAs, politics etc.
It is interesting how purity has a very strong allure - maybe our brains are naturally drawn to a reduced state of complexity, and thus energy consumption?
> It is interesting how purity has a very strong allure - maybe our brains are naturally drawn to a reduced state of complexity, and thus energy consumption?
Or maybe complicated more often than not is just not a "carefully balanced mix of grey" but more of a clusterfuck .. and we learned to be wary of it.
I've seen most of his talks, actually I'm a fan. I wouldn't consider Clojure to be a good example of purity though - it has both LISP purists as well as FP purists (Haskell) against it. Actually it is quite pragmatic for running on the JVM and even has optional typing.
If elegance and simplicity are achievable without making too many sacrifices, great! I'd choose Clojure over C++ any day.
I think instruction density has quite some significance here too - x86 opcodes vary between 1 and 15 bytes with 2-3 being average and ARM has Thumb mode where instructions are either 2 or 4 bytes, but all MIPS instructions are 4 bytes. It also has twice as much L1 as most of the ARM and x86 processors, which apparently didn't help it much. Cache consumes power too, and thus I believe small variable-length encodings (like x86) are ultimately better since they allow for better utilisation of cache; the extra complexity in the decoder to handle this, which basically amounts to a few barrel shifters, is almost nothing in comparison to the area and power that more cache would need.
The entire reason CISC architectures emphasized complex multi-cycle instruction execution is because memory accesses were orders of magnitude slower than the processor and data storage was extremely limited.
When considering cache, these points are all true again. There's a common belief about optimising for x86 to avoid the smaller but slower "CISC" instructions, but in situations like tight loops, an instruction that's 2-3x slower individually can be better than the faster longer one(s) if it means the difference between code and data staying in cache or a 10x+ slowdown from a cache miss somewhere else. Especially on an OoO/superscalar design where the slower instruction can be executed in parallel with other nondependent ones. (Intel/AMD's focus on speeding up these small CISC instructions - which they have done - is possibly one of the reasons why x86 performance continues to improve.)