Performance difference between 1.8.0.6 ESP32_REV3 and ESP32_PSRAM_REV3 firmware

[shodan8192]

Target name(s)

ESP32_PSRAM_REV3, ESP32_REV3

Firmware version

1.8.0.6

Was working before? On which version?

No response

Device capabilities

No response

Description

using System.Device.Gpio;

namespace Blinky
{
    public class Program
    {
        private static GpioController s_GpioController;
        public static void Main()
        {
            s_GpioController = new GpioController();
            GpioPin led = s_GpioController.OpenPin(25, PinMode.Output);

            while (true)
            {
                led.Toggle();
            }
        }
    }
}

Output frequency on pin 25 :

81kHz on ESP32_PSRAM_REV3
27kHz on ESP32_REV3

using System.Device.Dac;

namespace Blinky
{
    public class Program
    {
        public static void Main()
        {
            DacController dac = DacController.GetDefault();
            DacChannel dacChannel = dac.OpenChannel(0);

            while (true)
            {
                dacChannel.WriteValue(0);
                dacChannel.WriteValue(255);
            }
        }
    }
}

Output frequency on pin 25 :

4.7kHz on ESP32_PSRAM_REV3
2.5kHz on ESP32_REV3

What's curious, that replacing led.Toggle() with led.Write(0) ; led.Write(1) gives :

1.5kHz on ESP32_PSRAM_REV3
1.7kHz on ESP32_REV3

Mandelbrot fractal calculations (https://gist.github.com/shodan8192/1248f49a1d752e34a7abc42a668b0b0d) shows little general performance difference

7390ms on ESP32_PSRAM_REV3
7530ms on ESP32_REV3

How to reproduce

No response

Expected behaviour

No response

Screenshots

No response

Aditional information

No response

[Ellerbach]

Thanks for sharing @shodan8192.
Few elements: Toggling the pin is always faster as there is a hardware way of doing it directly. All other methods goes a longer way.
For the PSRAM vs non PSRAM performance difference, hard to comment why.

And question: any expectation or anything that you feel is broken here?

[shodan8192]

I'm just curious frome where this come from. It's more expected for me that the PSRAM build will be slightly slower.
While pin toggling it's not common use case, it's unknown to me where else that difference may shows up and why.

[josesimoes]

Converting this to a Discussion as it's not really an issue.

[josesimoes]

As you probably know, C# code it's interpreted at the MCU, so nanoFramework will "loose" in any comparison for toggling a GPIO pin with a raw implementation using pure C or C++.

For GPIO specifically, there is an extra wrapper to help manage the GPIO assignment that introduces some ceremony and, therefore, some delay when executing code that uses it. I personally am not very fond of it, but it was the way to handle the need to have reconfiguration of GPIOs from the code at boot time.

I agre with your assessment that execution from PSRAM should be slightly slower then a device running it from internal RAM. As the code it's the same from nanoFramework end, it's most likely something with the Espressif IDF that manages the memory access. I have no better explanation to offer about this at this point.

[shodan8192]

OK, that's fair enough. Regarding performance, these settings should adds nice boost :

CONFIG_FLASHMODE_QIO=y
CONFIG_ESPTOOLPY_FLASHFREQ_80M=y
CONFIG_SPIRAM_SPEED_80M=y

Probably not all boards can handle this, but maybe we can have additional build like ESP32_PSRAM_REV3_QIO_80M ?

[josesimoes]

I recall looking at those settings when going through the changes for IDF 4.4.
Do you know if there is a way to detect those at Runtime? I'm trying to avoid adding more images as this is already too confusing wiht all those options and variants.

[shodan8192]

Do you know if there is a way to detect those at Runtime?

you mean to detect board capabilities to run at those settings ? While PSRAM and flash chips id can be read, there's no way to check if those are correctly wired to ESP32 to support QIO, I think

[josesimoes]

Too bad... There are other configs that the bootloader can detect and adapt accordingly. These would be nice to have.
Thanks for the pointers and suggestions. Let's find a nice way to take advantage of these.