SQRT optimization

[trogluddite]

Without doing anything, without sending an email, I am again allowed to attach files.

Ah, that's good news! I guess maybe somebody else sent a report which has led Malc to clear something?

The sqrt(x) doesn't deliver what one is expecting. There must me something obvious like an offset

That is very peculiar indeed, and not at all obvious - and very likely a bug in FS.

If you take a multi-line text box and connect it to the (S) output of the DSP primitive, it shows you the compiled assembly for the DSP code. And the compiled assembly is practically the same as the "hand-made" assembly using sqrtps. By changing one register assignment, I made them identical - and still the strange output difference!

I then suspected it might be a known problem where writing to an input variable in a component can change a preceding component's output values (if there is only one source, they may share a memory address, hence you should never write to an input variable). But no - there is no component which does this. I then changed the input variable names in the schematic in case some kind of weird name-sharing was happening - no, nor that, either!

I then changed the DSP code to "b = a" to view the input value. Aha! - this was very strange indeed! The value was not only incorrect; it was continuously changing! To confirm this, I constructed a new DSP component containing the same code - and problem gone!

So, a vanishingly rare bug in FS, it seems. I can only guess that the memory address of the input connector was being shared with something else in the schematic which was overwriting the input value. Quite an entertaining little exercise in debugging - and possibly the strangest FS bug I have ever seen!

[steph_tsf]

So, a vanishingly rare bug in FS, it seems. I can only guess that the memory address of the input connector was being shared with something else in the schematic which was overwriting the input value. Quite an entertaining little exercise in debugging - and possibly the strangest FS bug I have ever seen!

Makes sense, as such sqrt(x) block was used to establish the local feedback loop that's required for elaborating the RMS value of an audio signal.
http://www.dsprobotics.com/support/viewtopic.php?f=3&t=5976&p=28462&hilit=rms+detector#p28462
Dig into the schematic. Enter the "compressor" block. Find the "EnergyDetector" module. Zoom into it.
Possibly, the bug is 100% reproducible in such context. Possibly the "bug" is a side-effect of Flowstone, assessing the dangerosity of local (possibly endless) loops. But wait a moment, local loops appear to be permitted, provided they are governed by the sampling rate (blue stuff, virtual sample-per-sample processing), or provided they consist in processing a block of data whose length is relatively small say 32,768 samples like the data that's coming from a FFT (green stuff).

[trogluddite]

But wait a moment, local loops appear to be permitted...

Yes, that's correct. There's always an implicit one-sample delay in a 'blue' feedback loop - so while such an arrangement might be numerically unstable, it cannot cause an infinite processing loop. There are rare cases in 'green' which can cause an endless trigger loop, but FS does test for, and usually catches, these (the cycle is broken and links turn red).

If you copy/pasted from the linked schematic, this might explain the problem - I notice that Rocko/Spogg spoke of back-porting to FS v3.0.8.1, which suggests that Rocko may have originally used an unstable "beta" version of FS with updated (but buggy) assembler/DSP implementation.

[steph_tsf]

One get scary, upon realizing how thin the ice can be.

[trogluddite]

One get scary, upon realizing how thin the ice can be.

Indeed. I understand the need for beta-testing, but having those betas posted for public download has been rather troublesome, as have the bugs in the 3.0.8 versions. Thankfully, the lesson has been learned, and the risks are explicitly spelled out for those who are testing the current "work in progress".