Conversation
|
Today I saw turbo-cli tools in Tim's live Deep dive, and it does seems that this is the correct place or at least form that mpy-tool.py and mpy_ld.py should probably go to. Also, as discussed in last week's meeting, what I'm testing now is benchmarking. When I started the project I wasn't aware of turbo, but it seems like the code to bench against.
This simple ulab sqrt() is also a very good pointer to moving to rust for native C code, with that 17.85x result! Note: esp32-s3 sqrt() seems closer in performance. It looks that llvm just moves everything to vsqrt.f32 so it runs on hardware rather than software. |
|
@mikeysklar should see this too and coordinate wrt Turbo. Totally happy to have it work with a rust module too. |
|
fede2cr and I have been comparing benchmarks. The numbers from Rust are impressive. Another ~10x over turbo across the benchmarks. It looks like a rust or C compiled code will be many times faster than machine code that viper offers. I'm running some tests now of my own on this topic. More to come. |
|
I ran my own benchmarks on this draft: viper, C and Rust, same kernel, eight boards. C was fastest on six of seven, and its toolchain was the more dependable one. Rust stayed close
Some PR changes you will want to consider: The loader design does not use the emitter. Code is generated on a host, not on the board. The ESP32 PRs are merged, so you can rebase on main and drop that code. The M7 native enable needs its own PR. |
|
I would be interested in knowing what optimization flags are being used on rust and gcc. |
|
The flags play a roll. Switching from the CP default gcc flag for size optimization The above table was using optimized options like this: |
4 participants
Adding support for circuitpython.
Testing against fede2cr/cpy-rust-examples which include a very basic calculator + string managment as proof of concept, ports of (only as demos) adafruit_debounce and adafruit_ticks, showing that bundle modules can be ported. I have also ported pixels (viper demo) with perfomance of 4.6x for nrf, 4.77x for esp32-s3, and 7.56x fo M7.
In includes two new tools that need to be integrated into mpy-cross (probably), but for now are kept as separate tools to understand what is different while working on rust code.
The goal of this project is not enable rust inside of code.py, but for modules to be written in rust, compiled as .mpy files, copied to lib/ and imported and called like you would a circuitpython function.
As the basic demos and mandelbrot (pixel_rs) show, you have available data types for fp such as f32, f64, for ints like i64, u64, i128, plus structs, slices, enums, strings, etc.
Please help with benchmarking and add any opinions at all of usage, mpy building, ports you'd like to see, and help to get it out of draft PR mode.