FFTW / fftw3

DO NOT CHECK OUT THESE FILES FROM GITHUB UNLESS YOU KNOW WHAT YOU ARE DOING. (See below.)
GNU General Public License v2.0
2.73k stars 665 forks source link

bench can not use wisdom from fftwf-wisdom #71

Closed blacklion closed 8 years ago

blacklion commented 8 years ago

I have "bench" and "ffrwf-wisdom" from same build (3.3.5, float, static build to simplify things) in one directory. And "bench" fails to load wisdom from "fftwf-wisdom" utility. I'm running:

% ./fftwf-wisdom -o wis.dat ocf64
% ./bench -owisdom -owisdom-only -s ocf64
bench: ERROR reading wisdom
bench: speed.c:39: assertion failed: can_do(p)
%

Size doesn't matter here, any size doesn't work.

blacklion commented 8 years ago

Signature in output of "fftwf-wisdom" is differ from signature in output of "./bench -owisdom -s ocf64":

% ./fftwf-wisdom  ocf64
(fftw-3.3.5 fftwf_wisdom #x51bab467 #xc577022a #x71ce00fe #x1c761582
  (fftwf_codelet_t2fv_8_avx2 0 #x11048 #x11048 #x0 #x161166c7 #x05df8f94 #xd8ed13e3 #x84c874a9)
  (fftwf_codelet_n2fv_8_avx2 0 #x11048 #x11048 #x0 #x43891fa9 #xe40b2f6f #xf3e0a288 #xe5b9cf92)
)
%

vs

% rm wis.dat
% ./bench -owisdom -opatient -s ocf64
Problem: ocf64, setup: 55.74 ms, time: 173.78 ns, ``mflops'': 11048
% cat wis.dat
(fftw-3.3.5 fftwf_wisdom #xc4fc48e8 #x5e4e0221 #xa2886a62 #x879b6101
  (fftwf_codelet_t3fv_8_avx2_128 0 #x31bff #x31bff #x0 #x161166c7 #x05df8f94 #xd8ed13e3 #x84c874a9)
  (fftwf_codelet_t2fv_8_avx2 0 #x11048 #x11048 #x0 #x161166c7 #x05df8f94 #xd8ed13e3 #x84c874a9)
  (fftwf_codelet_n2fv_8_avx2 0 #x11048 #x11048 #x0 #x43891fa9 #xe40b2f6f #xf3e0a288 #xe5b9cf92)
  (fftwf_codelet_n2fv_8_avx2_128 0 #x31bff #x31bff #x0 #x43891fa9 #xe40b2f6f #xf3e0a288 #xe5b9cf92)
)
matteo-frigo commented 8 years ago

Can't reproduce. (I.e., the signature matches for me.)

Can you post the exact sequence of steps that you did, starting from a fresh unpack of a fftw-3.3.5 tarball?

blacklion commented 8 years ago

Here is "script" with removed build output (it is 1.3MB). Please note, that I could reproduce this on Windows with mingw64 (gcc 6.1.0) too, but I know, that you don't use and don't support Windows. But here it is, same behavior on two systems, with two different compilers. fftp-3.3.5.txt

matteo-frigo commented 8 years ago

The problem is that by default "bench" enables a threaded configuration, whereas fftw-wisdom does not. "Configuration" has a technical meaning in FFTW, and it denotes the set of "solvers" that can be used. A solver is a piece of code that can compute some subset of all possible FFT problem (e.g., solve ocf64, or compute all out-of-place transforms). Threads enable and require more solvers, e.g. for splitting a problem into multiple threads.

You can enable threads in fftw-wisdom via -T N; note that -T1 is still incompatible with the nonthreaded configuration, since the threaded solvers are still present even if you don't use them.

bench always enables threads. A variable threads_ok in tests/fftw_bench controls whether or not to enable threaded solvers, but there is no way to change this variable without changing the source code.

I agree that this confusion is unfortunate, but I don't see any way to remove it. We don't want to have FFTW depend on pthreads, as this will break many existing programs (and people use other threading substrates such as openmp, or outer-level parallelization mechanisms such as MPI). So the thread/nonthread distinction is kind of necessary. Consequently, fftw-wisdom must work in either mode. Conversely, bench must be able to read its own wisdom, so we must run in in threaded mode always (since it can be run with -onthreads=N). I don't see any way around this problem.

blacklion commented 8 years ago

Thank you for explanation!

blacklion commented 8 years ago

Oh, sorry, I have one last question regarding threads and wisdom: is wisdom, generated with several threads, applicable to single-threaded planning? If I want to run same task on 1, 2, 4 threads should I prepare 3 versions of wisdom or one is sufficient?

stevengj commented 8 years ago

The wisdom is specific to the number of threads.

ka9q commented 1 year ago

Along the same lines, I've found that the wisdom generators (eg. fftwf-wisdom) are sensitive to the order of their command line arguments when priming them with existing wisdom files. E.g., fftwf-wisdom -w wisdom-file -T 1 ... fails if wisdom-file was generated with threading enabled. You must put the -T option ahead of the -w option if that is the case.