Use fftw_planner_nthreads #526
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
As @DiamonDinoia mentioned in the comment Line 763 in 9f517e3 The ci is breaking because some of the ubuntu apt still installs fftw 3.3.8, do we still want to support fftw 3.3.8? If so, fftw[f]_version needs to be called to check fftw version. |
Merged
|
Can that be checked in cmake? If the correct version is not found in the system we can build it from source. This is not supported in makefile but will allow to fix the issue for everyone. one way to check in cmake is to write a program that links against fftw and prints the fftw_version to stdout, cmake can read the output an compare it with the right version. |
|
Hmm, this is a huge pain that ubuntu 22.04 only has FFTW 3.3.8. I was
hoping to make 3.3.9 compulsory, esp since we're shifting more to DUCC.
Compiling from source would be expensive (eg, in every run of CI). Could
we enforce ubuntu 24.04 in CI, which has 3.3.10 ?
…On Mon, Aug 19, 2024 at 10:57 AM Marco Barbone ***@***.***> wrote:
Can that be checked in cmake? If the correct version is not found in the
system we can build it from source. This is not supported in makefile but
will allow to fix the issue for everyone.
one way to check in cmake is to write a program that links against fftw
and prints the fftw_version to stdout, cmake can read the output an compare
it with the right version.
—
Reply to this email directly, view it on GitHub
<#526 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNZRSWIFMHHNLOKOD3CBMDZSIBUXAVCNFSM6AAAAABMX2PFJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWG44DIMRRGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
*-------------------------------------------------------------------~^`^~._.~'
|\ Alex Barnett Center for Computational Mathematics, Flatiron Institute
| \ http://users.flatironinstitute.org/~ahb 646-876-5942
|
|
Yes, we could enforce Ubuntu 24.04. But how about the user-base? Ubuntu 22.04 is still quite popular. Even though fftw 3.3.9 has been out I would expect many to use fftw from the package manager. |
|
Hi Jonas, Maybe restoring the threads does not restore fftw state. Could you replace I like your idea of trying to restore the previous number of threads so to still support 3.3.6. Thanks, |
|
Dear all, Thank you very much for looking into this PR! @DiamonDinoia I assume you are wondering if Thanks |
|
Update: I have set up another branch making use of and running |
|
Dear Jonas,
I'm confused: why is the desired result a single-threaded FFTW call here?
By default it should work with the max openmp threads available, which you
set to 4 in the environment variables.
Or, is this some refined test of if FFTW's global state can remain
unchanged, and not a proposal for library behavior?
Thanks, Alex
…On Wed, Aug 21, 2024 at 8:19 AM Jonas Krimmer ***@***.***> wrote:
Update: I have set up another branch making use of fftw_planner_nthreads
to test if we could get rid of FFTW_PLAN_TH over at
<https://github.com/jkrimmer/finufft/tree/rm_plan_with_threads>.
Building with
mkdir build && cd build; cmake -DFINUFFT_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release -DFINUFFT_STATIC_LINKING=OFF -DFINUFFT_FFTW_SUFFIX=OpenMP ..; cmake --build . -j
and running OMP_NUM_THREADS=4 test/finufft1d_test 1e6 1e6 1e-6 yields the
expected result, i.e., the FFTW plan is single-threaded:
test 1d type 1:
[finufft_makeplan] new plan: FINUFFT version 2.3.0-rc1 .................
[finufft_makeplan] 1d1: (ms,mt,mu)=(1000000,1,1) (nf1,nf2,nf3)=(2000000,1,1)
ntrans=1 nthr=4 batchSize=1
[finufft_makeplan] kernel fser (ns=7): 0.00252 s
[finufft_makeplan] fwBatch 0.03GB alloc: 9e-06 s
[finufft_makeplan] FFTW plan (mode 64, nthr=1): 0.00275 s
[finufft_setpts] sort (didSort=1): 0.00451 s
[finufft_execute] start ntrans=1 (1 batches, bsize=1)...
[finufft_execute] done. tot spread: 0.0203 s
tot FFT: 0.0219 s
tot deconvolve: 0.00718 s
1000000 NU pts to 1000000 modes in 0.0634 s 1.58e+07 NU pts/s
one mode: rel err in F[370000] is 6.59e-08
test 1d type 2:
[finufft_makeplan] new plan: FINUFFT version 2.3.0-rc1 .................
[finufft_makeplan] 1d2: (ms,mt,mu)=(1000000,1,1) (nf1,nf2,nf3)=(2000000,1,1)
ntrans=1 nthr=4 batchSize=1
[finufft_makeplan] kernel fser (ns=7): 0.00365 s
[finufft_makeplan] fwBatch 0.03GB alloc: 7e-06 s
[finufft_makeplan] FFTW plan (mode 64, nthr=1): 0.000163 s
[finufft_setpts] sort (didSort=0): 0.00282 s
[finufft_execute] start ntrans=1 (1 batches, bsize=1)...
[finufft_execute] done. tot deconvolve: 0.0123 s
tot FFT: 0.0228 s
tot interp: 0.00891 s
1000000 modes to 1000000 NU pts in 0.0507 s 1.97e+07 NU pts/s
one targ: rel err in c[500000] is 1.87e-07
test 1d type 3:
[finufft_makeplan] new plan: FINUFFT version 2.3.0-rc1 .................
[finufft_makeplan] 1d3: ntrans=1
M=1000000 N=1000000
X1=3.14 C1=2 S1=5e+05 D1=8.5e+05 gam1=1.00777 nf1=1259712
[finufft_setpts t3] widcen, batch 0.04GB alloc: 0.00122 s
[finufft_setpts t3] phase & deconv factors: 0.0554 s
[finufft_setpts t3] sort (didSort=1): 0.00307 s
[finufft_setpts t3] inner t2 plan & setpts: 0.0325 s
[finufft_execute t3] start ntrans=1 (1 batches, bsize=1)...
[finufft_execute t3] done. tot prephase: 0.00129 s
tot spread: 0.00742 s
tot type 2: 0.0328 s
tot deconvolve: 0.00209 s
1000000 NU to 1000000 NU in 0.145 s 1.38e+07 tot NU pts/s
one targ: rel err in F[500000] is 5.93e-07
—
Reply to this email directly, view it on GitHub
<#526 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNZRSVULUQBMDUH3OSZKQ3ZSSAUDAVCNFSM6AAAAABMX2PFJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHEYTINBTG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*-------------------------------------------------------------------~^`^~._.~'
|\ Alex Barnett Center for Computational Mathematics, Flatiron Institute
| \ http://users.flatironinstitute.org/~ahb 646-876-5942
|
|
Dear Alex, I am sorry for the confusion: My new branch rm_plan_with_threads is indeed only a refined test of the FFTW behavior as I am not interested in having single-threaded FFTs only. Instead, my conclusion is that we cannot avoid calling Line 763 in 9f517e3 fftw_planner_nthreads if we want to determine the current number of threads used by FFTW.
Thanks a lot |
|
The other question is if returning FFTW to its prior # of threads is
sufficient to preserve it's global state (which is proving very annoying
when FINUFFT integrates with other projects using FFTW).
Thx for your work, Alex
…On Wed, Aug 21, 2024 at 1:07 PM Jonas Krimmer ***@***.***> wrote:
Dear Alex,
I am sorry for the confusion: My new branch rm_plan_with_threads
<https://github.com/jkrimmer/finufft/tree/rm_plan_with_threads> is indeed
only a refined test of the FFTW behavior as I am not interested in having
single-threaded FFTs only. Instead, my conclusion is that we cannot avoid
calling FFTW_PLAN_TH as in
https://github.com/flatironinstitute/finufft/blob/9f517e3a97cec1fd9c04c9d6656d32e02bc15e3f/src/finufft.cpp#L763
if we want FFTW to run with multiple threads. Accordingly, I currently have
no idea how we could avoid calling fftw_planner_nthreads if we want to
determine the current number of threads used by FFTW.
Thanks a lot
Jonas
—
Reply to this email directly, view it on GitHub
<#526 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNZRSQZDNLSDMA7MF4TWLLZSTCOBAVCNFSM6AAAAABMX2PFJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBSGU3TGNBUGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*-------------------------------------------------------------------~^`^~._.~'
|\ Alex Barnett Center for Computational Mathematics, Flatiron Institute
| \ http://users.flatironinstitute.org/~ahb 646-876-5942
|
|
Not sure we want to do this as it enforces a recent version of fftw that ubuntu 22.04 does not ship with. We could potentially check if the function fftw_planner_ntreads exists? #include <iostream>
#ifdef _WIN32
#include <windows.h>
#else
#include <dlfcn.h>
#endif
bool functionExists(const char* functionName) {
#ifdef _WIN32
HMODULE handle = GetModuleHandle(NULL); // Get handle to the current executable
if (!handle) {
std::cerr << "Error getting module handle: " << GetLastError() << std::endl;
return false;
}
FARPROC func = GetProcAddress(handle, functionName);
return func != nullptr;
#else
void* handle = dlopen(nullptr, RTLD_LAZY); // Open the current executable
if (!handle) {
std::cerr << "Error opening handle: " << dlerror() << std::endl;
return false;
}
dlerror(); // Clear any existing error
void* func = dlsym(handle, functionName);
const char* dlsym_error = dlerror();
dlclose(handle);
if (dlsym_error) {
return false;
}
return func != nullptr;
#endif
}
int main() {
const char* functionName = "myFunction";
if (functionExists(functionName)) {
std::cout << "Function " << functionName << " exists." << std::endl;
} else {
std::cout << "Function " << functionName << " does not exist." << std::endl;
}
return 0;
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull should close #521.