Hi all, I just created an issue for that in the volk GitHub repository: https://github.com/gnuradio/volk/issues/202
The normalized error seemed to be in the ~1e-8 range (errors in volk are normalized to the amplitude of the result in question) Thus it passes the default error threshold of 1e-6. Marcus pointed out offline that some of the intrinsics might even have a better precision compared to the generic implementation. Cheers Andrej On Wed, Oct 03, 2018 at 04:57:32PM -0700, Ron Economos wrote: > It depends on which box I look at. > > 1) volk_32fc_x2_divide_32fc a_avx u_sse3 > > 2) volk_32fc_x2_divide_32fc a_avx u_avx > > Ron > > On 10/03/2018 08:05 AM, Müller, Marcus (CEL) wrote: > > Well, I'd be willing to call that a bug, all in all: > > > > Though I totally get the "machine accuracy" argument, I'd at least > > expect the same results when running the same program twice, on the > > same machine. > > > > Now, I'm an author of one of the 32fc_x2_divide_32fc implementations; > > I'd like to know what I can do to fix this. Ron, what was the machine > > that volk_profile picked for you? > > > > By the way, just as for the float/char (and other ints) conversion > > kernels, it's not inherently obvious who's right or wrong, the > > optimized or the generic impl. So, we should be analyzing which values > > led to the differing result. > > > > Best regards, > > Marcus > > > > On Wed, 2018-10-03 at 06:52 -0700, Ron Economos wrote: > >> That's the problem. If a set_output_multiple(4) in added to the > >> constructor in divide_cc_impl.cc, it solves the issue. > >> > >> Ron > >> > >> On 10/03/2018 06:42 AM, Ron Economos wrote: > >>> Well, I guess it's not really a bug. Most likely it has to do with the > >>> accuracy difference between the x86 intrinsics and the C library. If > >>> you look at the code in volk_32fc_x2_divide_32fc.h, the remaining > >>> points that are not a multiple of four are calculated with the C > >>> library. If the points from one run that are calculated with the C > >>> library line up with points calculated with intrinsics in the next > >>> run, there can be a mismatch. > >>> > >>> Ron > >>> > >>> On 10/03/2018 06:27 AM, Ron Economos wrote: > >>>> It's a VOLK bug. Go into ~/.volk/volk_profile and change the > >>>> volk_32fc_x2_divide_32fc line to generic. That fixes the issue here. > >>>> > >>>> Ron > >>>> > >>>> > >>>> On 10/03/2018 05:46 AM, Piotr Krysik wrote: > >>>>> Hi all, > >>>>> > >>>>> I simplified the flowgraph a bit and prepared a script that runs it > >>>>> twice and compares the results. > >>>>> > >>>>> https://imgur.com/a/CSjOeLc > >>>>> > >>>>> In short something is wrong indeed. > >>>>> Almost after every run of the script I get results with differences. > >>>>> > >>>>> I tested it on GNU Radio 3.7.12.0, I'm compiling the most fresh > >>>>> version > >>>>> now. > >>>>> > >>>>> Best Regards, > >>>>> Piotr Krysik > >>>>> > >>>>> W dniu 03.10.2018 o 06:55, Reiichiro Nakano pisze: > >>>>>> Here's an updated flowgraph where you don't need a separate file > >>>>>> source. Just run the flowgraph twice for a few seconds each. You'll > >>>>>> likely get different file sizes but `cmp` doesn't care, it'll still > >>>>>> show the first differing byte which should still prove the bug exists. > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Andrej Rode GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
signature.asc
Description: Digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio