Hello everyone! I’ve created the InplaceRealFFT.jl module to expose FFTW’s inplace real-to-complex (rfft!) and complex-to-real (irfft!) transformations. Currently, Julia only provides inplace version of the transform for complex-to-complex transformations (fft! and ifft!). I’ve been using this mod…

No you must not do it. There’s absolutely no guarantee that the data will be valid

Would you mind elaborating what the problem is? From you answer, I’d guess you think that a use-after-free might happen in some cases; in what kind of cases?

[image] foobar_lv2: If a user decides to keep the real view and let the PaddedArray die Compiler can do this, easily. [image] foobar_lv2: in what kind of cases? In general, just don’t do this kind of analysis. All what you can ever do is to assume certain compiler limitation and rely …

[image] yuyichao: In general, just don’t do this kind of analysis. All what you can ever do is to assume certain compiler limitation and rely on implementation details that can easily change. That’s a reasonable standard for security-relevant code and for base / quasi-stdlib code. I have a f…

No it’s not breakage in future, it’s breakage when the code is used in a way that the compiler can already optimize.

So the proper guard would be to @noinline all scary functions, and then just read the @code_llvm or test to see whether everything is fine? I mean, the overhead of a couple function calls is negligible compared to fft computation.

Thanks a lot! Now I feel stupid. Since @favba has a quite small lib, this is actually feasible (there are only 3-4 dangerous functions to annotate).

Thank you guys, for the help. [image] foobar_lv2: Option: Make the real array the owner of the memory. Then it is safe to take out the real part and run away with it, and unsafe to take out the complex view and run away. It does make a lot more sense to use the real view as the “parent” of t…

I’m changing my mind again. In order to use the new ReinterpretArray I’d have to change FFTW.jl internals, which I got away with so far and might be out of my league. Also, right now I’m getting a 200x slowdown on a sum with the ReinterpretArray. [image] yuyichao: No, the propery way is to use @…

ANN: InplaceRealFFT.jl : inplace real-to-complex and complex-to-real FFT

Specific Domains Numerics

yuyichao January 3, 2018, 9:30pm 13

No, the propery way is to use @gc_preserve in this function and every single users.

Topic		Replies	Views
In-place rfft with padded arrays New to Julia question , fftw	3	2228	May 5, 2017
In-place fft General Usage	4	3502	May 8, 2019
[ANN] RustFFT.jl: Compute forward and inverse FFTs with RustFFT Package Announcements	13	1708	May 30, 2023
Reusing a complex FFT array’s memory as a real array, “C-style” General Usage array , memory , fft	7	254	October 4, 2024
Performance Help on Large Matrix Manipulation Performance performance , matrices	16	1958	September 24, 2020

ANN: InplaceRealFFT.jl : inplace real-to-complex and complex-to-real FFT

Related topics