Benchmarking MicroPython

This should not be used to conclude on the viability of using MicroPython for numeric type tasks. For that one should at least take into account the following:

Integers are much faster than floats (floats involve a pointer and a heap allocation, integers are stored in a single word/object).

array.array is preferred over list for something like sort. Continuous memory representation of numbers versus general purpose list of objects.

MicroPython has on-board "JIT" (native/viper emitters), have to explicitly annotate the function. Should give 4-10x improvements for this case.

MicroPython has an on-board assembler, so one can write ARM assembly and get that to a function.

MicroPython also has support for C modules, which expose a Python API. Including dynamic native modules which can be installed at runtime with the package manager.

Bubblesort is O(n*2), which hurts for even a few thousand numbers. Actual sorting on a microcontroller should be done with an O(n log n) algorithm.

▲

jononor 2 days ago | parent | next [-]

Ok, you guys have successfully nerd sniped me this morning... Here some experiments showing the use of code emitter to speed this code up massively. Link to code: https://github.com/jonnor/embeddedml/tree/master/handson/mic... The results on ESP32S3 (M5Stick AtomS3U), running MicroPython 1.24.1. All times in seconds, for the 2000 number sort.

bubble.py 19.119

bubble_native.py 9.482

bubble_viper.py 0.904

heapsort_viper.py 0.02

So one can do 100x better without changing the algorithm, and 1000x by changing it :)

Microcontrollers are a constrained platform. They can be plenty fast - but it is much more important to use the tools available, compared to on PC. MicroPython has excellent tools available for this.

	▲	jononor a day ago \| parent [-]
		EDIT: 20x better with same algorithm, not 100x. Do not post before the coffee starts kicking in...

▲

jononor 2 days ago | parent | prev [-]

If anyone is interested in fast dynamic native C modules for MicroPython, you can check out emlearn-micropython - a machine learning and digital signal processing library. https://github.com/emlearn/emlearn-micropython Disclaimer: I am the maintainer

▲

mbirth 2 days ago | parent | prev | next [-]

I'm missing testing the different emitters as demonstrated here: https://www.kickstarter.com/projects/214379695/micro-python-...

Not sure whether they're supported on all the architectures, though.

	▲	jononor 2 days ago \| parent [-]
		I have added this now, as a reply to one of the other posts :) 100x speedup.

▲

Archit3ch a day ago | parent | prev | next [-]

You can drop down to C and call it from MicroPython if you want to count cycles.

Of course, you have to recompile your C every time it changes, which is annoying when you're used to the REPL workflow.

▲

drewcoo 2 days ago | parent | prev | next [-]

Somehow, I don't mind that the code blew the stack because it was recursion without memoization. Blowing the stack should be a pretty clear sign to figure out why and fix it.

▲

mrheosuper 2 days ago | parent | prev | next [-]

Generate 2000 random numbers and sorting them using bubble sort on 160Mhz 32bit mcu takes 80 seconds ? This is exactly why micropython is a toy.

	▲	jononor 2 days ago \| parent [-]
		The same can be done in 0.02 seconds with MicroPython. I posted optimized code here, https://github.com/jonnor/embeddedml/tree/master/handson/mic...

▲

wewewedxfgdf 2 days ago | parent | prev | next [-]

As the author points out, performance is pretty much irrelevant - it is a rewrite of python prioritizing memory usage.

▲

zem 2 days ago | parent | prev | next [-]

would have been nice to see benchmarks against the equivalent c code running on the same microprocessor, not against micropython code running on different hardware. the post just told me that microprocessors are slow, not how well micropython performs.

▲

2 days ago | parent | prev | next [-]

[deleted]

▲

snvzz 2 days ago | parent | prev [-]

>pico 2w

ARM or RISC-V?