[FEATURE REQUEST] ESP32-S3 vector extensions

[cherrydev]

The ESP32-S3 microcontroller has a set of dedicated instructions for vector operations. Generally speaking, instructions can operate on 16 bytes, with variations for 1, 2 and 4 byte values. These intrinsics can either be used on their own, or via the ESP-DSP library. Adding support for these instructions could provide significant performance improvements for the ESP32-S3 microcontroller.

Documentation on the extended instructions are documented in sections 1.5 and 1.6 of the reference manual (PDF)and documentation for the ESP-DSP library is provided on their website.

[v923z]

Thanks for pointing this out! I'm not quite sure this would work, except for dense arrays. As far as I see, the point of these extensions is that you don't really have to deal with the array pointer, for that is incremented automatically for you, so you can save the hassle associated with it. But in numpy, you can have the dot product of two arrays that are sliced, where you would lose the advantage.

[cherrydev]

Couldn't all of the basic (integer) array arithmetic operations be accelerated with the ESP32-S3 SIMD arithmetic instructions? I realize now I was incorrect about the contents of the DSP library, which does not contain provide an interface to those instructions, but they're available as assembly. I have found example code online showing how to write the appropriate assembly for basic SIMD operations. Relevant to ulab, there are addition, subtraction, multiplication (signed or unsigned), bitwise operations, shifts and comparisons. It has complex number multiplication, but I'm not sure if that overlaps with ulab.

[cherrydev]

Oh, I may not have read your comment carefully the first time. You mentioned dense arrays. So yes, if you're holding onto an array that isn't dense, you would need to materialize it to a dense array in order to be able to take advantage of it, but wouldn't people still want the option to do so if they knew it could speed up an operation by 4-16x?

[v923z]

you would need to materialize it to a dense array in order to be able to take advantage of it, but wouldn't people still want the option to do so if they knew it could speed up an operation by 4-16x?

The way to do that is to copy the contents to a temporary array in RAM. But first, when copying, you would have to iterate over the array and at the same time, you could just perform the operation. And on top of that, you would also have to reserve and free the RAM that you use.

So, basically, the only place you can take advantage of this is a forward-going dense array. Even something like

a = array([1, 2, 3])
a[::-1]

would fail, because a[::-1] needs to access the element beginning at the end of the array.

Thus, whenever you see an array, and want to operate on it, you would have to ascertain that the array conforms to some quite specific conditions. Apart from copying its content as mentioned above, you would also run some checks. At that point, all advantages are lost, in fact, you'll be worse off.

It has complex number multiplication, but I'm not sure if that overlaps with ulab.

Yes, you can compile ulab with complex support.