23 Nov
2018
23 Nov
'18
7:37 p.m.
It's probably gonna be silly question, but after short analysis i don't
see, what could be broken in this demo snippet, when float is standard
single-precision 32bit type.
I omit first case, as optimizing compiler could just optimize it to
just =1; though it could do it in second case too... (as assumed, i did
not try to compile it yet).
But even without underhood tricks - 32bit float has 23/24bit for
significand, thus
In Fri, 23 Nov 2018 14:09:02 +0100
Robin Gareus <robin(a)gareus.org> wrote:
On 11/23/2018 01:00 PM, Will Godfrey wrote:
[...]
Thanks for going into this in such detail Robin.
I never realised
fp stuff could be *quite* so, umm, approximate!
Depending on context and the maths, the difference may not matter at
all, or may be off completely..
float a = (1 + 1e20) - 1e20;
float b = 1 + 1e20; b -= 1e20;
printf ("%f %f\n", a, b);
Any guesses what this code prints without compiling it? :)
I was using O3. Following on from this I found
that if I removed
either O3 or ffast-math the problem disappeared.
OK, so SSE/AVX/compiler-intrinsics are the issue at hand.
It's quite possible that I'm
over-thinking this as there are
actually only a few iterations before the initial figures are
re-calculated, but I don't like mysteries :(
You could also disable this for a specific function only
__attribute__((optimize("-fno-fast-math")))
void different_mysteries_here (float val)
{
...
}
ciao,
robin
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev