Call background tasks only once per ms

[jepler]

run_background_tasks: Do nothing unless there has been a tick

To do this, we need the refactored tick (moved to supervisor), so that we can add the atomic flag setting in just one site instead of in all ports.

This improves performance of running python code on a samd51 34%, based on the "pystone" benchmark on metro m4 express at 5000 passes (1127.65 -> 1521.6 passes/second).

In addition, by instrumenting the tick function and monitoring on an oscilloscope, the time actually spent in run_background_tasks() on the metro m4 decreases from average 43% to 0.5%. (however, there's some additional overhead that is moved around and not accounted for in that "0.5%" figure, each time supervisor_run_background_tasks_if_tick is called but no tick has occurred)

On the CPB, it increases pystone from 633 to 769, a smaller percentage increase of 21%. I did not measure the time actually spent in run_background_tasks() on CPB.

Testing performed: on metro m4 and cpb, run pystone adapted from python3.4 (change time.time to time.monotonic for sub-second resolution)

Besides running a 5000 pass test, I also ran a 50-pass test while scoping how long an output pin was set. Average: 34.59ms or 1445/s on m4, 67.61ms or 739/s on cbp, both matching the other pystone result reasonably well.

[dhalbert]

@tannewt will have comments about 1ms displayio frame rate resolution. He wants to achieve certain frame rates precisely which may not be possible at 1ms granularity

[tannewt]

It'd be nice to have more resolution for displays but that isn't urgent enough to block this.

I am a little worried this will impact USB performance though because it will increase the time between receiving usb data and queueing up another. Could we have the usb interrupt also set a run_background flag in addition to the tick doing so?

[jepler]

@tannewt that seems a good idea. Suggestions on naming an API that would trigger the background tasks to run as soon as possible?

[dhalbert]

Could be run_background_soon(). But I wonder if we should have a flag for each background task, instead of forcing all to run. So run_displayio_background_now, run_usb_background_now, etc. or something like that.

In other words, each thing that might want to run soon can ask that it itself be run, without affecting the scheduling of the other tasks.

[jepler]

The build failures are because not all MCUs support atomic operations on values of type bool, sigh. I will implement this feature in a way that does not require atomic_bool.

[tannewt]

I'd start with a single global to guard if they run at all. Most of them already do some checking to see if they need to run, it's just costly at the moment.

[jepler]

@tannewt is this USB interrupt something that exists now? If so, can you suggest what to search for? I came up empty.

[tannewt]

@jepler I think the USB interrupt is in TinyUSB although we could move it out.

Is this ready for another look?

[jepler]

@tannewt I think your assessment about the USB interrupt is right: as it's contained in tinyusb right now, we'd need some more changes before we can use it to trigger background tasks sooner.

It looks like I have some failed builds to attend to but they're shallow (use of ticks_ms global need to be converted to function calls), so it should be ready for stylistic checks.

Any suggestions on a way to benchmark the possible USB performance regression you're concerned about? That would be good to know before accepting this PR.

[tannewt]

I would just time a couple 100k transfer as a sanity check. Once this is merged we'll have more testing on it.

[dhalbert]

@jepler do you feel this is ready? I did a casual review already.

[jepler]

Testing on pyportal, sitting at the ">>>" REPL.

$ dd if=/dev/zero of=/media/jepler/CIRCUITPY/zero bs=512 count=200

Adafruit CircuitPython 5.0.0-beta.0
Before background changes, best of 3: 48.7 kB/s

Adafruit CircuitPython 5.0.0-beta.0-42-gbfdfe0e68
After background changes, best of 3: 48.4 kB/s

Difference: -0.62%, probably not statistically significant

[jepler]

@dhalbert If it passes CI this time, I think it's ready for review. I added the performance figures that @tannewt requested, and merged master (there were conflicts due to uart changes)

[kevinjwalters]

Has this been tested on an M0 board? I see no particular reason why it would not be fine, just thought I'd mention it in case CPX/Gemma M0/Feather M0 haven's seen this code...

BTW, does your test rx code on the Adafruit board confirm that the exact amount of data sent has been received? E.g. for your example 102400 received.

[ladyada]

@kevinjwalters wanna help test it? :) we have build artifacts over at
https://github.com/adafruit/circuitpython/commit/95d9c49e439cc4ba440ea737b57d03544bc952dc/checks?check_suite_id=335065792

[tannewt]

Looks good! Thank you!

[kevinjwalters]

Just ran adafruit-circuitpython-circuitplayground_express-en_US-20191129-7eea65d.uf2 up on a CPX. It runs ok. I copied a file (writes at about 80kB a second) from Windoze and that was ok. @jepler were you doing other read tests or just writes into the FAT filesystem?

[dhalbert]

On a simple loop, it's nearly twice as fast:

>>> import time
>>> def t(c):
...     start = time.monotonic()
...     for _ in range(c):
...         pass
...     print(time.monotonic() - start)
...
>>> t(5000)
0.0609741
>>> t(100000)
1.2301
>>> t(1000000)
12.351

>>> def t(c):
...     start = time.monotonic()
...     for _ in range(c):
...         pass
...     print(time.monotonic() - start)
...     
>>> t(5000
... )
0.0350037
>>> t(100000)
0.695007
>>> t(1000000)
6.92801

[ladyada]

@dhalbert wanna re-try that test that the person compared a samd51 with pyboard? we should be at near-parity?

[dhalbert]

We were half the MicroPython speed after the initial speed-up, so I think this is very close, if not now completely equivalent.

[ladyada]

@dhalbert yep, wanna re-run it on a samd51? or i can