Am I missing something, or is the Tip wrong?

I am looking to optimize my code for execution speed. (Embedded coder, simulink)

This option has bothered me for quite some time though, as I have seen mixed results from ticking and unticking "Saturate on integer overflow" in all different types of Simulink blocks.

According to the Tip, as seen of the left, the code efficiency is supposed to increase when I untick this box. However, as unticking the box results in a fmodf (modulous) function call being generated with the box unticked, I am really confused by the statement that this option should be unticked for optimized code efficiency. When the box is ticked, the generated code will still have the same range check, but the result of being out of range is simply that the value gets saturated at the maximum value for that specific datatype (instead of wrapping via modulous function).

so... is the 'Tip' simply wrong, or am I missing something?

Answer 1

[Andy Bartlett]

Hi,

The advise is generally correct.

Turning off Integer Saturation and allowing the math to wrap modulo 2^N will lead to leaner and faster code in MOST cases.

The BIG EXCEPTION is converting from floating-point to integer/fixed-point.

As you've noted, the generated code for a wrapping cast from floating-point to integer/fixed-point will involve a costly call to floating-point modulo. The call to modulo is needed because the C/C++ language says that behavior for an out of range cast from floating-point to integer is undefined. The call to modulo in the generated code forces a wrapping 2^N behavior that is consistent with Simulink simulations. This consistency is incredibly helpful in simplifying back to back testing of simulation and generated code.

There is a way to get rid of the modulo calls in generated code for floating-point to integer/fixed-point cases.

Model Parameter -> EfficientFloat2IntCast

Remove code from floating-point to integer conversions that wraps out-of-range values

For floating-point to integer conversions, simulation handles out-of-range

values by saturation or by modulo power of two wrapping. Generating code to

force out-of-range wrapping provides agreement with simulation. Removing

wrapping code affects only out-of-range values and increases efficiency.

But keep in mind that if overflows do occur in "wrapping" floating-point to integer/fixed-point casts the behavior is implementation dependent and almost certainly will not agree with simulation.

If you want the fastest code with a consistent behavior for floating-point to integer/fixed-point overflows use saturation for those cases. If you definitely won't have overflows in floating-point to integer/fixed-point casts or don't care what happens when they do, then the fastest is wrapping casts with EfficientFloat2IntCast ON.

For the fastest casts, be sure to set rounding mode to simplest. For floating-point to integer/fixed-point, this will automatically pick round to zero which matches the C standard and is the fastest. For integer/fixed-point to integer/fixed-point casts, simplest will automatically map to Round to Floor which is the fastest for those types of casts.