Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Andrej Rode]

Another kernel with a lot of variying precision is the log2
implementation since it's currently a polynomial approximation with a
6-th degree polynomial.

The glibc implementation uses a 14-th degree polynomial to approximate
log2 which turns out to have a maximum error of 2**-58.45.

Probably the log2 approx. should be improved to a point where the
maximum normalized error is always less than 0.15.
The current implementation produces large normalized errors for input
values close to 1.

```
offset 98458 in1: -1.70264e-05 in2: -2.47955e-05 measured error was: 0.456301
 tolerance was: 0.15
```

Cheers
Andrej

On Mon, Oct 08, 2018 at 06:37:50PM +0200, Andrej Rode wrote:
> 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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> -- 
> Andrej Rode
> GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA



> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> 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