-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FFT API rewrite #25
Comments
Katja from http://www.katjaas.nl calls the unmangle/mangle operations just split spectrum and merge spectrum |
that's much better name. We'll go with that. Thanks. So the API will be:
|
Do we really need the 16 bit versions too? If we instead had an efficient 16 -> 32 and 32 -> 16 array converter functions then we could do away with the 16 bit implementations at the cost of some run time memory (one length N 32 bit array). The benefit, other than implementation, would be increased precision on the 16 bit version. |
|
I love that guys graphics. On 8 Mar 2016, at 12:10, Larry Snizek <notifications@github.commailto:notifications@github.com> wrote: Katja from http://www.katjaas.nl calls the unmangle/mangle operations just split spectrum and merge spectrum — |
ASJ - you might have a good point about only providing the 32 bit versions and then converting to 16 bit. In addition to the increased precision (which has been a big problem for Thomas, with the 16 bit version), this might actually also be more efficient than the direct 16 bit versions because the 16 bit versions are a lot slower, from Thomas' benchmarks. |
Love the graphics too, Henk |
If someone could contact them then that would be good. I want to get On 08/03/2016 14:05, John Edwards wrote:
|
I can do that, Andrew. I've reviewed Thomas' emails and think I've got a handle on the performance differences. I'll let you know |
The accuracy will be very limited for a 16 bit implementation with the On 08/03/2016 14:22, John Edwards wrote:
|
Hi Guys But: Here's the test for the forward FFT using the new method: Regarding Performance: The overhead of 2.54ms is due to unpacking short int from memory into int (for the maccs, + and - of the butterfly) The function Andrew proposes to copy a 16-bit short int array in a 32-bit int array should be faster than that. would take: 16384 cycles (0.164 ms). Bottom line: But because memory is so tight for DOA+Beamforming+AEC (ideally also Keyword Recognition) we should also get feedback from customer. Cheers, /T |
Thanks very much, Thomas, |
I implemented and tested the array conversion functions: Performance (cycles per im/re data point): 5 cycles: |
Should be |
all done now. |
Here is a suggested API for fft work:
The mangle and unmangle functions could do with a better name and I'm open to suggestions. The purpose of unmangle is to take the complex output of two N length real ffts and reorder them such that the array represents two N/2 length FFTs. mangle will do the opposite, i.e. take two N/2 length complex FFT and combine them such that they can be inverted with and iFFT.
This will mean a reduced amount of code, testing, docs and that FFTs can be fit into half the memory footprint.
The text was updated successfully, but these errors were encountered: