Henrik Enquist
Henrik Enquist
Yeah there is quite a lot hidden in that "just" 😆 BTW roughly how large is your data? If it fits in the cpu cache, then you can get away...
What lengths do you use? Have you measured the actual speed at those lengths compared to say the next larger power of two? I often use lengths that are 2^n...
There isn't really any need of bringing in another fft library. RustFFT has a built-in reference implementation here: https://github.com/ejmahler/RustFFT/blob/master/src/algorithm/dft.rs It's basically just the DFT definition. That makes it quite slow,...
> > I was hoping to make a fuzz target for every combination of algorithm and instruction set, Many algorithms use other ffts internally. These are normally selected by the...
This is quite similar to https://github.com/ejmahler/RustFFT/issues/79
I think the speed benefit alone is too small to motivate a change. Anyone who cares about performance should be reusing the same buffers for every call, so the initialization...
Is it allowed to cheat with unsafe? ``` let mut buf: Vec = Vec::with_capacity(1000); unsafe { buf.set_len(1000); } ``` This should skip the clearing of the new vector. I'm also...
> The first one is pretty obvious. If the allocator didn't allocate enough memory for the `Vec`, then accessing past the `Vec` will, in the best case, cause a segfault,...
Yes I read it. The problem I see is that any reasonable implementation of your suggestion would essentially need to do the same. I mean to just assume the scratch...
If you then want to reuse the output buffer, what do you do then?