Uh oh!
There was an error while loading. Please reload this page.
FFTW overrides via extension - #668
Conversation
dlfivefifty
commented
Oct 2, 2023
This also replaces https://github.com/JuliaApproximation/FastTransformsForwardDiff.jl |
dlfivefifty
commented
Oct 2, 2023
I don't understand whats causing the Invalidations failure, it looks like an unrelated bug... |
devmotion
commented
Oct 2, 2023
IMO ForwardDiff should not depend on FFTW. Instead I think it would be preferable to fix JuliaMath/AbstractFFTs.jl#56 and only depend on AbstractFFTs. |
dlfivefifty
commented
Oct 2, 2023
This is why its an extension so it doesn't depend on either but I agree with you that JuliaMath/AbstractFFTs.jl#56 makes sense |
devmotion
commented
Oct 2, 2023
It's not an extension on Julia < 1.9. |
dlfivefifty
commented
Oct 2, 2023
I believe we can just drop FFTW support on Julia <v1.9. How does that sound? |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@## master #668 +/- ##
==========================================
- Coverage 89.65% 86.63% -3.03%
==========================================
Files 11 13 +2 Lines 967 920 -47 ==========================================
- Hits 867 797 -70 - Misses 100 123 +23
☔ View full report in Codecov by Sentry. |
devmotion
commented
Oct 3, 2023
I guess this would be annoying in practice. Downstream packages that want to use ForwardDiff + FFTW would have to copy the diff rules or add some workaround for them in Julia < 1.9, including the LTS version. |
antoine-levitt
commented
Oct 3, 2023
Would something like |
devmotion
commented
Oct 3, 2023
One could also put the FFTW rules behind a |
antoine-levitt
commented
Oct 3, 2023
Looking at the patch, the bulk of it only requires AbstractFFTs, FFTW is only needed for real-to-real FFTs, so just drop FFTW for <1.9 and <1.9 users can still enjoy most of the benefits of this, and add the relatively small real-to-real FFTs by hand if they really need it? |
dlfivefifty
commented
Oct 3, 2023
I’m not quite sure what to do about the tests failures as they pass locally and it’s unclear what’s causing allocations |
devmotion
commented
Oct 4, 2023
Not supporting the FFTW-specific rules on Julia < 1.9 might be a bit surprising but I think it would still be much more preferable than depending on FFTW. The current design of AbstractFFTs is to leave the choice of the FFT backend to the users - as soon as a package loads an FFT backend (directly or indirectly) it's used for all FFT computations in all packages, i.e., the AbstractFFTs design assumes that only users load a backend because otherwise the whole ecosystem is affected (see, e.g., see e.g. JuliaMath/AbstractFFTs.jl#32, JuliaStats/KernelDensity.jl#117, and the discussion in JuliaPlots/StatsPlots.jl#480). I think this design is questionable but probably its restrictions were not a practical concern as long as there was no proper alternative to FFTW.jl. However, with alternatives such as RustFFT.jl nowadays it's more problematic if packages do not take the AbstractFFTs design into account. |
sjkelly
commented
Nov 30, 2023
Is using |
This replaces #541 and introduces overrides needed for FFTW as extensions.
Note it will make FFTW and AbstractFFTs dependencies in Julia <v1.9