> Running 80 FFT's every second isn't going to be great on batteries.
Assume for the moment that floating-point were used instead of fixed-point:
A 2048-element real-to-real FFT requires a bit less than 40Kflop, or 3.2Mflop/sec to get 80FFT/sec. Modern hardware is capable of > 1Gflop/joule, so the raw compute of 3.2Mflop/sec actually takes something on the order of 3.2mw.
Of course, the computation is being done in q15 instead of float, which (in theory) should require something on the order of 1/2 the energy. On the other hand, the processor can’t just do FFTs. It’s spending energy going in and out of lower-power states, running other code, etc, etc, and I don’t have any data for the energy usage of the M4 specifically, to say nothing of the other components on the board.
In principle though, the energy actually consumed by performing the FFTs should be pretty minimal; most of it will be going to everything else unless the hardware and software are both very carefully designed for efficiency.
Assume for the moment that floating-point were used instead of fixed-point: A 2048-element real-to-real FFT requires a bit less than 40Kflop, or 3.2Mflop/sec to get 80FFT/sec. Modern hardware is capable of > 1Gflop/joule, so the raw compute of 3.2Mflop/sec actually takes something on the order of 3.2mw.
Of course, the computation is being done in q15 instead of float, which (in theory) should require something on the order of 1/2 the energy. On the other hand, the processor can’t just do FFTs. It’s spending energy going in and out of lower-power states, running other code, etc, etc, and I don’t have any data for the energy usage of the M4 specifically, to say nothing of the other components on the board.
In principle though, the energy actually consumed by performing the FFTs should be pretty minimal; most of it will be going to everything else unless the hardware and software are both very carefully designed for efficiency.