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.