🤦‍♂️😜 Darn. That was a stupid mistake! But I think you are right it feels like soooo long ago!

Apple's first iPad: April 2010

@@GaryExplains Future proofing the video, that's all

@@ZDevelopers Yea that's what I was going to say

It’s so sad hear that 😢

RISCV having open specs should make software catching up easier than for arm no?

@@markhaus Yes and no. Availabillity of documentation is greatly simplyfying a port to a new architecture, especially when there is already a port to a simila architecture. It still remains a major underrtaking in terms of manhours required. Been there, done that. Three times 🙂 As far as software development is concerned, x86, MIPS, RISC-V, MIPS, ARM are open enough to aloo development of dcent software. IA-64 was special in that it's performance characteristics are ... complex. without NDA or possibly even being Intel it was not possible to certain software including high-end compilers. The level beyond that is licensing for the architecture itself to develop a core by anybody who wants to. RISC-V didnt really inovate there, there have been other such public domain or similarly unrestricted architectures before. But they were the first polished architecture with academic and industry acceptance, documentation and very liberal licensing on top. It's this mix (and probably a few more things on top) which made the rise of RIsc-V possible.

It’s not just about the people who designed the RISC-V ISA it is also about the people that implement it, they are the ones that actually determine the efficiency and clock speeds and similar.

@@markhaus Yes and no. Programming specs are open for most architectures though the degree of detail varies. On the example of Intel, Intel CPUs accept only a signed blob as microcode and the microcode programming interface is not even documented. Probably few users care. More painful was Intel's attitude towards protecting the IA-64. The Merced documentation covers four thick books printed on thin paper and is also available for download (1-click sign-away your soul acceptance of terms required ;-) but errata required and NDA and certain very deep secrets were only available under terms of a much stricter NDA - the most restrrictive I've ever seen. Finally some further aspects such as deep details on performance aspects of the pipeline which are essential for the ijmplementation of top notch code generators and compilers were not available outside of Intel at all. I don't want to single out Intel but just picken them as an illustrative example Companies very in their degree of paranoida, protectiveness and openness and corporate history and experiences are part of that. RISC-V may be an open architecture. That means the architecture is open. It does not mean an actual implementation is open. It is possible to implement a fully RISC-V-compliant processor under the terms of the RISC-V licensing conditions - great. Yet iI can keep the implementation as closed as a traditional microprocessor implementation from companies such as Motorola, IBM, Intel, AMD, HItachi, MIPS, ARM etc. The result may be something that executes RISC-V code just fine yet for certain aspects such as performance has to be treated as opaque, as a black box. As somebody who has ported Linux to MIPS it's been occasinally helpful to have access to the folks who did all the mental heavy lifting and wrote the specs. With a RISC-V compaliant core one may or may not have the same kind of access. for a particular project.

@@conorstewart2214 While this is correct one should consider the architecture defiinition of any processor architecture as something that sets the absolute limits of what's possible. A good implementation can reach for near 100% of that; a bad one will stay well below. With my MIPS experience I found the size of early MIPS and RISC-V cores which are somewhat comparable And the RISC-V implementation is much smaller in terms of transistors / gates which is an indication of how polished the architecture is. Ok,RISC-V had the benefit modern software tools to aid the implementation. Such comparisons across decades are bound to limp somewhat. An interesting aspect is how the RISC-V architecture is made up of several optional parts. Just to pick one example, an implementation does not need to have a multiplication or division instruction. They were looking at other architectures' pain points. MIPS was born as a super-fast RISC processor for super-mini computers, later workstations and servers. Nobody early on thoght of embedded computing. Such omissions are hard to rectify lateron in a clean manor. One point where RISC-V is brutally efficient is cost due to absence of licensing fees for the architecture itself. To some users that's the #1 aspect that matters.

Let me wind back the clock to the mid-80s to point you at the horrors of the Dhrystone benchmark which back then was more or less the canonical benchmark for integer performance. Even in the best case Dhrystone results didn't represent real world performance very well. Dhrystone wasn't only ignoring fp math entirely, its results also got more and more comically absurd as architectures got more sophisticated (caches and out-of-order made a giant difference) but also as compilers improved and started to "optimize away" part of dhrystone. The peak was rached when certain compilers started to recognice Dhrystone and applied Dhrystone-specific optimizations for almost arbitrary benchmark results - whatever marketing orders ;-) It gives me headaches to see parts of the industry are still using DMIPS decades after it's been throughly proven to be rubbish. (It seems many folks don't know these days - the D in DMIPS stands for Dhrystone).

@@ralfbaechle Thank you for this informative comment. One learns something new everyday.

It's an artificial value though and not very helpful for real world performance comparisons. I know this because Qualcomm quoted quite a high DMIPS for their Krait CPU core back during the ARMv7-A generation, and it routinely got thrashed by the lower DMIPS rated Cortex-A9 based SoCs in actual performance.

Not just "black pill" but stm32f401 or 411. Today one mc on black pcb tomorrow another... And f411 has 12.7mA at 100MHz core with periph disabled. Not all periph is need to be on. I have doubts about this video test 20mA. The Chinese have a lot of analogues stm32. And for example CH32V203 (f103 clone with riscv core) has 8mA at 144MHz. CH32V30x ( riscv core with fpu) 12mA at 144MHz. And they have ever tssop20 case. As f103 clone CAN onboard, that f411 doesn't have. And 307 has Ethernet, 208 has bluetooth + Ethernet and 2.2$ in my local store. I have not been interested in buying stm32 for a long time. Only Chinese only like stm32 has CH32, HK32, AT32, GD32 and so on.

You're in the realm of potential compiler optimizations... And which process node these chips are made of...

arm & risc-v are nearly of same age. Sadly, only ARM got attention at that time.

I agree. RISC-V is not there yet but made a very good showing being the new kid on the block. ARM has been at this game for decades. It is unrealistic to expect the new kid to outperform the veteran. ARM has been optimized over decades. RISC-V has to pay its dues to take the crown. I am strong RISC-V advocate. I look at this as there is plenty of room for RISC-V to improve. The ground to cover in some areas are not that great to close the gap.

@@xade8381 that's not correct. ARM started to be designed in 1983 and the first chips and boards were in 1986. ARM the company started in 1991, when there were already 100,000 ARM-based Archimedes PCs in use. RISC-V started to be designed in Berkeley university in 2010 (27 years after ARM), the initial frozen spec was published in 2014, the first board you could buy commercially from the first RISC-V company was in 2016 (30 years after ARM).

@@xade8381 RISC-V was still an educational tool for years though, with zero plans for reaching any sort of market. Whereas ARM was made from the very beginning as a commercial ISA, and is 30 years older to boot. Not very comparable.

My pleasure!

the one and only legendary Gary Explains.

Why are so many of the commenters here so obsessed with process node? It strikes me that many (not aimed at you in particular Mark, sorry) may just be reciting jargon without understanding it. Even a very old node such as 180nm is good enough for making a 300+ MHz chip (e.g. the SiFive FE-310 on many RISC-V microcontroller boards) which is plenty for anything in this test. Smaller process nodes do allow higher clock speeds, but if you're not USING that ability then they are not just a waste of money in the much more expensive design and manufacturing process, but they may actively be WORSE because of things such as higher leakage current when operated at low clock speeds or in low power sleep modes. It's also a complete waste when you're making a simple stand-alone chip such as a microcontroller with a small core and a small amount of SRAM because even with the old nodes you end up with the actual processor&memory being a tiny little square inside a huge bit of silicon with the I/O pin pads taking up 90% or 99% of the extremely expensive small process node chip area. The default assumption unless you're a real expert should be that the manufacturer has chosen the best process node to optimise what they want to achieve with their chip.

We are familiar with needing to sample the test code many times to generate benchmark results which are not misleading, but it is also essential to sample different kinds of test code, to not be misled even by random compiler differences on each bit of code tested. With the performance results between the esp-c and the black pill coming within 1% of each other, that suggests the test was entirely memory bound on those systems and the systems share very similar memory systems. Multiple programs need to be benchmarked for a picture to emerge.

@@BruceHoult In general I would think that a smaller feature size would mean less parasitic capacitance, but I didn't think about leakage current. Is that from quantum tunneling? I wonder where the sweet spot is for that. But there's also the matter of different topologies like finfet and gaa, that might reduce the switching current. Mostly I think it's an economic decision. Everybody wants better speed and battery life, but how much are they willing to pay for it? For a computer that only runs a single program continuously, all you need is "good enough". Microcontrollers often have external power anyway. The main concern vis a vis power consumption is cooling.

I think 'process node' probably has a huge influence

What news are you referring to? Also, did you see this video of mine? ukposts.info/have/v-deo/f6mIrZ-ieWiZp6c.html

@@GaryExplains Talking about an efficiency specific comparison.

Sounds like a great plan. All are good ISAs. If you have any questions the Reddit /r/asm forum is pretty good for any ISA, and /r/avr and /r/riscv are helpful too. Sadly, /r/arm seems dead and/or non-technical.

I talk about RISC-V's potential in my RISC-V series.

@@GaryExplains indeed you did! Quite a few as well ukposts.info/slow/PLxLxbi4e2mYFTkLsNYqWLrSQZtLB94wnY

They are for 5v. But they are all 5v (i.e. for all the boards). I have the 3.3v numbers are well, but of course it changes nothing, just smaller numbers.

@@GaryExplains so all these chips run at 3.3V natively? Fair enough

@@AbelShields some chips use lineal voltage regulator (5V to 3.3V) some - switching voltage regulator (at least Raspberry Pi Pico with an RP2040). Switchers waste way less power (probably 92% efficiency for regulator, 94% efficient reverse voltage protection, 85% in total vs 64-66% in total with lineal one)

Indeed, it is something I will note for future videos. As for this video the key is that the Arm Cortex-M4 is using 90nm and the RISC-V ESP32-C3 is on 40nm, which makes the performance of the RISC-V processor even worse.

@@GaryExplains Wow that's very telling. Thanks Gary!

Also the area of the chip also should be a criteria

Glad you liked it!

Or better still watch my previous video on this topic where I actually changed the clock speed of the Pico and measured the power usage.

Active power is proportional to Vcore^2 * frequency. Not frequency squareq but just frequency multiplied by core voltage squared. You may get around frequency squared when cores are pushed harder than above mentioned microcontrollers (not as hard as full boost latest Intel or AMD chips, frequency still has to be supported by changing core voltage).

@@volodumurkalunyak4651 The formula I remember from university is proportional to voltage and to frequency squared (P ∝ V * f^2).

@@leonardosabino2002 i literally wrote the very same formula: Vcore^2 * frequency power is proportional to frequency and to voltage squared. Power scaling does also resemble frequency squared at some part of volt-frequency curve (probably 0,7 to 1V region for latest chips)

@@volodumurkalunyak4651 Not the same formula. Look again, it's the -frequency that's squared.- EDIT: I just looked up the formula, looks like voltage squared is correct. Sorry about that.

The test didn't use the USB ports.

No comparision. Atmega328 is an 8-bit processor.

I mean in context of cmsis which includes dsp and many things

The difference is that STM32 is from a company, i.e. STMicroelectronics, to support the ARM chips they make. RISC-V is an architecture, so you need to pick a company and see what it provides. The Espressif chips seems to have a mature development system for all their processors including Arduino support.

Also, CMSIS is an Arm thing, from Arm itself.

What about DSP math tools, QMath, and feature like this, are they included in the Espressif ?, is there nice youtube session to give me overview. I review that last time (1-2 year ago) but not confident with IDE setup that seen so far

You appear to have detailed requirements, and I'm not sure I can provide a thorough response that fully addresses all of your questions. It might be best for you to reassess these platforms to determine if they align with your needs.

The Arm one is on 90nm, the RISC-V on 40nm.

x86 chips can only run Arm and RISC-V programs using emulation. The opposite is also true.

There is also a compact version of arm called thumb which offers higher code density.

You aren't doing anything around your house that requires more than a lemon battery's worth of power. What you would need, though, are low power drivers for your network, which are hard to get, it seems. Just use whatever works and plug it into the wall. Who cares about a couple of Watts of extra power consumption.

And on the 3.3v pin?

@@GaryExplains Yes cheap LDO Voltage Regulator like the AMS1117 consume power even when no voltage is converted by it. this is called "Quiescent Current" and can be found in all LDO datasheets. For the AMS its between 3 - 10mA and is the main reason why cheap EPS32 boards consume above 1mA when in deep sleep. There are better one available but they cost 60 cents not 6 cents. I had to find this out the hard way when when designing a battery powered ESP32-S3 board. Its enough to have 3V3 on the output pin of the LDO for this current to flow from the 3V3 output to GND through the LDO chip. its a kind of leak current. an easy way to fix this is to just desolder the LDO and power it directly with 3.3V on the 3.3V pin

Thanks for the info, very helpful. 👍

@@GaryExplains no problem ;] power consumption is a bitch x]

They are too fare away to be compared.

e-cores aren't efficient whatsoever

Ah, it can't be compared. Atom is an x86 cpu, and it depends on how the cache and fsb are set. Arm chips usually operate at max 0.5 volt atom can go up.to 2 volt on turbo so is definitely diffrent clas of cpu ah why not against an ia64 cpu lol 😆 wanna se that race 😆

@@adriancoanda9227 In the end what makes the difference between slow and fast, is 99% software. I would win that race if I am the programmer : would use inline assembly, lookout tables with pre-computed values, would not miss the caches with visibility list, local goto.... Sofware always wins.

@MarquisDeSang not always. It still needs hardware to run on y saw some remastered games to be used via the browser chromebook target it ah tnd that launcher looped 2 gb of data but target just on cpu core so the loading screen took 10 minutes search for ah y like to see you in quantum pc your thinking won't apply there cause it is not a digital cpu is analog and capable of insane parallel computing and it exists already a portable one withou a transmission it won't run any apps like you are used to, 😉

Yes, of course, but that doesn't change the relative results, does it. What exactly is the point you are making?

@@GaryExplains yes it does change relative results. Rpi pico does have a switching regulator not lineal one that outher boards have.

If we read the same article it says that Apple is using RISC-V for some of its small co-processors, that is all. It is a good engineering choice, if it has to design bespoke hardware blocks then RISC-V is a workable solution.

@@GaryExplains Maybe but that Article had some text about moving to RISC-V that Apple might be considering. Moving to RISC-V would benefit Apple in long-term as they wouldn't have to keep paying ARM for royalties or whatever deal they have with ARM. What's your take on this?

No, that part was just pure speculation because otherwise it would be a boring article and no one would read it.

@@GaryExplains ok, thanks for clarifying.

LOL, other people complained when they thought I was using floats (as some MCU's don't have an FPU). I just can't win. UKposts comments for the victory! 🤪

Outside of very specialised areas, almost no software uses floating point on desktop computers, let alone on microcontrollers! I've been programming professionally for 40 years and 99% of C programs I work on don't even have the word "float" or "double" in them. Gary's previous "Primes by division" benchmark was quite unrepresentative of normal programs, but this one sounds pretty good (I don't know if the actual source code is available?) so I for one applaud this change.

@@BruceHoult "almost no software uses floating point on desktop computers" u wot mate ? Browsers and games are "almost nothing" ? Though to be fair, I don't know much about other software, but I'd be surprised if these would be the only major ones. Still, I'd also say it's kind of irrelevant what desktop-level software use and then compare to what MCU-level software uses.

@@Winnetou17 "outside of very specialised areas". Games and browsers are specialised. A lot of people run them, it's true, but they constitute a very small proportion of the lines of code written or programmers employed.

Bruce, the code to Oceantoo is in my GitHub repo, there is also an accompanying video here on this channel.

While I agree that it isn't necessarily linear, as far as I know that is only if the voltage changes with the frequency. In my testing I didn't only use extrapolation, I did clock them (where possible) at the same freq and the results correlated with my extrapolations.

There is actually even more fun stuff here: The chip has 2 PLLs; it sets one to 48MHz for USB, and one to 125MHz for CPU and bus clock. 125 is also much more manageable to get useful clocks for other peripherals as you said. You can also push the pico MUCH further than what it is specced for. I have run complex programs with PIO and PWM at 300MHz just fine running from RAM, and ~250MHz when running from XIP.

Sadly, no.

I wish that as well, but I ordered an S3 boards weeks ago, but it hasn't arrived yet. Having said that I don't think the performance will be any different. I will include the S3 in my dual-core power/perf showdown video.

Some feedback on your feedback: - I did that in the previous video on MCU power efficiency. - The goal was to show the current state of RISC-V MCUs and to debunk the myth that just because a processor is RISC-V, it somehow means it is inherently better. - I covered that in the video and made the same point myself, did you miss that segment?

@@GaryExplains Thanks for your reply, I had not seen the other video. Your graph at around 12 mins shows what I mean. For instance, at 240 MHz, rpico consumes 0.16 mA/MHz, while at 50MHz, it consumes 0.26 mA/MHz. Similar results are seen for ESP32. If it was linear, it would be the same number. That's actually a larger difference than I thought it would be. It is counterintuitive, but I believe MCUs tend to be more efficient at higher clock speed (likely up to a certain threshold). Hence, comparing the energy usage at different clock speed seems to favor the boards running at higher clock speeds. If the goal is simply to show that a risc-v chip can be less efficient than an arm processor, it is achieved, but then IMO, the title "Arm vs RISC-V? Which One Is The Most Efficient?" is a tad misleading, I was hoping to get a comparison of efficiency of risc-v compared to ARM, which would need to control the other parameters (especially the technology node, since it is likely a huge factor). Still an interesting video nonetheless. You did mention it in the video that you measure the board current. Depending on what's on the board this may have a huge impact. I now had a quick look at some schematics and it looks like the boards are quite bare (though I'm not sure what's the exact board you use in some cases), so it may not be that important in the end. One thing I noted though is that most board use an LDO while the Pico apparently uses a DC/DC converter. Boards that use an LDO should indeed have the same current going in 5V as in 3V, however this should not be the case for the DC/DC converter. Efficiency of those LDO is 3.3/5 ~= 65%, while efficiency of the DC/DC converter of the pico is mentioned "up to" 90% (though this varies with consumption). This is an advantage towards the pico board, not related to architecture. If you indeed measure the same current when supplying the pico from 3.3V, it is either because the efficiency of the DC/DC converter is actually 65% as well, or because there is some leakage to the DC/DC converter when there is a voltage applied to its output while its input is floating (which is possible since it is likely not an intended use case). Just to make it clear, I just wanted to provide some constructive feedback, I'm subscribed and enjoy watching some of your videos, I hope this doesn't come off as arrogant.

​@@FranzzInLove I agree; if the goal was indeed to compare the efficiency of Arm vs RISC-V, the best way to do it (aside from getting two different chips that are identical, apart from the CPU core - so same node, same class, same memory, same speeds etc.) would be to record the actual number of instructions executed for a given benchmark - i.e. the _dynamic instruction count_. This is the only meaningful number to look at when comparing one ISA vs another. Otherwise you're just comparing chip vs chip. And the direct comparison of cycle counts that was done in this video isn't realistic either, for the exact reason that Gary actually explained just before showing the comparison; memory systems are running slower than the cores themselves and often have a somewhat fixed latency when reading data (and instructions), so you'll typically waste more cycles waiting for memory when running the CPU at a higher frequency. So Gary: nice try and I really appreciate that you focus a bit on my field (MCUs) as well, but for this particular comparison it could've been a bit better - at least from a "comparing ISAs" point of view, from a "comparing MCUs" point of view it was great! :)

What has booting from nvme got to do with the efficiency of RISC-V?

@@GaryExplains just a big improvement on visionfive 2 board efficiency’s. Not Risc-v specific. Currently no soc boards have nvme boot up and processing, not even raspberry pi.

Nvme boot doesn't improve efficiency, it improves IO performance, which isn't related to RISC-V in any way.

Also, I have a VisionFive 2 board, and looking at it there doesn't seem to be support to boot from NVME.

I was just thinking the current measurements aren't very useful because of all the extra stuff on a lot of those boards. Plus the esp32 are not known for low power. You would have to compare active current with the idle current of each board.

Yes the delta power should show the true cpu energy used for the benchmark, maybe Gary can follow up?

The tricky thing with a delta number is that a CPU can never actually be idle. Even doing nothing is still looping and reading instructions waiting to no longer be "idle". To help in this situation there are two general solutions. 1. Lower the clock frequency and the voltage. This is something that smartphones and laptops do. 2. Put the CPU to sleep, this is a feature MCUs tend to have and it is similar to 1 but not dynamic.

@@GaryExplains thanks for replying. The motivation for the delta is to see the difference between the dynamic power consumption of the cpu architectures. I take the point that the cpu is never really idle, but I the case of MCUs, it should be at least the cores are idle, or running noops. I think the data would be interesting nevertheless. Idle power in itself would be interesting, so all 3 data points tells a story, idle, full load, and 'full load - idle'. Its quite surprising that a 22 year old design/process can still beat a 2 year old one.

I will look into this more and see if it is interesting enough for a follow up video...

The cryptographic co-processor in the C3 accelerate very specific algos (SHA and AES), and need to be expressly enabled in code through C headers as well as through the NVM configuration. His crypto algorithm is very custom(?), so I doubt it can even take advantage of the co-processor, let alone the fact that putting code forward that used co-processor on the C3 would kill compilation for all the other chips, since the header would have definitions for C3 specifics.... unless of course Gary was a complete A-hole and put #IF guards around that part of the code. (which would absolutely give the C3 and advantage.)

I think the general wisdom is that floating point code accounts for less than 1% of microcontroller code. So doing a test that focusses on floating point is inherently flawed.

​@@GaryExplains Where did you get that "general wisdom"? I know I've never seen it in my 30+ years of professional software engineering... Not saying it's incorrect, but in my experience it very much depends on the application how much floats are being used... Source? But even if it is correct, I don't think you understand how bad it really is. I actually did some benchmarks on the esp32 a while back, because I couldn't make heads or tails of the performance numbers. It has roughly 600 MIPS and just 1 MFLOPS (!) for common operations. That means that even if only 0.2% of your code is using floating point, it will consume 50% of your cpu power. It's that bad...

When I say general wisdom, I mean general wisdom, there isn't a particular source. However over the years I have seen multiple presentations that analyze real-world code and FP code is minimal, certainly on microcontrollers. That is why some microcontrollers don't even include an FPU, not needed really.

@@GaryExplains Right, and as I said, I'm no amateur, and I've seen a lot of issues with FP over the years. At the end of the day it doesn't matter what the exact percentage is: since FP is so much slower than integer operations (for obvious reasons), the effects on the application as a whole are still significant. Whether or not FP is required for applications at all is a totally different discussion. Again, such discussion is eventually irrelevant; the fact is that regardless if it's a good idea or not, people use it for everything from motion control to PID loops and from UI's to signal processing. That is why there's a tendency for vendors to add an FPU: because it is needed. ESP, STM32F4 seem to agree with me. The RP2040 does not have one.

What do you mean by "specifically tailored for RISC-V"? What alterations do you want in this RISC-V specific version?

@@GaryExplains Thank you for your response. By "specifically tailored for RISC-V", I meant a version of the Python interpreter that's been optimized to run on RISC-V architectures, taking advantage of its specific features and instructions. Just as we have optimized versions or builds of software for different platforms or architectures (e.g., ARM, x86), I was wondering if there's an equivalent for RISC-V. Essentially, Any version of Python that might offer similar performance or other benefits when running on a RISC-V system.

Hmmm... I am not sure that Python has special optimizations for different architectures. I just downloaded the Python source code and I see very little code that is optimized for say SSE3 or SSE4 or AVX. There isn't much assembly language either. I see a little bit of x86 ASM code in one of the math libraries, but there isn't an equivalent for ARM64. It is just C code in general. 🤷‍♂️

@@GaryExplains Thanks Gary.

Languages such as Python defeat the purpose of efficiency.

The processor is shown along the x axis.

ARM has not announced anything of the sort. You are repeating a rumor published by the FT.

@@GaryExplains It came from Softbank, the owner of ARM. Let us wait and drink tea. Maybe it is a hoax.

Again, nothing official has been said by Softbank or Arm.

Let us wait and drink tea. Btw. Enjoying most of your content. Great channel.

@@michaelkaercher I am waiting and drinking my tea while the attention trolls on UKposts keep asking me for all the love they didn't get from their Moms. :-)

Transistor count doesn't correlate in any meaningful way. It won't help you decide what size battery to use etc. Power usage is the most important thing, everything else is just statistics.

How would you suggest I resolve those issues?

@@GaryExplains Actually I didn't finish watching when I commented, I see you ran all of them at 1MHz later to level the playing field and I assume system bus was dropped to 1MHz also and that's a first important step. I would run all of these CPU cores at the system bus speed of the lowest common denominator system bus speed. The second step is to link to run the code out of SRAM instead of Flash on all of them. That's probably the best you can do to isolating core performance efficiency.

Indeed. I think it is my favorite Cortex-M processor!

Of course it is proportional to clock frequency.

Hmmm... If you look at my previous video about microcontrollers you will see that I actually did change the clock speeds. While it isn't linear it is very close.

You think microcontrollers have branch prediction?

@@GaryExplains .. not yet, and hopefully never! I agree on the microcontroller front RISC-V is no better than the Pi Pico spec. It's also less RISC than the pico.. The low end RISC-V spec now includes basic, MMX level integer SIMD, probably FP SIMD when it's finalised then extended, so quite bloated compared to Pi Pico ISA. -- I'm an ARM fan but think the High End RISC-V spec is a better idea (Vectors vs fixed sized SIMD).. Risc-V is an ARM killer, X86 never was... ARM is still the most likely X85 killer but Intel and AMD will probably race to replace X86 with native Risc-V and emulated X86. 10s to 100s of smaller SOC designers and manufacturers will obviously also prefer Risc-V. -- Sadly ARM's days are numbered. It may well have to abandon its ISA and many core implementation details when it too goes Risc-V.. Open Standards are very powerful forces.. Look at IBM PC, HTML + CSS, Unicode. For better or or worse, these royalty-free technologies alays dominate. -- I actually prefer 2 byte opcode ISAs using a few tricks and vector processing over SIMD. de-bloats the cache and pipeline. Risc-V is getting more bloated despite its lack of SIMD. Too many cooks spoiling the broth will be the reason Risc-V fails, if it does, which it probably won''t. A (US) Big Boy could buy out the project I suppose, and ruin or bury it, but that's unlikely too.

"Some of these chips have a lot of functionality to improve performance per watt which isn't supported by Arduino HAL" - Could you please give me some examples.

@@GaryExplains You can shut down the ESP32s entire radio circuitry if you have access to the low level registers. This saves a lot of power even when the radio isn't being used. If you have access to clock multipliers on the STM chips you can tune them to give lower power consumption too. Your encryption algorithm may be able to take advantage of encryption hardware on some of the chips which would make a big difference but the HAL won't necessarily take advantage if it.

Well, you can shutdown the entire radio circuity using the Arduino HAL. In fact I tried that, and said so in the video. Switching on low-power idle modes isn't relevant to this test. Also I used my encryption algorithm as a example of a heavy CPU load, it doesn't matter that it is about encryption. In my previous video I used finding primes and in my next I might use nqueens. It isn't about using special HW encryption blocks, but about testing the CPU.

@@GaryExplains Turning off the radio is not a low power idle mode it is just turning off the WIFI circuitry when the application doesn't require it. The rest of the chip runs at full speed and full power. It gives a better apples to apples comparison when testing say STM chips with ESP. Like when people compare the PI Pico to others ignoring the programmable IO which is it's most unique and powerful feature.

Hmmm... I seem to be repeating myself, one more go I guess: You can shutdown the entire radio circuity using the Arduino HAL. In fact I tried that, and said so in the video.

Low-power variants of M4 have reduced performance, especially in DMA and Bus Matrix as they have been simplified (in order to maximize battery saving and system power consumption under green something) compared to workhorse F4 with better parallel architecture in DMA and Bus-Matrix. The reason for M0+ from M0 is that interrupts have been proven to be too limiting in the past, where M0+ relieved some of this issue.

Why? What will it give you that x86 or Arm don't do/have?

@@GaryExplains A useful PC instead of a developer Board that cannot do my averyday work with a open ISA AND a Open Source OS like Linux. X98_64 or the ARM Cors are not free.

@@Schutti73 When you say free, what do you mean?

But the point is the power efficiency per MHz, which is what I showed. I don't think you understood the video.

Did I not say that?

​@@GaryExplainsyeah, sometimes I type out my thoughts before I watch the whole video. You did great.

Really? You understand that only the document describing the instruction set is open source. What advantage does that give consumers?

@@GaryExplains Pls read (even in google) why riscv and open instruction set is so important.

@@mementomori1868 😂 Or please watch my videos as I have several about RISC-V and what it really is.