Skip to content
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

WIP: enable reusing fft plans #271

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from
Draft

WIP: enable reusing fft plans #271

wants to merge 8 commits into from

Conversation

IanButterworth
Copy link
Member

@IanButterworth IanButterworth commented Jan 13, 2024

Requires

TODO:


Because they are not threadsafe FFTW FFT plans are behind a lock. They should be reusable for same-sized images and kernels, so this is WIP towards exposing a way to provide plans, so that imfilter! can be run concurrently on julia threads without lock conflict.

Note that this is using JuliaLang/julia#52883 to count conflicts.

There's a demo temporarily in this PR.

Before it hits 34255 lock conflicts

% FFTW_NUM_THREADS=1 BLAS_NUM_THREADS=3 ../julia/julia --project -t6,1 -q
julia> include("demo.jl")
warm run of benchmark(mats): 5.483911 seconds (2.14 M allocations: 10.671 GiB, 16.62% gc time, 34255 lock conflicts)

This PR removes all but the lock conflicts from the singlular plans, which could be moved out of the for loop

% FFTW_NUM_THREADS=1 BLAS_NUM_THREADS=3 ../julia/julia --project -t6,1 -q
julia> include("demo.jl")
warm run of benchmark(mats): 2.440659 seconds (478.12 k allocations: 7.888 GiB, 21.53% gc time, 8 lock conflicts)

@IanButterworth IanButterworth marked this pull request as draft January 13, 2024 05:34
@IanButterworth

This comment was marked as outdated.

@IanButterworth

This comment was marked as outdated.

src/imfilter.jl Outdated Show resolved Hide resolved
@IanButterworth
Copy link
Member Author

Ok, I think this seems reasonable now. @timholy would you mind reviewing for general design and I can add tests & docs if you agree

@IanButterworth IanButterworth changed the title WIP: allow providing fft plans WIP: enable reusing fft plans Jan 13, 2024
@timholy
Copy link
Member

timholy commented Jan 13, 2024

I confess I haven't thought about these plans in ages (the code I linked earlier was probably written in the Julia 0.1 days), but nothing bad jumps out about this. Thanks for doing it!!

src/ImageFiltering.jl Outdated Show resolved Hide resolved
@IanButterworth

This comment was marked as resolved.

@IanButterworth
Copy link
Member Author

Comparing buffered vs standard I get different values here

B = complex(planned_rfft1(A)) * FFTW.AbstractFFTs.to1(A)
_B = rfft(A)
@show B[1:4] _B[1:4]

B[1:4] =  ComplexF32[3065.7727f0 + 113.279686f0im, -254.48924f0 - 85.513504f0im, -369.77383f0 - 146.0826f0im, -267.98865f0 - 201.43063f0im]
_B[1:4] = ComplexF32[4595.6045f0 + 0.0f0im,         3.6047888f0 + 15.441383f0im,  14.378552f0 - 19.552792f0im, -18.684448f0 - 19.284311f0im]

My trial and error phase of debugging isn't being very fruitful, so I think I'll wait for review. @timholy if you happen to have time

@mkitti
Copy link
Member

mkitti commented Jan 31, 2024

Commeting to remind myself to take a look

Copy link
Member

@timholy timholy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing jumps out as a serious problem just from a read through the code, but it's probably been a decade since I put the serious work into writing RFFT.jl (it used to be part of a more monolithic repository so the git history may not reflect that). Do the disagreements only arise when you use multiple threads?

demo.jl Outdated Show resolved Hide resolved
src/RFFT.jl Outdated Show resolved Hide resolved
src/RFFT.jl Outdated Show resolved Hide resolved
@IanButterworth

This comment was marked as outdated.

Copy link

codecov bot commented Mar 11, 2024

Codecov Report

Attention: Patch coverage is 15.00000% with 34 lines in your changes are missing coverage. Please review.

Project coverage is 89.78%. Comparing base (66cf9d9) to head (6ef477e).

❗ Current head 6ef477e differs from pull request most recent head 9db8caf. Consider uploading reports for the commit 9db8caf to get more accurate results

Files Patch % Lines
src/imfilter.jl 10.52% 34 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #271      +/-   ##
==========================================
- Coverage   94.25%   89.78%   -4.48%     
==========================================
  Files          13       13              
  Lines        1706     1742      +36     
==========================================
- Hits         1608     1564      -44     
- Misses         98      178      +80     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@IanButterworth
Copy link
Member Author

IanButterworth commented Mar 11, 2024

Ok. Tests are passing here.

Note that planned_fft doesn't support non-float eltypes currently because RFFT.RCpair only supports floats (and other reasons, I guess).

However, demo.jl still fails

f1[1:4] = [0.11624783622854669, 0.15113825707056688, 0.16887924282352731, 0.20249257393260642]
f2[1:4] = [0.17744583830964283, -0.0655415564571991, -0.10802786527654895, 0.11185075216343188]
ERROR: LoadError: f1 !≈ f2

@IanButterworth IanButterworth force-pushed the ib/threading branch 2 times, most recently from e32b32f to a948fae Compare March 11, 2024 20:13
Copy link
Member

@timholy timholy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! Not only is the new functionality appreciated, but the various cleanups are too.

I haven't played with this myself, but does demo pass now? If so, it seems like you're almost over the hump. I don't see anything objectionable here (assuming you'll get to a point of full test coverage for the new functionality), so feel free to run with this.

Project.toml Outdated Show resolved Hide resolved
demo.jl Outdated Show resolved Hide resolved
return function (arr::AbstractArray{T}) where {T}
copy!(buf, OffsetArrays.no_offset_view(arr))
return plan(buf)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No test coverage here and below

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I hadn't noticed this. Sadly it turns out the new functionality isn't passing yet..

test/gabor.jl Show resolved Hide resolved
test/nd.jl Outdated Show resolved Hide resolved
function filtfft(A::AbstractArray{C}, krn, planned_rfft1::Function, planned_rfft2::Function, planned_irfft::Function) where {C<:Colorant}
Av, dims = channelview_dims(A)
kernrs = kreshape(C, krn)
B = complex(planned_rfft1(Av, dims)) # TODO: dims is not supported by planned_rfft1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think dims can be a point of flexibility: these plans are specific to the memory layout of the array. (The planning explores various implementations and picks the fastest discovered; performance is strongly dependent on memory layout, so the choice for one layout may not be the same as another.) You'd have to create a plan specifically to the colorant array-type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added this comment to the TODO. I think I'd prefer to fix this in a follow on PR, if that sounds ok

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants