V1.22 is very slow (Raspberry Pi Pico)

[ThHupk]

I have noticed that my programs are running almost three times slower than with previous versions of MicroPython.
What could be the reason and what can be done about it?
Here are the results of three different statements ( measured with ticks_cpu() ) :
v1.20.0 WeAct
1: 325330
2: 283260
3: 326694

v1.21 Pimoroni PicoLipo
1: 319496
2: 273826
3: 318965

v1.22.2 WeAct
1: 915635
2: 890955
3: 932455

v1.22.2 Pimoroni 16MB on PICO BOOT
1: 915580
2: 891191
3: 932501
The differences are so great that you notice it because you have to wait longer for the results.

[robert-hh]

Could you repeat the test with the actual 1.23 preview?

[projectgus]

Just to double down on this, one big change in 1.22 is that the rp2 port became tickless, meaning it doesn't automatically wake up every millisecond. This should give a slight increase in performance due to less time running the tick interrupt, but there may be bugs that cause it to not wake up at the correct time. One such bug was #13377 which relates to the UART and is fixed in the 1.23 preview releases (thanks to robert-hh, no less!) If your test code uses the UART, that's probably it.

If your test code doesn't use the UART, and the V1.23 preview build is also slow, then I'll +1 to @andrewleech's request below to please share some test code, or failing that a description of what your code does.

[andrewleech]

If possible can you also share some test code that creates these results?

[shariltumin]

Are you sure you ran the tests at the same processor speed?

Here is what I have on my Pico:

MPY: soft reboot
MicroPython v1.22.2 on 2024-02-22; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> import machine
>>> machine.freq()
125000000
>>> machine.freq(260000000)
>>> machine.freq()
260000000
>>> machine.freq(280000000)

[tio 15:46:32] Disconnected
[tio 15:46:35] Connected

Trying machine.freq(280000000) will cause my board to hang.

[ThHupk]

@micropython.viper
def funct(x):
    return x**2.5

from gc import collect, mem_free
from time import ticks_cpu

print(f'frequency = {machine.freq()//1e6} MHz')

collect()
mem_free()
L = []
t = ticks_cpu()
for i in range(8000):
    L.append(funct(i))
   
print(f'1: {ticks_cpu() - t}')
del L
collect()
mem_free()

t = ticks_cpu()
L = list(map(funct, range(8000)))
print(f'2: {ticks_cpu() - t}')
del L
collect()
mem_free()

t = ticks_cpu()
L = list(map(lambda x: x**2.5, range(8000)))         
print(f'3: {ticks_cpu() - t}')
del L
collect()
mem_free()

[projectgus]

@ThHupk I see you closed this as resolved. Did you fix the performance slowdown?

[mendenm]

Try something other than x**2.5. The math libraries were changed from the RP2 SDK CORDIC-based libraries, which were very fast, to ones from the MP code base, which are probably more robust, but much slower. The RP2 CORDIC math library was impressively fast. Also, for floating math, I doubt the viper declaration helps at all, since it still has to call the regular python libraries for the object retrieval and math.

[scruss]

...The math libraries were changed from the RP2 SDK CORDIC-based libraries, which were very fast, ...

Wait, what? The rp2040 ROM floating point routines (Mark Owen's Qfplib, used under licence) are about the only way to get acceptable floating point performance out of a Cortex-M0. If that had changed, everyone would be complaining about the speed

[mendenm]

I think this is implied in the release notes for 1.22:
https://github.com/micropython/micropython/releases/tag/v1.22.0

The rp2 port sees the introduction of a new rp2.DMA class for control over DMA transfers. It has switched to use the same math library as other ports to get more accurate floating point behaviour...

I did mean to ask the maintainers if it would be easy to maintain the ability to compile against the SDK, since it is REALLY fast. Any comments from the maintainers?

[andrewleech]

There was significant discussions around the floating point library change, it started from some bug reports about inaccurate floating point results in rp2.

See:

• Incorrect float values obtained from strings / program code with RP2 #13094
• rp2: switch math library routines to use MicroPython-provided ones #13119
• powf(10, -11) is not accurate raspberrypi/pico-sdk#1566
• rp2: Switch to locally provided math library. #13133

[scruss]

but these are the fault of the Raspberry Pi SDK, not Qfplib, right?

[andrewleech]

I'm not sure about the details myself

[mattytrentini]

I'm not too familiar with the details either, but you can read the tickets that @dpgeorge raised on the pico-sdk (Andrew linked to one of them).