Replies: 7 comments 2 replies
-
|
Another approach to passing 32-bit (rather than 30-bit) ints to a Viper or asm function is to populate a 32-bit integer array with the values and pass the array as an arg. |
Beta Was this translation helpful? Give feedback.
-
|
The one I had high hopes might work was SIO = const(0xd0000000)
@micropython.viper
def callback(_):
sio = ptr32(SIO)but even that involves a 700ns lookup. I assume the const substitution happens before the viper decorator even gets a chance to see it? On the subject of array() and bytearray(), if For me, this 100x difference really hammered home the importance of taking local pointers once at the start of a viper function, rather than doing any namespace lookups inside tight loops, as the documentation already cautions. I see that x[0] = 324
x[1] = 324
x[2] = 324takes 40ns whereas for i in range(3):
x[i] = 324takes 560ns and even i = int(0)
while i < 3:
x[i] = 324
i = i + 1takes 510ns, although luckily viper still doesn't need to allocate for the range(3). (Within viper, I don't think I need the int(0) there - it would automatically be int32 when assigned as 0?) It'd be interesting to build a debug version of the code emitters and see what they're actually doing here. I'll need to work out how, though... |
Beta Was this translation helpful? Give feedback.
-
|
Nice results! Yes, some of the workings of viper can be surprising. Did you see this page with more information about viper? https://github.com/micropython/micropython/wiki/Improving-performance-with-Viper-code
Viper integer constants are in the range -2**29 to 2**29-1. Outside that range, the constants are treated as
This is the same as
I would expect this loop to be much faster. Did you test this in the same function as While loops can be even faster if you compute the first and the last pointer and iterate until the pointer reaches the final value. That avoids using a counter. See here https://github.com/micropython/micropython/wiki/Improving-performance-with-Viper-code#range-vs-while
That's true. However a call to a Viper function is much faster than a call to a regular function. There are some restrictions: Viper functions do not accept keyword arguments nor optional arguments. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I found the documentation and started to dig through the emitnative.c code generator a bit too, although not yet figured out how to build a debug version of mpy-cross that debug logs the generated assembler from viper so I can experiment with its behaviour more directly. (I rather lazily started disassembling the relevant bytes of the .mpy file, but that's a horrific way to do it!) My measurement harness is as simple as from machine import Pin, Timer
import micropython
Pin(0, Pin.OUT)
@micropython.viper
def callback(_):
sio = ptr32(uint(0xd0) << 24)
sio[6] = 1
# Insert something here
sio[8] = 1
timer = machine.Timer(freq = 1000, mode = Timer.PERIODIC,
callback = callback, hard = True)where the block to test is pasted inline. (Obviously it can't use the predefined sio as that would be cheating.) Without any additions, this produces a 14ns pulse: essentially the two cycles to write sio[8]. I can offset the trigger to measure just the extra time added by the code spliced in. Inserting
I can't find any way to write the fast version that has the literal 0xd0000000 in it, nor any way to express addresses between 0x40000000 and 0xc0000000 faster/clearer than a shifted smaller constant. If python had macros or define-time/inline expanded functions, I could write a helper than takes a define-time constant and emits something that viper will optimise well, but sadly python is not scheme. Yes, I expected the while loop to be super-fast too, and I don't really understand why it's not. With no other code spliced in than: i = 0
while i < 4:
i = i + 1the loop over four values of i doing nothing still costs 390ns or about 59 cycles. i = 4
while i:
i = i - 1is a little bit better at 240ns but still not brilliant: I guess about 34 cycles? |
Beta Was this translation helpful? Give feedback.
-
|
Here's something a bit more precise. Maybe it's of use for testing: #!/micropython
# -*- coding: UTF-8 -*-
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
#┌────────────────────────────────────────────────────────────────────────────┒
#│ Viper timing measurements ┃
#┕━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
from machine import freq as cpufreq
from time import sleep_ms
_SIOBASE = const(0xd000_0000)
_SIOBASEHI = const(_SIOBASE >> 16)
_SIOBASELO = const(_SIOBASE & 0xffff)
_PPB_BASE = const(0xe0000000)
_SYST_CSR = const(0xe010 >>2) # SysTick Control and Status Register
_SYST_CVR = const(0xe018 >>2) # SysTick Current Value Register
@micropython.viper
def enable_systiming():
ppb: ptr32 = ptr32(_PPB_BASE)
ppb[_SYST_CSR] = ( (1<<2) # CLKSOURCE:Processor clock.
| (1<<0) ) # ENABLE: Enable SysTick counter
print('# All measurement in CPU cycles')
@micropython.viper
def test_timing1():
HIGH: uint = (1<<24) - 1000
ppb: ptr32 = ptr32(_PPB_BASE)
t0: int
t1: int
while (t0:=ppb[_SYST_CVR]) < HIGH: pass
pointer1: ptr32 = ptr32(_SIOBASE) # unnessessary slow
t1 = ppb[_SYST_CVR]
diff = t0 - t1
print(f'# {diff:4}', end=' ')
sleep_ms(100)
while (t0:=ppb[_SYST_CVR]) < HIGH: pass
pointer2: ptr32 = ptr32(uint(_SIOBASE)) # pretty bad, timing unstable
t1 = ppb[_SYST_CVR]
diff = t0 - t1
print(f'{diff:4}', end=' ')
sleep_ms(100)
while (t0:=ppb[_SYST_CVR]) < HIGH: pass
pointer3: ptr32 = ptr32((uint(_SIOBASEHI)<<16) | _SIOBASELO) # fast
t1 = ppb[_SYST_CVR]
diff = t0 - t1
print(f'{diff:4}', end=' ')
sleep_ms(100)
while (t0:=ppb[_SYST_CVR]) < HIGH: pass
x: uint = (uint(_SIOBASEHI)<<16) | _SIOBASELO # as is this
pointer4: ptr32 = ptr32(x)
t1 = ppb[_SYST_CVR]
diff = t0 - t1
print(f'{diff:4}' )
sleep_ms(100)
return
cpufreq(200_000_000) # won't change measurements
enable_systiming()
for _ in range(10):
test_timing1()
# All measurement in CPU cycles
# 184 849 24 28
# 184 345 24 28
# 184 395 24 28
# 184 446 24 28
# 184 347 24 28
# 184 295 24 28
# 184 194 24 28
# 184 346 24 28
# 184 446 24 28
# 184 347 24 28 |
Beta Was this translation helpful? Give feedback.
-
|
Nice, there's basically zero jitter in the overhead on your test harness. Saves firing up a scope! I added two extra columns, one for PS For me the RVR register comes up as zero so I added |
Beta Was this translation helpful? Give feedback.
-
|
Here's a slightly boiled down version which disables interrupts during the test: import machine
import micropython
@micropython.viper
def test() -> uint:
ppb = ptr32(-0x20000000) # PPB = 0xe0000000
ppb[0x3804] = 0b101 # CSR = CLKSOURCE | ENABLE
ppb[0x3805] = -1 # RVR = maximum
state = machine.disable_irq()
t0 = ppb[0x3806] # t0 = CVR
t1 = ppb[0x3806] # t1 = CVR
x = ptr32(-0x30000000) # Line to benchmark
t2 = ppb[0x3806] # t2 = CVR
machine.enable_irq(state)
# Difference between t1 - t2 and t0 - t1 masked with RVR:
return uint(t1 - t2 - t0 + t1) & ppb[0x3805]
print(*(test() for _ in range(20)))and some corresponding results for variants you and I have measured above: When I look at the initially puzzling difference between |
Beta Was this translation helpful? Give feedback.
-
|
Another curious factor with gpio timing is that: p = Pin(10)
p(1) # set pin highis actually noticeably faster than: p = Pin(10)
p.value(1) # set pin highThis is because in the second case there's a dictionary lookup internally to find the |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, and 420ish cycles vs 700ish cycles (a bit jittery): almost twice as fast as you say. I didn't know you could call pin objects directly like that! I wondered if I'd overlooked it when reading the documentation. The machine.Pin reference does mention Maybe I should cook up a docs PR? Another fun one I stumbled across: MicroPython interns strings, so comparing two strings in viper is cheap and constant time, as is comparing two pin objects (say). There isn't an [Edit after reading the code: no, comparing string reprs wouldn't be cheap like comparing objects is, because |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
While measuring jitter on hard vs soft IRQs on rp2350 with a scope, I got distracted into benchmarking different ways to do fast GPIO from a viper hard IRQ handler. I found the numbers interesting, so thought I'd post them in case anyone else is interested too.
As a baseline, with the default 150MHz clock frequency, if
pin = machine.Pin(0, machine.Pin.OUT), callingpin.value(1)from a viper function takes around 4us with roughly 700ns jitter.A more direct
mem32[0xd0000018] = 1takes about 2us with c. 500ns jitter.Of course, viper can write memory directly and this is much faster. If
siois a ptr32 to 0xd0000000, the directly equivalentsio[6] = 1takes only 14ns.But there's a little trap here: initialising
sio = ptr32(0xd0000000)takes 700ns! The same forsio = ptr32(13 << 28)orsio = ptr32(int(0xd0000000)). However,sio = ptr32(int(13) << 28)orsio = ptr32(int(0xd0) << 24)are fine and take just 26ns.Even though we're using viper, the argument to
ptr32()/int()is a python integer and if that's more than 30-bits we end up dereferencing an object. I understand why this happens but still managed to forget and end up surprised by it!Similarly, something like
ptr8(0)[0xd0000018]won't work at all because we're trying to index zero with an object not a machine int. However,ptr32(0)[0x34000006] = 1works fine and is fast at 40ns (= 14ns + 26ns).Final measurement: if we define
then calling
wibble()from another viper function costs 1.5us, so it can be quite costly to break up a viper callback in the absence of any way to create a define-time macro.Beta Was this translation helpful? Give feedback.
All reactions