Dear Marcus, I updated my Makefiles and sources to work with libfftw3f.so API and fftwf_complex (from fftw3.h) Default fftw3 installation with no subscripts is for double, fftw3l is for long double and fftw3f is for float:) Rescaning 1000 targets from saved packets in the filesystem (no usrp): fftw3: 31 ms fftw3f: 19 ms Time includes the fs I/O to read ~8 MB same for both cases. cpu benefit is clear and always reproducible. Things are not as reproducible or clear with live signals. Additional benefit to uhd for shorter conversions. fftw3: 3.298 s 18 detections fftw3f: 3.279 s 18 detections
I will keep the float fftwf version. HTH Nikos On Mon, May 12, 2025 at 6:57 AM Nikos Balkanas <nbalka...@gmail.com> wrote: > You are right. fftw says that in float precision, it accepts float inputs > to the API. > I assume they mean the libfftwf.so library and the fftwf_* API. > I didn't specify precision in my build. So I got libfftw.so (as opposed to > libfftwf.so or libfftwl.so). > This simplified Makefiles and source code:) I/O with fftw_complex is > still 16 B. > A quick and dirty test with libfftw3.so and complexf I/O resulted with > memory corruption. > > I'll have to investigate this better and use the libfftwf.so library and > fftwf api, when I have more time. > I will update this thread when I do:) > > Thx again, > Nikos > > On Mon, May 12, 2025 at 6:10 AM Nikos Balkanas <nbalka...@gmail.com> > wrote: > >> Thx.I will check it:) >> >> On Mon, May 12, 2025 at 5:53 AM Marcus D. Leech <patchvonbr...@gmail.com> >> wrote: >> >>> On 11/05/2025 22:45, Nikos Balkanas wrote: >>> >>> Yes it is, But input is always double:( >>> >>> BR >>> Nikos >>> >>> Nope. >>> >>> https://www.fftw.org/fftw3_doc/Precision.html >>> >>> The FFTW3F routines used in Gnu Radio take in single-precision (32-bit) >>> and output single-precision (32-bit). In most CPUs, >>> the 64-bit floating-point pathways are slower than 32-bit pathways, >>> which is why FFTW3 has a version of the libraries that >>> process single-precision floating-point exclusively. This has been >>> true literally for at least two decades of FFTW3, since I >>> started using and contributing to Gnu Radio in 2004. >>> >>> Anyway, it's entirely up to you, but there's really no reason to use >>> double-precision floats to process data that on the >>> wire are only 16 bits. >>> >>> >>> >>> On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech <patchvonbr...@gmail.com> >>> wrote: >>> >>>> On 11/05/2025 22:27, Nikos Balkanas wrote: >>>> >>>> Thx Marcus, >>>> >>>> I worked it out 2 days ago. Just my memory allocation. >>>> I am passing input buffer with a global pointer. >>>> I was using global stack allocation. When I switched to >>>> malloc, it just works fine:) >>>> Here is what happened: Input buffs didn't reach the _recv_one_packet() >>>> where >>>> b was evaluated to nil and therefore out_buffs were allocated to nil. >>>> It would be helpful >>>> to check allocations like these and issue a warning. >>>> Input, however, still reached the convert_chdr_1_to_fc64_1_guts but >>>> outputs and therefore output were evaluated to NULL. >>>> With NULL output it was sent through the guts function. >>>> Even commenting out the switch and sending it through >>>> the generic chdr_sc16_to_xx crashed it with no output buffers:( >>>> I am not quite sure why b is not evaluated in _recv_one_packet() >>>> and is available downstream in convert_chdr_1_to_fc64_1_guts >>>> with a global stack allocation. Unstable code? >>>> >>>> Anyway, I need the complex double for libfftw3. Its >>>> input data is (fftw_complex) aka 16 B, no matter >>>> what precision I use. It comes out in float, long double >>>> and quad flavors, but input is the same. >>>> And it blows Opencl fft I was using by 10x! >>>> on the filesystem, less with live signals, >>>> but still faster:) And signal power is hotter:) >>>> >>>> BR >>>> Nikos >>>> >>>> FFTW3 is available in a single-precision instance -- Gnu Radio uses >>>> it. FFTW3F. >>>> >>>> >>>> >>>> On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech < >>>> patchvonbr...@gmail.com> wrote: >>>> >>>>> On 10/05/2025 07:17, Nikos Balkanas wrote: >>>>> >>>>> It turns out that the problem is not just bypassing the sse2 code:( >>>>> After commenting it out, uhd still crashes. The conversion output >>>>> buffers are not created in _recv_one_packet() >>>>> Any ideas why they don't? >>>>> >>>>> TIA >>>>> Nikos >>>>> >>>>> This should *Just work*. >>>>> >>>>> What happens if you use rx_samples_to_file and specify: >>>>> >>>>> --type double >>>>> >>>>> This should write out double-precision (64-bit) complex floats to the >>>>> output file. You should be able to use that example >>>>> code as a bit of a template. >>>>> >>>>> Also, I have to ask, why double precision? Even single-precision >>>>> float has more precision and dynamic range than is >>>>> actually represented by the 16-bit values on the wire, coming from >>>>> the ADCs. By moving to double-precision, unless you >>>>> have a library that only supports double-precision math, you're just >>>>> slowing down your computations for no good reason. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas <nbalka...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I recently changed my host application to complex double. I had to >>>>>> change my stream_args to >>>>>> fc64. I pass my void pointer to uhd_rx_streamer_recv same as before: >>>>>> ptr = (void **)&zin; >>>>>> Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I >>>>>> have only 1196 maxsamples, and crashes. I don't need the sse2 code for my >>>>>> conversion. I only use 1024 complex >>>>>> samples/packet for fft. I am very happy with the >>>>>> generic chdr_sc16_to_xx. >>>>>> Does anyone have any fc64 experience and how one can pass the void >>>>>> buffer pointer to >>>>>> skip the sse2 code? >>>>>> >>>>>> TIA >>>>>> Nikos >>>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>> >>>> >>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
