Skip to content
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

Using similar for preallocation #59

Open
dannys4 opened this issue Sep 9, 2021 · 1 comment
Open

Using similar for preallocation #59

dannys4 opened this issue Sep 9, 2021 · 1 comment

Comments

@dannys4
Copy link

dannys4 commented Sep 9, 2021

In line 28, whoever originally wrote this expressly went out of their way to avoid using y = similar(x). I can't seem to find any discussion as to why this was done except for the vague comment, but I'm currently trying to interface with AbstractFFTs and this would be a huge minus for me.
Currently, I'm respecting whatever type the user inputs. While just plugging in AbstractFFTs would likely work just fine, I think this behavior could be undesirable. For example, right now, using StaticVector as both input and output accelerates the algorithms tremendously, which is particularly consequential when performing many very small FFTs. I asked @ararslan about this a few weeks ago, and got the response that this was ported over from when AbstractFFTs was in Base. Is it still necessary to do this?

@stevengj
Copy link
Member

It's not necessary, but if it is used with FFTW.jl then it will cause an extra array copy to be allocatedd for cases where similar produces a non-StridedArray. That can be eliminated, however, by adding more specialized methods to FFTW.jl

(These lines date back to when everything was in Base and FFTW was the only FFT implementation.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants