Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

How to handle optional compiler features in mpy-cross? #7653

Open
dlech opened this issue Aug 13, 2021 · 2 comments
Open

How to handle optional compiler features in mpy-cross? #7653

dlech opened this issue Aug 13, 2021 · 2 comments

Comments

@dlech
Copy link
Sponsor Contributor

dlech commented Aug 13, 2021

This is something I've come across a few times before and looking at #7649 got me thinking about it again.

A single mpy-cross executable should be able to build .mpy files that run on any MicroPython port, including customized ones. However, not all ports support all features.

Examples:

  • On a port without floating point support, running a .mpy file with floating points can cause a crash due to invalid CPU instruction. This is particularly subtle with the / operator and integers.
  • There are some options, like MICROPY_PY_BUILTINS_SET that affect the compiler output but may be disabled in a port which will fail to process the bytecodes.
  • py: Implement partial PEP-498 (f-string) support (v3) #7649 is probably a little different in that the compiled .mpy would run fine since it basically transpiles the code to something else, but if the same .py source was copied to a device and tried to compile on a device without f-string support enabled, then compiling the same file would fail there.

So what I'm wondering is if it is reasonably possible to add more options to mpy-cross like -mno-unicode to basically make mpy-cross give the exact same compiler output as any given MicroPython port? I.e. -mno-float would cause mpy-cross to give a compiler error if floats were used anywhere instead of successfully compiling the program.
@dpgeorge
Copy link
Member

Related to this, and looking at it from the opposite point of view, I think it would be good if mpy-cross had fewer options, and .mpy files containing just bytecode (ie no native/machine code) should be able to run on all MicroPython targets. I think it's quite easy to remove the -mno-unicode option. -mcache-lookup-bc is harder but possible to eliminate if ports that have this caching option enabled expande bytecode loaded from .mpy so it has slots for the caching (also requires adjusting jump offsets).

@jimmo jimmo mentioned this issue Aug 18, 2021
Closed
@dlech
Copy link
Sponsor Contributor Author

dlech commented Aug 18, 2021

Fewer options makes sense from a maintenance and just keeping things simple point of view. So I guess the solution for catching things at compile time rather than at run time would be an external static analysis tool.

dpgeorge pushed a commit that referenced this issue Sep 16, 2021
@jimmo @dpgeorge
all: Remove MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE.
b326edf 
This commit removes all parts of code associated with the existing
MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE optimisation option, including the
-mcache-lookup-bc option to mpy-cross.

This feature originally provided a significant performance boost for Unix,
but wasn't able to be enabled for MCU targets (due to frozen bytecode), and
added significant extra complexity to generating and distributing .mpy
files.

The equivalent performance gain is now provided by the combination of
MICROPY_OPT_LOAD_ATTR_FAST_PATH and MICROPY_OPT_MAP_LOOKUP_CACHE (which has
been enabled on the unix port in the previous commit).

It's hard to provide precise performance numbers, but tests have been run
on a wide variety of architectures (x86-64, ARM Cortex, Aarch64, RISC-V,
xtensa) and they all generally agree on the qualitative improvements seen
by the combination of MICROPY_OPT_LOAD_ATTR_FAST_PATH and
MICROPY_OPT_MAP_LOOKUP_CACHE.

For example, on a "quiet" Linux x64 environment (i3-5010U @ 2.10GHz) the
change from CACHE_MAP_LOOKUP_IN_BYTECODE, to LOAD_ATTR_FAST_PATH combined
with MAP_LOOKUP_CACHE is:

diff of scores (higher is better)
N=2000 M=2000       bccache -> attrmapcache      diff      diff% (error%)
bm_chaos.py        13742.56 ->   13905.67 :   +163.11 =  +1.187% (+/-3.75%)
bm_fannkuch.py        60.13 ->      61.34 :     +1.21 =  +2.012% (+/-2.11%)
bm_fft.py         113083.20 ->  114793.68 :  +1710.48 =  +1.513% (+/-1.57%)
bm_float.py       256552.80 ->  243908.29 : -12644.51 =  -4.929% (+/-1.90%)
bm_hexiom.py         521.93 ->     625.41 :   +103.48 = +19.826% (+/-0.40%)
bm_nqueens.py     197544.25 ->  217713.12 : +20168.87 = +10.210% (+/-3.01%)
bm_pidigits.py      8072.98 ->    8198.75 :   +125.77 =  +1.558% (+/-3.22%)
misc_aes.py        17283.45 ->   16480.52 :   -802.93 =  -4.646% (+/-0.82%)
misc_mandel.py     99083.99 ->  128939.84 : +29855.85 = +30.132% (+/-5.88%)
misc_pystone.py    83860.10 ->   82592.56 :  -1267.54 =  -1.511% (+/-2.27%)
misc_raytrace.py   21490.40 ->   22227.23 :   +736.83 =  +3.429% (+/-1.88%)

This shows that the new optimisations are at least as good as the existing
inline-bytecode-caching, and are sometimes much better (because the new
ones apply caching to a wider variety of map lookups).

The new optimisations can also benefit code generated by the native
emitter, because they apply to the runtime rather than the generated code.
The improvement for the native emitter when LOAD_ATTR_FAST_PATH and
MAP_LOOKUP_CACHE are enabled is (same Linux environment as above):

diff of scores (higher is better)
N=2000 M=2000        native -> nat-attrmapcache  diff      diff% (error%)
bm_chaos.py        14130.62 ->   15464.68 :  +1334.06 =  +9.441% (+/-7.11%)
bm_fannkuch.py        74.96 ->      76.16 :     +1.20 =  +1.601% (+/-1.80%)
bm_fft.py         166682.99 ->  168221.86 :  +1538.87 =  +0.923% (+/-4.20%)
bm_float.py       233415.23 ->  265524.90 : +32109.67 = +13.756% (+/-2.57%)
bm_hexiom.py         628.59 ->     734.17 :   +105.58 = +16.796% (+/-1.39%)
bm_nqueens.py     225418.44 ->  232926.45 :  +7508.01 =  +3.331% (+/-3.10%)
bm_pidigits.py      6322.00 ->    6379.52 :    +57.52 =  +0.910% (+/-5.62%)
misc_aes.py        20670.10 ->   27223.18 :  +6553.08 = +31.703% (+/-1.56%)
misc_mandel.py    138221.11 ->  152014.01 : +13792.90 =  +9.979% (+/-2.46%)
misc_pystone.py    85032.14 ->  105681.44 : +20649.30 = +24.284% (+/-2.25%)
misc_raytrace.py   19800.01 ->   23350.73 :  +3550.72 = +17.933% (+/-2.79%)

In summary, compared to MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE, the new
MICROPY_OPT_LOAD_ATTR_FAST_PATH and MICROPY_OPT_MAP_LOOKUP_CACHE options:
- are simpler;
- take less code size;
- are faster (generally);
- work with code generated by the native emitter;
- can be used on embedded targets with a small and constant RAM overhead;
- allow the same .mpy bytecode to run on all targets.

See #7680 for further discussion.  And see also #7653 for a discussion
about simplifying mpy-cross options.

Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
@dpgeorge dpgeorge mentioned this issue May 16, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dlech @dpgeorge