Commit Graph

7 Commits

Author SHA1 Message Date
Damien George c0761d28fc tests/perf_bench: Use math.log instead of math.log2.
So MICROPY_PY_MATH_SPECIAL_FUNCTIONS is not needed for these performance
tests.

Signed-off-by: Damien George <damien@micropython.org>
2021-09-13 18:27:39 +10:00
David Lechner 3dc324d3f1 tests: Format all Python code with black, except tests in basics subdir.
This adds the Python files in the tests/ directory to be formatted with
./tools/codeformat.py.  The basics/ subdirectory is excluded for now so we
aren't changing too much at once.

In a few places `# fmt: off`/`# fmt: on` was used where the code had
special formatting for readability or where the test was actually testing
the specific formatting.
2020-03-30 13:21:58 +11:00
Jim Mussared cfd17f4ebe tests/perf_bench: Add bm_fft test.
This is mostly a test of complex number performance.

The FFT implementation is from Project Nayuki and is MIT licensed.
2019-10-15 16:38:11 +11:00
Damien George 73fccf5967 tests/perf_bench: Add some viper performance benchmarks.
To test raw viper function call overhead: function entry, exit and
conversion of arguments to/from objects.
2019-06-28 16:30:01 +10:00
Damien George 73c269414f tests/perf_bench: Add some miscellaneous performance benchmarks.
misc_aes.py and misc_mandel.py are adapted from sources in this repository.
misc_pystone.py is the standard Python pystone test.  misc_raytrace.py is
written from scratch.
2019-06-28 16:29:23 +10:00
Damien George 127714c3af tests/perf_bench: Add some benchmarks from python-performance.
From https://github.com/python/pyperformance commit
6690642ddeda46fc5ee6e97c3ef4b2f292348ab8
2019-06-28 16:29:23 +10:00
Damien George e92c9aa9c9 tests: Add performance benchmarking test-suite framework.
This benchmarking test suite is intended to be run on any MicroPython
target.  As such all tests are parameterised with N and M: N is the
approximate CPU frequency (in MHz) of the target and M is the approximate
amount of heap memory (in kbytes) available on the target.  When running
the benchmark suite these parameters must be specified and then each test
is tuned to run on that target in a reasonable time (<1 second).

The test scripts are not standalone: they require adding some extra code at
the end to run the test with the appropriate parameters.  This is done
automatically by the run-perfbench.py script, in such a way that imports
are minimised (so the tests can be run on targets without filesystem
support).

To interface with the benchmarking framework, each test provides a
bm_params dict and a bm_setup function, with the later taking a set of
parameters (chosen based on N, M) and returning a pair of functions, one to
run the test and one to get the results.

When running the test the number of microseconds taken by the test are
recorded.  Then this is converted into a benchmark score by inverting it
(so higher number is faster) and normalising it with an appropriate factor
(based roughly on the amount of work done by the test, eg number of
iterations).

Test outputs are also compared against a "truth" value, computed by running
the test with CPython.  This provides a basic way of making sure the test
actually ran correctly.

Each test is run multiple times and the results averaged and standard
deviation computed.  This is output as a summary of the test.

To make comparisons of performance across different runs the
run-perfbench.py script also includes a diff mode that reads in the output
of two previous runs and computes the difference in performance.  Reports
are given as a percentage change in performance with a combined standard
deviation to give an indication if the noise in the benchmarking is less
than the thing that is being measured.

Example invocations for PC, pyboard and esp8266 targets respectively:

    $ ./run-perfbench.py 1000 1000
    $ ./run-perfbench.py --pyboard 100 100
    $ ./run-perfbench.py --pyboard --device /dev/ttyUSB0 50 25
2019-06-28 16:29:23 +10:00