Arm vs RISC-V? Which One Is The Most Efficient?

Arm has been making power efficient processors for decades. RISC-V is relativity new and many parts of its specifications aren't even ratified, but that hasn't stopped chip designers making RISC-V processors, including microcontrollers. Can RISC-V challenge Arm's power efficiency supremacy?
---

#garyexplains

[rajivpalayan]

For measuring relative performance, it is wrong to do a per MHz calculation. The only metric that should matter is the total time needed to run the same application on both processors. A more complicated ISA means clock speeds will be reduced (which gives better per MHz performance), but that does not mean the processor is faster

[marklewus]

One more comment. Most processor manufacturers produce a spec called DMIPS/MHz, or millions of integer calculations per megahertz clock speed. This allows you to do a clock for clock comparison between parts.

[ralfbaechle]

RISC-V, ARM and others like MIPS which I have plenty of experience with are just architectures; the chips you can buy are implementations of these architectures. First thing to notice from a 30, 000ft perspective is that 64-bit ARM, MIPS and RISC-V are surprisingly similar. In the past CPU architects were more adventerous. These days no more bat crazy shit like segments (x86) or register windows (SPARC, and totally batshit crazy on IA-64). MIPS is an early but well designed RISC architecture; 64-bit ARM (which fortunately is rather dissimilar to the 32-bit ARM architecture) is surprisingly similar. Which is unsurprising because one of the architects used to work for MIPS. And RISC-V was designed by the fathers of SPARC and MIPS.
So are they all the same? Not quite but 64-bit ARM and RISC-V benefit significantly from hindsight.
Now, once you take things to the limit things will be different. RISC-V's smaller footprint allows fitting more cores running at a higher clockrate on a die. It barely matters for the birdseed class of microcontrollers that's polluting most PCBs ;-
So for most uses architecture doesn't matter - software does. That's where ARM is very well supported, MIPS is well established and RISC-V is still catching up. That said, the folks behind RISC-V is smart and have impressed me by what they have achieved and in my discussion so they're going to close that gap. Plus hgiher end implementations are going to show up. Being a truely open architecture however the RISC-V market can be as confusing as a ant pile - or open source in general ;-)

[markwarburton]

I was surprised that the now somewhat venerable Black Pill did so well in these tests against the newer upstarts, especially in power consumption and power efficiency. Thanks Gary!

[mementomori]

Its not about performance only!!!! The biggest thing RISCV is OPEN SOURCE processor...

[GreySectoid]

When I studied computer science Risc-V was my favorite to program. Good to see they are now doing a comeback.

One detail that you missed is that the Pico and Pico W do not have a linear regulator; they have an on-board buck-boost switching power supply. Current consumption will not be constant; it will go up as voltage decreases.

[jamesmcintyre]

I appricate that Gary is right here that RISC-V is not yet *as* effecient as but I'm very impressed that RISC-V is already *almost* as efficent as ARM with for the same processes being run 1.36mWh compaired to the equivlent ARM board getting 1.31mWh and even compaired to the *much* more established Pi Pico, it's only 8% less effient (than the Pico). Obviously being almost 89% less efficient than the Blackpill isn't ideal for RISC-V but this is still early days for it compared to ARM and just with there being so many less RISC-V processors produced vs ARM, I don't think you can expect it to be beating the leaders of the pack in ARM just yet. Maybe when there are as many models of RISK-V processor as ARM processors the leader will be arm. Maybe with more time for tuning, the leader of the RISC-V pack will beat the leader of the ARM pack; even with less models out there. Encouraging stuff.

Stating my bias: I want RISC-V to succeed as I think open source is the way forward and garding "intelectual property" like dragons over gold, is holding humanity back.

Thanks for the interesting video Gary!

[marklewus]

Great work as always. Benchmarking is always a can of worms because it is as dependent on the application as it is on the processor. Do you need fast integer? Fast interrupt response? Floating point? DMA? If you used newer M3 and M4 parts they would have performed much better even in this integer-only test both with regard to processing speed and power consumption given that they’re built on *much* newer process nodes. And a recent STM32 M7 would’ve blown everything else out of the water.

[LokiScarletWasHere]

It’s always strange being reminded that people think RISC-V is inherently more efficient than ARM. That’s not why people like the architecture. It’s an open standard, whereas ARM is proprietary. Anyone who can make a chip can make and innovate a RISC-V design, not the case with ARM.
That being said, this was nice to see. I’m sure it has a lot of people blackpilled now.

[jacobrosen]

A nice explanation as always. But I'm missing the sleep current for the different boards. It would be intresting to see how they perform compared to eachother. It is more if a comparison between MCU brands than core architechture, but still! :D

[BruceHoult]

Crazy to use only a single RISC-V board as representing a whole ISA. Obviously not all ARM cores or boards are created equal, and neither are all RISC-V cores or boards. Espressif doesn't even say in their datasheet what RISC-V core it uses. Crazy also not to include Sipeed Longan Nano ($4.80, 108 MHz, been around for three years), some Bouffalo lab BL602 board (similar price to ESP32s, we know it uses a SiFive core) or even extend the price limit a fraction to include a K210 board (dual core 400 MHz 64 bit) such as Maix Bit. Still, it is interesting to see that from the same chip/board manufacturer the RISC-V does in fact give better performance per MHz and per Watt than what they were using before. A really interesting test would be the Longan Nano (GD32VF103 clone of an STM32 but with a RISC-V core) vs either a GD32F103 (same manufacturer STM32 clone with a real licensed ARM core) and/or a real STM32F103.

[abdox]

I really love the black pill, actually currently I’m working on project using it (STM32F411CE), so glad to hear it did will in the benchmark, but Gray I have question
Did u write the program for each board in assembly or C ?
In case the answer C, then What compiler did u use for each one?
I hope didn’t throw up a lot of questions 😅😅.
Amazing work man, thanks a lot for this benchmark and I hope see more of them!!

[IamTheHolypumpkin]

I just bought my first RISC-V chip, an esp32-c3 from adafruit. Mostly bought it to learn RISC-V Assembly.
Generally want to learn AVR, ARM and RISC-V Assembly.

[magfal]

A huge factor for efficiency is compiler quality which grows with age.
The major design differences ariund efficiency is stuff like dark silicon for common tasks and SIMD engine implementation plus caches.

[marcusk]

Isn't the manufacturing process(how many nm) a major factor in power consumption?

[laci]

As I watch, I get questions, and as soon as they pop into my mind, Gary already responds to them. It's rare that a tech video is this well thought out and structured this well!

[fakecubed]

Gonna take a while for the RISC-V manufacturers to figure out how to design really great chips with it, but there's no reason not to expect it will be roughly the same as ARM in the long run, just with an open ISA which is an absolute win on its own. Hobbyists who aren't trying to squeeze every last bit of performance and efficiency out of their projects should support RISC-V to help it along and encourage faster development. It's already outpacing ARM's development, which was already quite rapid.

[ryan]

You also need to consider the code density. The firmware binary size is usually smaller using ARM cortex compare to RISC-V or ESP32.

[kayakMike]

Well... There are certain extras in your core implementation that will make a difference; stuff like the different caches and the coherency mechanism, the branch predictor, cpu internal bus and the bus arbiters, there's just so many extra internals that are all abstracted away in complex logic. Some of that complex logic is just more appropriate to implement in another program, i think some of the cpu caches are governed by a whole other "management engine" that runs its own firmware to keep track of the bits in the cache....