Closed
Description
Board
ESP32
Device Description
Adafruit ESP32 Feather
Hardware Configuration
No.
Version
v2.0.7
IDE Name
Arduino IDE
Operating System
macOS 10.13.6
Flash frequency
80 MHz
PSRAM enabled
no
Upload speed
921600
Description
I've compared benchmarks for three application programs running on the ESP32 version of uLisp, my Lisp interpreter for microcontrollers, and there's a big drop in performance between arduino-esp32 version 2.0.5 and 2.0.6 (the figures are execution times, so shorter times are better):
Version | 2.0.5 | 2.0.6 | 2.0.7 |
---|---|---|---|
Tak | 8.1 s | 14.2 s | 13.8 s |
Q2 | 21.2 s | 38.1 s | 37.2 s |
FFT | 241 ms | 416 ms | 408 ms |
As you can see from the figures, 2.0.7 is a slight improvement, but it's still about 70% slower than 2.0.5.
Is there a reason for these differences, and is there anything I can do about it?
Sketch
For details of the benchmarks see [Benchmarks](http://www.ulisp.com/show?1EO1).
Debug Message
There is no error.
Other Steps to Reproduce
No response
I have checked existing issues, online documentation and the Troubleshooting Guide
- I confirm I have checked existing issues, online documentation and Troubleshooting guide.
Activity
mrengineer7777 commentedon Apr 1, 2023
That's interesting. Not sure what your benchmark is doing, but I'm guessing it's processor bound work. The differences are probably due to updates in the underlying IDF.
mrengineer7777 commentedon Apr 1, 2023
It's also possible the compiler optimization flags have changed.
technoblogy commentedon Apr 1, 2023
Is there some way I can check that - I assume it's in the platform.txt file?
mrengineer7777 commentedon Apr 1, 2023
technoblogy commentedon Apr 12, 2023
Sorry, why is this closed? Is there no plan to investigate what's causing it?
mrengineer7777 commentedon Apr 12, 2023
If you can specify which library is causing the performance issue and can provide a simple code example to replicate it, then we can investigate. While interesting, your issue is not a bug and would take a lot of time to research.
technoblogy commentedon Apr 12, 2023
I've tried a pure C implementation of the first benchmark I used for the above comparison:
The calculation of tak(24, 16, 8) took exactly the same time (170ms) on 2.0.5, 2.0.6, and 2.0.7.
I'll have to think about what my Lisp interpreter might be doing that's affected by the different versions of the ESP32 core.
mrengineer7777 commentedon Apr 12, 2023
Sounds good. FYI I'm not an Espressif employee. I volunteered to help with managing their issues because they are way behind on issues and PRs. I have even fixed some issues by submitting PRs.
dragoncoder047 commentedon Apr 12, 2023
My guess from a user standpoint is that the arduino core runs freeRTOS background tasks and the uLisp evaluator calls
yield()
somehow (although I can't figure out where) allowing other non-uLisp stuff to run in the middle of uLisp execution. The C example clearly doesn't callyield()
so no tasks switch.@technoblogy if you want to get rid of this issue, I would maybe add a flag
NOYIELD
, and turn it on when in(time)
, and then only everyield()
if theNOYIELD
flag is cleared -- similar to callingtestescape()
and theNOESC
flag.technoblogy commentedon Apr 13, 2023
@dragoncoder047 thanks for the suggestions, but I think I've tracked down what the problem is. My uLisp interpreter periodically calls Serial.read() to allow the user to escape from a runaway program by entering the '~' character.
Here's a test program:
and here are the timings (the figures are execution times, so shorter times are better):
So the change in performance between versions of the ESP32 Arduino core could have something to do with the execution of Serial.read().
Changing the testescape() routine to:
makes the execution time for the test program 68 ms for all three versions; ie eliminates the difference.
Apologies that I reported this as a more general scare before fully tracking down what was causing it.
10 remaining items