MicroPython Forum (Archive)

Since my recent figures were all collected with firmware built locally on my PC I cannot exclude that that could be a cause of the performance differences, even though I use a build-script for consistency.
So I decided to redo the tests with 'standard' firmware from the Download section of this site and a PyBoard 1.1.
Most tested versions (1.16-2, 1.16, 1.15, 1.14, 1.13) give around 1750 pystones/second.
Some 'unstable' versions (1.15-222 and -229) give a few percent more: around 1800.
So I have no firm point to raise an issue...

Would you mind to post the script used for testing. Then I can repeat the test here.

I have no script for testing: I simply run pystone_lowmem.py on the target after loading a firmware version.
I do have a Python script to build firmware for several ports, is that of interest to you?

The first run showed numbers in the range of 1200, further builds moved to ~2500. But nothing in the range t 4000.

Just to be sure about my results I reran pystone_lowmem on a Teensy 4.0 with MP firmware 1.15-216. Below a screenshot of my terminal program:

You may notice that I us 5000 for the number of loops.

No major change. i have built v1.15-216. Pystone values ~2800.
V1.16-3, Values at ~2300.
Plain Makefile. Double precision float. With single precision float the numbers for V1.16.3 are ~2800.

Just rebuilt a few earlier versions (1.15-221/220/215/211): all result in around 2625 pystones/second.
But versions which I built 3 days ago (1.1-216/184) perform at around 4250.
I noticed a difference in filesize too: today all 728.9 KB, those of June 18: 708.8 kB.
I did not see updates of the tools in these 3 days, nor in my config. Maybe in Makefile(s)?
Looking at the difference in performance it would be worthwhile to find the cause.
BTW Essential for the figures is an accurate timer, could that be the culprit?

The timing should be fine. In my tests it said it lasted 2.1 seconds, and that matches the observation. At a figure of 4200 it was 1.1 second, and that's a noticeably difference.
I was considering whether the fast speed was a lucky memory layout which makes best use of the cache. The difference between code executed from cache and non-cache is a factor of ~3. So it can make a huge difference. Cache is enabled, but it is not really large.
Running the same test with my PR for SPI support brings the figure down to ~1300, even if SPI is not used. The SPI image is even larger.

@RobH The speed drop comes with commit bbdc98f72, from version 1.15-182 to v1.15-183, causing the pystone numbers to drop from ~5500 to 2300. But that commit "just" add most of the Python features. Nothing that is really needed for the pystone test. It increases the code size quite a bit from 195552 to 275520 bytes.
Very strange!

Edit: About the timer. When I lazily run from the linux terminal

time mpremote run pystone_lowmem.py

The runtime shown by time is about the same as reported by the code. Just ~100ms difference, which is fine for code loading and compiling.

@Roberthh Good that you found a significant speed drop from version 1.15-182 to v1.15-183.
Still some (but not all) later versions like my 1.15-216 perform at 4248 pystones/second as my entry of June 21 shows. There must be an explanation for the differences.....