This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Crash when exporting FFT wisdom for certain c2c transform sizes

I am seeing a crash in the fftw_export_wisdom_to_filename function for certain 2d complex-to-complex transforms with FFTW_PATIENT. I've tried a range of sizes and it's rare but it appears to occur with certain larger prime sizes.

For example, 263x263 crashes, as does 269x269 and 263x269. Other nearby primes don't, though. I have not seen it for a non-prime size, but I haven't tried very hard to find failure cases.

I'm on libarmpl_lp64, version 24.04, and I've seen the same behavior on both macos and linux. I can make minimal changes to the example code in fftw_guru_dft_c2c_c_example.c to reproduce the crash:

52,53c52,53
< 	const int n0 = 3;
< 	const int n1 = 4;
---
> 	const int n0 = 263;
> 	const int n1 = 269;
101,102c101,102
< 	fftw_plan forward  = fftw_plan_guru_dft(RANK, dims, HM_RANK, hm_dims, x, y, FFTW_FORWARD, FFTW_ESTIMATE);
< 	fftw_plan backward = fftw_plan_guru_dft(RANK, dims, HM_RANK, hm_dims, y, x, FFTW_BACKWARD, FFTW_ESTIMATE);
---
> 	fftw_plan forward  = fftw_plan_guru_dft(RANK, dims, HM_RANK, hm_dims, x, y, FFTW_FORWARD, FFTW_PATIENT);
> 	fftw_plan backward = fftw_plan_guru_dft(RANK, dims, HM_RANK, hm_dims, y, x, FFTW_BACKWARD, FFTW_PATIENT);
127a128,131
>   if (!fftw_export_wisdom_to_filename("test.fftwisdom")) {
>     fprintf(stderr, "export error\n");
>   }
>


The crash occurs with FFTW_PATIENT or FFTW_MEASURE but not FFTW_ESTIMATE.

I am observing no real loss in performance when changing to FFTW_ESTIMATE, so this is an acceptable workaround for me. That leads me to a related question: should I expect any advantage to the MEASURE or PATIENT planner modes in armpl?

  • Hi,

    Thanks for reporting this, we'll look into it and get it fixed for the next release.

    As to your question about whether there is any advantage in using levels of rigour higher than FFTW_ESTIMATE... right now in most cases there's probably not an advantage, but adding more run-time optimization decisions and tests during planning is something we may work on in the future.

    Regards,

    Chris.