-
Notifications
You must be signed in to change notification settings - Fork 27
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
FFTW wisdom for threads #162
Conversation
No, I think it is fine. That is the beauty of FFTW working well with Partr threads, we basicaly throw everything at the thread scheduler and it crunches through it all. We'll need to benchmark of course. |
Could we not run into this issue? JuliaMath/FFTW.jl#121 (comment) I guess it will depend strongly on the size of the transform. |
src/Utils.jl
Outdated
@@ -60,26 +60,25 @@ function sourcecode() | |||
return out | |||
end | |||
|
|||
FFTWthreads() = settings["fftw_threads"] == 0 ? 4*Threads.nthreads() : settings["fftw_threads"] |
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.
why don't we just use Threads.nthreads
? That way we don't depend on some internal structure of FFTW.jl. I don't think we need to set the number of FFTW threads explicitly now, given that this is taken care of
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.
It's to allow manual setting of the FFTW threads if needed/wanted. This can be independent of nthreads
. But the wisdom file needs to correspond to the number of FFTW threads, not nthreads
.
Just realised this is missing the nthreads() == 1
case though
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.
You are correct. We should also note that if someone installs the MKL backend to FFTW.jl (which might be faster) then the code does not set the number of threads automatically: https://github.com/JuliaMath/FFTW.jl/blob/2638fbe3e51094ca8cd8e9f67dc1836b4aa6956e/src/FFTW.jl#L46
It initialises threads, but presumably one also needs to run set_num_threads
too.
I don;t think so. Our transforms will always be huge, such that partr spawning shouldn't matter. Also that is supposed ti be getting much faster soon anyway. But we will simply have to benchmark to be sure. My measurements so far are that threaded sims are always faster than single threaded, just not as much as we might hope! |
test pass |
Save FFTW wisdom in different files depending on number of thread used by FFTW. This can be set using
Luna.set_fftw_threads
, otherwise it defaults to4*nthreads()
as done by FFTW internally.Two issues:
FFTW.set_num_threads
is called manually without updatingLuna.settings
.TransModal
in Threads #159. For free-space sims, we can parallelise the response independently from the FFTs (except for Raman), but do we want to use single-threaded FFTs insideTransModal
?