-
Notifications
You must be signed in to change notification settings - Fork 1
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
Precompute sin/cos lookup tables. #22
Comments
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 This is for a later time. A first draft could do it in a simpler way... |
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. |
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. |
We could improve the speed execution of the complex and real transforms by pre-computing a sin/cos table when a plan is created.
The text was updated successfully, but these errors were encountered: