Precompute sin/cos lookup tables.

[Lagrang3]

We could improve the speed execution of the complex and real transforms by pre-computing a sin/cos table when a plan is created.

[ckormanyos]

improve the speed execution of the complex and real transforms by pre-computing a sin/cos table when a plan is created

This is a neat idea, with an advanced little twist. We are always interested in thread-safe modules at Boost. Sometimes it's not always possible. But FFT might be a good candidate for thread-safe.

So when we think about computing sin/cos tables, one thread-safe way to do so is to compute the needed constants during static initialization prior to the call to main(). Why there? Because computing them on the first call or whatever could always result in a race-condition. So for stuff like that (i.e., also Boost.Math.Constants), we sort of settled in on computation prior to main().

This is for a later time. A first draft could do it in a simpler way...

[Lagrang3]

The sin/cos tables I am referring to are unique for every FFT size. We cannot compute them until we know the size, and need to recompute them if the size changes. My idea is that that these could be stored in the state of the plan. To be honest, I am not sure if those could provide a significant boost in performance.

However, precomputing sin/cos tables for small size transforms, eg. from n=3 to 100, could also be interesting.

[ckormanyos]

To be honest, I am not sure if those could provide a significant boost in performance

Indeed. This is a very rich topic. In my experience, on PC/worstations toady, sin/cos computations are predominantly in hardware and very fast on the fly. Storage in pre-computed tables is often not worth the added effort. For multiprecision types, however, precomputed trig tables can be quite helpful.