Timeline for How could I make FFTW Hilbert transform calculate faster?
Current License: CC BY-SA 4.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 4, 2021 at 10:34 | vote | accept | Kevin | ||
| Jan 3, 2021 at 17:46 | comment | added | Eric Backus | Sounds like you did the right thing, so I don't know what's causing the break point. I'm no FFTW expert though. Perhaps call fftw_cleanup() after you destroy the plans? | |
| Jan 3, 2021 at 16:41 | comment | added | Kevin |
@EricBackus Thanks for your advice! However, I tried to move the fftw_destroy_plan(plan_forward); out to the hilbert() and put them on the end of the main()(below the displayComplex(y);), there is a break point occurred, saying CppFFTW.exe has triggered a breakpoint. Maybe I put them on the wrong place of main()?
|
|
| Jan 3, 2021 at 2:54 | history | edited | Eric Backus | CC BY-SA 4.0 |
Explain that overall speed increase from a real-valued forward FFT would be up to 25%.
|
| Jan 3, 2021 at 1:48 | comment | added | Eric Backus | @Kevin See my updated answer... | |
| Jan 3, 2021 at 1:38 | history | edited | Eric Backus | CC BY-SA 4.0 |
Add review of latest code from OP
|
| Dec 30, 2020 at 21:57 | comment | added | Kevin | @EricBackus Super cool! I got the same output answer! I think this could be my late Christmas gift, thanks! One last check, please take a look to the code that I updated to see if there are anything can be more optimized. | |
| Dec 30, 2020 at 21:37 | comment | added | Eric Backus |
@Kevin Leave the plan variables declared in main. But add them to the parameters passed to hilbert. So the hilbert function declaration would look like void hilbert(const double* in, fftw_complex* out, fftw_plan plan_forward, fftw_plan plan_backward). Then when you call the hilbert function from main, use hilbert(x, y, plan_forward, plan_backward);.
|
|
| Dec 30, 2020 at 18:39 | comment | added | Kevin |
@EricBackus If I move fft_execute(plan_forward) (also the backward) back to the hilbert(), the VS will show the red saying the variable is undefined so where is the place better to declare these two variables?
|
|
| Dec 30, 2020 at 18:24 | comment | added | Kevin | @Eric Backus Thanks for the reply, I will try and realize what you mentioned above. In fact, I just be thrown to use C/C++ recently because our data stream DAQ card only support in C, since I only know how to write Matlab... So, I'm just trying to write and let it run but with less knowledge. | |
| Dec 30, 2020 at 18:08 | comment | added | Eric Backus |
Then pass plan_forward and plan_backward as parameters into hilbert, and use them in the calls to fft_execute. Your initialization of plan_forward and plan_backward should use y, not out, since y is what you pass to hilbert. Hope this helps... :)
|
|
| Dec 30, 2020 at 18:06 | comment | added | Eric Backus |
@Kevin I think you've got some fundamental misunderstanding of C++ there. That's OK, we've all had to learn it at some point, and C++ is a complicated language. Anyway, you have no calls to FFT at all in your hilbert function, so all it is doing is multiplying the first half of the input data by 1/N (for the first point) or 2/N (for the remainder of the first half), and setting the second half of the points to zero. You need to put back the calls to fft_execute in hilbert, but leave the plan_forward and plan_backward in main.
|
|
| Dec 29, 2020 at 10:35 | comment | added | Kevin | @Eric Backus I tried almost followed your instruction to rewrite the code, at least it can run normally now, but the output value was not right. Please take a look in the question content which I updated. Any thoughts? | |
| Dec 29, 2020 at 3:31 | history | edited | Eric Backus | CC BY-SA 4.0 |
Fix a few typos
|
| Dec 28, 2020 at 23:00 | comment | added | pacmaninbw♦ | Better. Since the question is now closed you may not get a lot of up votes, but good job. | |
| Dec 28, 2020 at 20:22 | comment | added | chux | "should be passed into hilbert" is an agreeable view and is more true with C++ than C (now that the tag has changed) Yet "using global variables is a bad idea" remains an overstatement and takes always from OP's efficiency focus. | |
| Dec 28, 2020 at 20:14 | comment | added | Eric Backus |
@chux-ReinstateMonica Yes, it is true that the global variables in the original post are not affecting performance, though they were contributing to a defect that prevents the code from working. Yes, embedded critical systems may be a place where allocated data is bad. However, even if the original post's hilbert transform was meant for that environment, I would still be arguing that the FFT plan variables should be passed into hilbert rather than be global.
|
|
| Dec 28, 2020 at 20:12 | comment | added | Eric Backus | @pacmaninbw OK, I've tried to add some explanation of why I think global variables are not generally a good idea. | |
| Dec 28, 2020 at 20:08 | history | edited | Eric Backus | CC BY-SA 4.0 |
Explain my reasoning for avoiding global variables
|
| Dec 28, 2020 at 17:11 | comment | added | chux | A classic example where global data is good and allocated data is bad is with life critical applications (air traffic control, medical devices) where out-of-memory is simple not an option. IAC, I see scant performance change (OP's review goals) due to its use or not. | |
| Dec 28, 2020 at 15:28 | comment | added | Kevin |
In order to prevent the plan variables need to be defined, I moved both fftw_execute to the main. However, the code still didn't work since the similar Exception thrown at 0x00000000707E4D38 (libfftw3-3.dll) in CppFFTW.exe: 0xC0000005: Access violation reading location 0x0000000000000000. happened. Please take a look to the code I updated today at the question content.
|
|
| Dec 28, 2020 at 15:24 | comment | added | Kevin |
I tried to follow your guide, but still several problems happened: 1. The VS is keep showing that out is an undefined variables, since I moved fftw_plan plan_forward = fftw_plan_dft_1d(N, out, out, FFTW_FORWARD, FFTW_ESTIMATE); out the hilbert(), so I still preserved fftw_complex* out; at global declaration, any better thoughts? 2. Similar to the out variable problem, as I moved fftw_plan plan_forward = fftw_plan_dft_1d(N, out, out, FFTW_FORWARD, FFTW_ESTIMATE); out hilbert(), the variable plan inside the hilbert became needs to be defined again.
|
|
| Dec 28, 2020 at 14:11 | comment | added | Edward | The C++ Guidelines is a good reference for many things, including why one should avoid non-const global variables | |
| Dec 28, 2020 at 13:19 | comment | added | pacmaninbw♦ | Explain why in your experience global variables are bad. I happen to agree with you but in my answers I explain why. | |
| Dec 28, 2020 at 6:14 | comment | added | Eric Backus | I still think that in general global variables are a bad idea, though I will admit there are times when they are useful/necessary. | |
| Dec 28, 2020 at 1:53 | comment | added | chux | "In general, using global variables is a bad idea." is too sweeping a statement - global data is fine - it is an application dependent issue. IAC unless that memory location affects performance, little reason to comment on it. | |
| Dec 27, 2020 at 17:55 | history | answered | Eric Backus | CC BY-SA 4.0 |