Am I missing something, or is the Tip wrong?
1 次查看(过去 30 天)
显示 更早的评论
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?
0 个评论
采纳的回答
Andy Bartlett
2023-3-20
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.
0 个评论
更多回答(0 个)
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Deployment, Integration, and Supported Hardware 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!