Why does a simulation containing Analog Filter Design block from Signal Processing Blockset run slowly under some input conditions?

I have a model (please refer to the attached model) which uses the Analog Filter Design block from the Signal Processing Blockset which implements a Butterworth Lowpass filter. The input to this block is a step wave.

When the step is made from an initial value of '1' to a final value of '0', the time taken for the simulation is very high compared to the step input with an initial value of '2' to a final value of '1'.

Note that the step size in both the cases is same and I would expect the simulation times to be very close if not exactly the same.

Answer 1

[MathWorks Support Team]

The Analog Filter Design block uses the state-space functionality under the mask. This issue is caused because in case of the state-space block the simulation is very different under different conditions of a step input.

This is not a bug in the software. It is due to denormals. Anything that decays to zero is a candidate for having denormal underflow. If that is the case, it is a design "feature" of the underlying hardware and not a bug in MathWorks products.

The example executables (using RTW-ERT generated code and modifying the main problem to turn on/off the IEEE compliant denormal handling) were created to illustrate this problem compiled off the following files:

denormal_demo_types.h

denormal_demo_private.h

denormal_demo.h

denormal_demo.c

The executables for glnxa64 and pcwin platforms are attached with this solution as the following files:

denormal_demo_pcwin.exe

denormal_demo_glnxa64

Here is how to see the problem using these executables.

First run the executable with the default IEEE compilant denormal handling:

   tic; system(['denormal_demo_pcwin']); toc

This runs in IEEE-754 compliant mode for handling denormal numbers (gradual underflow) :

    ** created denormal_demo.mat ** 

    Elapsed time is 22.227832 seconds.

Now run it in non-IEEE compilant model (with the ftz option) to see that it runs much faster:

   tic; system(['denormal_demo_pcwin ftz']); toc

This runs in non IEEE-754 compliant mode for handling denormal numbers (flush to zero)

    ** created denormal_demo.mat ** 

    Elapsed time is 1.550579 seconds.

These executables demonstrate the slowdown due to denormal handling on Intel and AMD processors that have an SSE unit, where the "flush to zero" can be controlled by the user either via compiler flags (if the compiler provides such a flag) or by expiclity calling an api function from the code (as it is done in denormal_demo_main.c here)

Unfortuanately on older Intel and AMD processors that do not have the SSE unit, where x87 is used for floating point operations, users have no control over denormal handling. It is always the default ieee 754 compliant "gradual underflow" mode which is expensive (compared to the non-compiant "flush to zero" mode).

Mathematical operations in MATLAB, Simulink and RTW generated code are IEEE 754 compliant, which trumps any performance (some times dramatic) gains by being non-compiliant.

The performance issue with denormal floating point numbers appears to be rather well known and not limited to Intel/AMD chips. Here is a good reference on this topic: