On 19.11.2021 01:32, Ichthyostega wrote: > > Hi Kristian, > Hi Will, > > obviously all these observations and results look somewhat discouraging. > And while -50dB is just barely audible, from a numerical POV these are > significant differences, not just "number dust". > > Seemingly we have several interwoven problems here. > > For one, the AnalogFilter is fragile, and unfortunately it is used on a > lot of places. But this doesn't explain why Will's results show a > difference > on BasicADD.test or on BasicPAD.test -- so there must be at least one > further > problem. > > I captured the Baseline.wav files for the testsuite with Production build > settings, and for the (today most common) Amd64 arch these are > -O3 -msse -msse2 -mfpmath=sse -ffast-math -fno-finite-math-only > > Esp. the use of SSE registers plays a role here (-mfpmath=sse), since > moving values from SSE to normal registers can cause changes on the last > bits (I have seen that in my investigations, but I don't understand the > details well enough to see why this happens). > > So a build with -O0 or a build with just --fast-math (without SSE) gives > differences in that order of magnitude. I have seen that here too. > > > Then there are the compilers. Personally, I am building on gcc-8, and have > tested with gcc-7 and gcc-6. Especially these older ones do something quite > crazy stuff for optimisation. I haven't looked in detail at newer > compilers, > since the setup is still quite tedious. Remote debugging on a different > compiler version / plattform turned out to be rather brittle, and without > using the IDE, it becomes near impossible to do an in-depth analysis, > where you need to drill down into various objects or poke around in > a huge float[] buffer. > > > Btw, those Optimisers do really freaking stuff today. > For example a lot of the SynthEngine code is written in blocks where > we first do this thing on the buffer in a for loop e.g. the volume, and > then comes the next block where we maybe (for stereo) do the same thing > for the other channel in another for loop, and then comes the next block, > where we e.g. apply an envelope in yet another for loop. > The optimisers collapse these consecutive for loops into a single loop > and totally rewrite the logic and sometimes even regroup the computations > and calculate backwards in order to re-use a common subexpression. > I is amazing that all this bold rewritings work that well.
With all these unpredictable effects going on, perhaps we should just turn -ffast-math off and see if that yields something more stable? The -fexcess-precision=fast option, which is implied by -ffast-math, explicitly states that the rounding errors are unpredictable. Other options I can think that might lead to more stable results. -fexcess-precision=standard - I think it's implied if -ffast-math is off. -ffloat-store - Only store floats in memory, not registers. This probably makes it a lot slower, but could make CPU differences less prevalent. -mfpmath=387 - Enables only the traditional 387 floating point processor, no new SSE stuff. After all, we are not interested in testing compilers here. I think if we can get stable results with one or more of those options, we can reasonably assume that the compilers won't destroy the sound simply by turning these on in a release build. -- Kristian _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
