On 18.11.2021 19:25, Will Godfrey wrote:
I've attached the results after doing this, then a normal run. This was
with 'build for this computer' set, which will also set -o3
CPU is (dual core) Intel(R) Pentium(R) CPU G3240 @ 3.10GHz Complier is gcc
10.2.1 OS is devuan chimaera yoshimi-power (4-11-2023)
Am 18.11.21 um 21:02 schrieb Kristian Amlie:
I just tried and got similar results as you, Will.
- Optimization: -ffast-math -O0 - Compiler: gcc (Ubuntu
9.3.0-17ubuntu1~20.04) 9.3.0 - CPU: Intel(R) Core(TM) i5-7200U CPU - Yoshimi
branch: Ichthyostega/power
- Config directory: Removed prior to running (I tried switching between 44100
and 48000 on the settings ALSA screen afterwards and then rerun, but this
didn't make a difference)
Indeed, the testrunner loads a state file to control that parameters,
so the personal config directory should not be an issue anymore.
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.
On the bright side, the "Unforeseen state" issue is gone, so one step at a
time!
And another nice thing is: both of you seemingly do not get any timing
errors. Which means, the concept with the "plattform model" and a calibration
plus statistics seems to hold up well.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
