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.
What irks me is computing and comparing W/Mips for vastly different processors like 45W Intel and 5W ARM chips. That just isn't reasonable, as performance increase is very sublinear in power.
There are a few other things that could also impact results. Looking at the experimental design, there could be a good 25% uncertainty in the results because of how it's done at such a high level.
Rough up-to values for various things I can think of / see:
- 10% because they're using an OS rather than running binaries straight.
- 15% because GCC is odd and -O3 does even stranger things, particularly when it comes to energy.
- 15% because their benchmarks are large workloads rather than microbenchmarks that may better target the architecture rather than being huge lumps (would exacerbate GCC strangeness).
- 17% because they're measuring board rather than CPU power supply (the claim that SoC-based ARM development boards cannot have processor power isolated is questionable - I've seen Beagleboards with the CPU power supply isolated)
- 10% because they're measuring energy consumption at a low resolution (their equipment measures in Hz when there's kit that happily measures in kHz or MHz).
Of course, some of these will cancel, and others will be nowhere near as bad as stated. It also doesn't introduce order-of-magnitude changes to the conclusions, although a few of the 'Key Findings' may want questioning.
Did anyone find a reasonably prominent link to the source?
It seems to me as if this article is mostly linkbait simply by reason of it failing to provide anything more than vague phrases about the source: "This paper is an updated version of one I’ve referenced in previous stories, ... the team from the University of Wisconsin"
Half-baked studies frequently attempt to shout down the real hard science.
Think we have the answer in the source article's abstract,
" Our methodical investigation demonstrates the role of ISA
in modern microprocessors’ performance and energy efficiency.
We find that ARM and x86 processors are simply engineering
design points optimized for different levels of performance, and
there is nothing fundamentally more energy efficient in one ISA
class or the other. The ISA being RISC or CISC seems irrelevant."
The one argument I can make is that MIPS is too simple. But I would only make this claim on the simplest of in-order single or dual issue implementations. Think of a memcpy loop: 32-bit ARM and PowerPC can update the pointers as a side effect of the load and store instructions, but MIPS can not. You could make similar arguments in favour of ARM's thumb instruction set (more work done per 32-bits of instruction loaded with low decoding overhead vs. x86).
For implementations more advanced than this... I don't think you can make any such claim based on ISA. x86 may be at a slight disadvantage due to decoding, but that's about it.
With ARM different companies can license the design and include different system components on the chip. With Intel you need to take a packaged chip provided by Intel. This can allow a system power and cost advantage compared to having multiple chips. It is however a licensing/business model issue rather than a fundamental ISA issue.
Intel is starting to offer custom customer silicon on its chips. They signed a contract with Rockchip a couple months ago are now marketing that product to customers in China.
The way this data is normalized destroys any comparison of offsets between mobile/server (and other) scenarios. Whats wrong with using the unit of measure, like Watts?
This is not a half baked study. The right comparison is being made, namely performance versus energy. Further, they attempt normalized comparisons, here quoting:
To factor out the impact of technology, present technology-independent power by scaling all processors to 45nm and normalizing the frequency to 1 GHz.
Normalization is nice for a mental exercise, but I cannot buy a normalized phone with a normalized i7 that fits in my normalized pocket. Engineering is the art of trade-offs and the i7 has traded off size and power to achieve speed. That is great when you have an i7-scale size and power budget, but if the i7 exceeds your power or size budget it is a non-starter regardless of how efficient (when normalized) it is. Full stop.
The implicit argument of the paper is that Intel could produce a direct size+power+speed replacement for a phone-scale ARM processor, they just need to dial the knobs to small+small+slower. The counter argument is that they have tried but not come close. The Atom line is roughly comparable with respect to speed, but size and power are a problem. The Galileo processor is roughly comparable with respect to power and size but speed is horribly lacking.
There are x86 phones on the market that have similar weight/shape/battery life to ARM phones. Anandtech reviewed one two years ago and found it in the middle of the pack with respect to energy.
The question for Intel is dialing down the profit knob: how much of a hit do they want to take on each unit shipped, by competing with ARM for tiny phone chips.
Unless they carefully considered issues such as memory timing, or actually ran all the CPUs at 1GHz, just scaling results by clock frequency will make the x86s look worse and the ARMs better, because the x86s have a bigger gap between core and memory speed. Anyone who has experience with PC overclocking will know this - increasing the core clock by e.g. 25% will not make any benchmark (except maybe the most trivial of microbenchmarks) result improve by that same amount, and the same goes for the other direction: A 3.4GHz i7 run at 1GHz will not be 3.4x slower. On the other hand (no pun intended), the ARMs have a native frequency closer to 1GHz and scaling their results will not introduce as much error.
I hoped the article had a look at which parts of those ISAs were reversible, and thus did not dissipate energy.
For those interested, there is a master thesis from the '90 that discussed a prototype reversible ISA + RTL that wasted (in theory) no power for the logic (non-IO) parts [2].
Not really. Both Intel and AMD do weird non-RISCy things beyond the decode stage.
The original difference between RISC and CISC was that RISC eschewed arithmetic+memory-operations in the same instruction. Both Intel and AMD processors violate this commandment. Instead their decomposition of instructions into uops is based more on the more pragmatic notion of choosing uops that are easy to pipeline and execute out of order.
It depends on what you consider RISC to be. The ARMs in that list decode instructions into uops too. The only CPU in that list that's probably "pure RISC", in the sense of the ISA instructions themselves being the uops, is the MIPS.
I think kristianp's point is that current x86 implementations are simply an x86 instruction decoder/emulator running on a very-RISC microcoded machine.
Which is how a lot of mainframes were implemented in the 60s/70s (e.g. KL-10).
Power consumption by the instruction decoder vs the power consumption of additional cache&memory bandwidth.
It's amusing that despite the complaints towards X86 in the 90's nowadays it's actually a really good instruction packing format (though it became really sensible only after AMD64).
The article explicitly addresses that the claim is that it matters for tiny processoors of 1-2 mm2 die size, but for the processor power commonly used in phones or such, that particular cost is insignificant.
You can have an impact on power consumption at a range of levels. From choosing appropriate algorithms, to switching to different data types, to changing compiler flags. Add together a few of these 'easy' 5-10% energy savings and you've just reduced your application's energy consumption by a third (OK, it's not quite that simple, but the principle stands).
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.)