-
Notifications
You must be signed in to change notification settings - Fork 234
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
[CUFFT] Preallocate a buffer for complex-to-real FFT #2578
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of minor comments. CI failures are also related.
db2ef19
to
bfb0a45
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2578 +/- ##
==========================================
+ Coverage 73.67% 73.69% +0.01%
==========================================
Files 156 156
Lines 15030 15048 +18
==========================================
+ Hits 11074 11090 +16
- Misses 3956 3958 +2 ☔ View full report in Codecov by Sentry. |
@@ -25,32 +25,34 @@ Base.:(*)(p::ScaledPlan, x::DenseCuArray) = rmul!(p.p * x, p.scale) | |||
|
|||
# N is the number of dimensions | |||
|
|||
mutable struct CuFFTPlan{T<:cufftNumber,S<:cufftNumber,K,inplace,N} <: Plan{S} | |||
mutable struct CuFFTPlan{T<:cufftNumber,S<:cufftNumber,K,inplace,N,R,B} <: Plan{S} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A dedicated typevar instead of simply Union{Nothing,CuArray}
seems overkill, but I guess you want to eliminate the partial type information?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and I also take this PR as an opportunity to have a concrete type for region
in the structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I trust you have good reasons for this, but it's not always advantageous to do so. The CUTENSOR wrappers, for example, cause excessive specialization for little gain, since these calls are very coarse-grained anyway (yet leading to very long test times). In this case, though, the specialization is already there (since B
doesn't introduced new information already contained in inplace
and T
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't changed the dispatch for the high-level FFT routines, so I didn't expect any slowdown. I simply made the low-level structure fully inferable.
I'll run a quick regression test for fft
/ifft
before and after this PR to check if there's any noticeable difference.
I didn't test it without the type B
in the structure, but I observed a nice speed-up in my code when adding the buffer inside for rfft
/irfft
.
Julia also stopped crashing due to OOM issues.
Co-authored-by: Tim Besard <tim.besard@gmail.com>
@maleadt
Related to our discussion on Slack:
and these issues: