On Sun, 24 Oct 2021 02:43:43 +0200 Ichthyostega <p...@ichthyostega.de> wrote:
Today, for this experiment, I have now replaced that code explicitly to
always use the expf() with a precomputed logarithm.
...
After those adjustments I now get precisely the same numbers with the
Release builds both on my PC and my laptop. With that first simple test
with just a single sine note of course....
However, I still get different results with Debug builds vs Release builds.
And this is due to the AnalogFilter. Since we're using --fast-math, the
optimiser is allowed to reorder statements....
Am 24.10.21 um 08:44 schrieb Will Godfrey:
I've found in the past that AnalogFilter was 'interesting' and it gets used
in a *lot* of places.
Is this ready to go now?
Hi Will,
Indeed, I'd vote in favour of making that change.
- it is mathematically equivalent
- modern optimisers are applying that replacement under --fast-math anyway
- the expf() function is known to be faster in theory, since it does not
need to do the case distinctions related to a variable base parameter.
- other than that, both pow() and expf() are typically implemented the
same, i.e. with a taylor series
https://www.efunda.com/math/taylor_series/exponential.cfm
And last but not least, by doing this rewriting explicitly in the code,
we remove leeway for the optimiser(s) to do it this way or that way.
I will thus look for all relevant instances of that pattern
and prepare a pull request.
As for the AnalogFilter, I am reluctant to touch /anything/ there,
since it is so extremely sensitive and has a large impact on the sound.
Moreover, theory and engineering of filters is a huge body of knowledge,
and we'd have to spend some time on learning and research if we want
actually to understand the consequences of any surgery.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
