ESP32-S3 maximum PSRAM/FLASH throughput.

[Malishev]

It is not surprising, that the execution speed of many applications on esp32 is bound not by cpu performance as is, but by the code fetch speed. For "ordinary" esp32 it is bound by roughly 80mhz bus speed * 4 qspi bus width = 40mbytes/s or 1/6 byte per clock at 240mhz cpu frequency.

For esp32-s3 seems things are improved quite a lot. Now it is 120mhz * 2 (ddr multiplier) * 8 (bus width) = 240mbytes/s or 6x improvement!

I wonder if this calculation is correct and this speed could be archived with existing esp-32s3 modules such as esp32-s3r8 or esp32-s3r8v ?

[ESP_Sprite]

It is not surprising, that the execution speed of many applications on esp32 is bound not by cpu performance as is, but by the code fetch speed.

That is an interesting assertion, especially as there's caching involved which in all but the most suboptimal use cases should give a pretty large speed boost. How did you conclude this?

As to your calculation: it is roughly correct. There's things to take into account like the behaviour of the aforementioned cache, as well as overhead because the psram needs some cycles to receive the address and prepare the output, but for a rough guesstimate, for pure psram/flash speed, you're probably not far off. How much that improves program speed is dependent on the program itself, though; for a fair amount of programs it probably won't improve things by too much as they already ran mostly out of cache.

[Malishev]

That is an interesting assertion, especially as there's caching involved which in all but the most suboptimal use cases should give a pretty large speed boost. How did you conclude this?

It is my biased experience based on ardupilot port. The whole fw is about 1-2mb and "hot" code size is at least 500kb. Cache is just not enough for it. IRAM is not much help either, cause "hot" code is not fixed but depends on flight mode, user settings, enabled features. Altogether this leads to unstable flight loop time.

Thank you for the information! Esp32-s3 looks very promising if it is correct. I hope it will be available soon )

[ESP_Sprite]

Fair enough, if you have a 'hot' code that is too large for the cache, you'll mostly be bound to the speed of the external interface indeed.

From what I understand, with the latest ECO of the ESP32S3, mass production should be ramping up now. It always takes some time between that and general availability, though, but I'd expect modules/devboards to appear fairly soon.