Go to the first, previous, next, last section, table of contents.


Is Fast Code or Small Code preferred?

If an application uses many floating point functions, it is often the case that the costs of the function calls themselves are not negligible. Modern processor implementation often can execute the operation itself very fast but the call means a disturbance of the control flow.

For this reason the GNU C Library provides optimizations for many of the frequently used math functions. When the GNU CC is used and the user activates the optimizer several new inline functions and macros get defined. These new functions and macros have the same names as the library function and so get used instead of the latter. In case of inline functions the compiler will decide whether it is reasonable to use the inline function and this decision is usually correct.

For the generated code this means that no calls to the library functions are necessary. This increases the speed significantly. But the drawback is that the code size increases and this increase is not always negligible.

The speed increase has one drawback: the inline functions might not set errno and might not have the same precision as the library functions.

In cases where the inline functions and macros are not wanted the symbol __NO_MATH_INLINES should be defined before any system header is included. This will make sure only library functions are used. Of course it can be determined for each single file in the project whether giving this option is preferred or not.

Not all hardware implements the entire IEEE 754 standard, or if it does, there may be a substantial performance penalty for using some of its features. For example, enabling traps on some processors forces the FPU to run unpipelined, which more than doubles calculation time.


Go to the first, previous, next, last section, table of contents.