Add support for FFT plans#1931
Conversation
26824de to
9cb5e4f
Compare
Co-authored-by: Avik Pal <avikpal@mit.edu>
|
I'd hope XLA is able to reuse plans applied to different arrays of the same shape. Since all the planning is completely opaque to the frontend we can't do much about it, but reusing plans is quite a crucial optimisation (and the whole point plans exist) |
|
I'd assume so as well, but also since we already separate compile from run, during compile even if we make a different plan for all the fft instructions, they'd still all be planned during runtime ? It already does this with matmul by trying all possible matmul plans I know |
|
The requisites for a plan are the shape and the eltype of the target array, and XLA should known them all at compile-time, right? So I'd speculate it's possible it does all the planning during compilation. But still, planning can be quite expensive, not repeating it unnecessarily would be welcome in large applications, whether it's during compile- or run-time. |
|
yeah Id assume it has a cache, but we can benchmark, check, and fix, as needed as a follow up |
| AbstractFFTs.$(op)(x) | ||
|
|
||
| # In-place plan | ||
| if op !== :rfft |
There was a problem hiding this comment.
Rfft returns an array of different shape than the input one, it can't be done in-place. There's no plan_rfft!
Should fix #1926, but for some reason I don't quite understand, the in-place plans aren't in-place (the added tests should fail), even though the code in #1926 (comment) works as expected. I now get
Note that contrary to #1926 (comment), the input is not aliasing the output. @avik-pal do you have any clue of what's going on here?
Edit: I simply missed a
!🤦