Performance Tuning Macros

| Home | Libraries | People | FAQ | More

### Performance Tuning Macros

There are a small number of performance tuning options that are determined by configuration macros. These should be set in boost/math/tools/user.hpp; or else reported to the Boost-development mailing list so that the appropriate option for a given compiler and OS platform can be set automatically in our configuration setup.

Macro | Meaning
--- | ---
BOOST_MATH_POLY_METHOD | Determines how polynomials and most rational functions are evaluated. Define to one of the values 0, 1, 2 or 3: see below for the meaning of these values.
BOOST_MATH_RATIONAL_METHOD | Determines how symmetrical rational functions are evaluated: mostly this only effects how the Lanczos approximation is evaluated, and how the `evaluate_rational` function behaves. Define to one of the values 0, 1, 2 or 3: see below for the meaning of these values.
BOOST_MATH_MAX_POLY_ORDER | The maximum order of polynomial or rational function that will be evaluated by a method other than 0 (a simple "for" loop).

BOOST_MATH_INT_TABLE_TYPE(RT, IT)

Many of the coefficients to the polynomials and rational functions used by this library are integers. Normally these are stored as tables as integers, but if mixed integer / floating point arithmetic is much slower than regular floating point arithmetic then they can be stored as tables of floating point values instead. If mixed arithmetic is slow then add:

#define BOOST_MATH_INT_TABLE_TYPE(RT, IT) RT

to boost/math/tools/user.hpp, otherwise the default of:

#define BOOST_MATH_INT_TABLE_TYPE(RT, IT) IT

Set in boost/math/config.hpp is fine, and may well result in smaller code.

The values to which `BOOST_MATH_POLY_METHOD` and `BOOST_MATH_RATIONAL_METHOD` may be set are as follows:

Value | Effect
--- | ---
0 | The polynomial or rational function is evaluated using Horner's method, and a simple for-loop. Note that if the order of the polynomial or rational function is a runtime parameter, or the order is greater than the value of `BOOST_MATH_MAX_POLY_ORDER`, then this method is always used, irrespective of the value of `BOOST_MATH_POLY_METHOD` or `BOOST_MATH_RATIONAL_METHOD`.
1 | The polynomial or rational function is evaluated without the use of a loop, and using Horner's method. This only occurs if the order of the polynomial is known at compile time and is less than or equal to `BOOST_MATH_MAX_POLY_ORDER`.
2 | The polynomial or rational function is evaluated without the use of a loop, and using a second order Horner's method. In theory this permits two operations to occur in parallel for polynomials, and four in parallel for rational functions. This only occurs if the order of the polynomial is known at compile time and is less than or equal to `BOOST_MATH_MAX_POLY_ORDER`.
3 | The polynomial or rational function is evaluated without the use of a loop, and using a second order Horner's method. In theory this permits two operations to occur in parallel for polynomials, and four in parallel for rational functions. This differs from method "2" in that the code is carefully ordered to make the parallelisation more obvious to the compiler: rather than relying on the compiler's optimiser to spot the parallelisation opportunities. This only occurs if the order of the polynomial is known at compile time and is less than or equal to `BOOST_MATH_MAX_POLY_ORDER`.

To determine which of these options is best for your particular compiler/platform build the performance test application with your usual release settings, and run the program with the --tune command line option.

In practice the difference between methods is rather small at present, as the following table shows. However, parallelisation /vectorisation is likely to become more important in the future: quite likely the methods currently supported will need to be supplemented or replaced by ones more suited to highly vectorisable processors in the future.

Table 41. A Comparison of Polynomial Evaluation Methods

Compiler/platform | Method 0 | Method 1 | Method 2 | Method 3
--- | --- | --- | --- | ---
Microsoft C++ 8.0, Polynomial evaluation | 1.34 (1.161e-007s) | 1.13 (9.777e-008s) | 1.07 (9.289e-008s) | 1.00 (8.678e-008s)
Microsoft C++ 8.0, Rational evaluation | 1.00 (1.443e-007s) | 1.03 (1.492e-007s) | 1.20 (1.736e-007s) | 1.07 (1.540e-007s)
Intel C++ 10.0 (Windows), Polynomial evaluation | 1.03 (7.702e-008s) | 1.03 (7.702e-008s) | 1.00 (7.446e-008s) | 1.03 (7.690e-008s)
Intel C++ 10.0 (Windows), Rational evaluation | 1.00 (1.245e-007s) | 1.00 (1.245e-007s) | 1.18 (1.465e-007s) | 1.06 (1.318e-007s)
GNU G++ 4.2 (Linux), Polynomial evaluation | 1.61 (1.220e-007s) | 1.68 (1.269e-007s) | 1.23 (9.275e-008s) | 1.00 (7.566e-008s)
GNU G++ 4.2 (Linux), Rational evaluation | 1.26 (1.660e-007s) | 1.33 (1.758e-007s) | 1.00 (1.318e-007s) | 1.15 (1.513e-007s)
Intel C++ 10.0 (Linux), Polynomial evaluation | 1.15 (9.154e-008s) | 1.15 (9.154e-008s) | 1.00 (7.934e-008s) | 1.00 (7.934e-008s)
Intel C++ 10.0 (Linux), Rational evaluation | 1.00 (1.245e-007s) | 1.00 (1.245e-007s) | 1.35 (1.684e-007s) | 1.04 (1.294e-007s)

There is one final performance tuning option that is available as a compile time policy. Normally when evaluating functions at `double` precision, these are actually evaluated at `long double` precision internally: this helps to ensure that as close to full `double` precision as possible is achieved, but may slow down execution in some environments. The defaults for this policy can be changed by defining the macro `BOOST_MATH_PROMOTE_DOUBLE_POLICY` to `false`, or by specifying a specific policy when calling the special functions or distributions. See also the policy tutorial.

Table 42. Performance Comparison with and Without Internal Promotion to long double

Function | GCC 4.2 , Linux (with internal promotion of double to long double). | GCC 4.2, Linux (without promotion of double).
--- | --- | ---
erf | 1.48 (1.387e-007s) | 1.00 (9.377e-008s)
erf_inv | 1.11 (4.009e-007s) | 1.00 (3.598e-007s)
ibeta and ibetac | 1.29 (5.354e-006s) | 1.00 (4.137e-006s)
ibeta_inv and ibetac_inv | 1.44 (2.220e-005s) | 1.00 (1.538e-005s)
ibeta_inva, ibetac_inva, ibeta_invb and ibetac_invb | 1.25 (7.009e-005s) | 1.00 (5.607e-005s)
gamma_p and gamma_q | 1.26 (3.116e-006s) | 1.00 (2.464e-006s)
gamma_p_inv and gamma_q_inv | 1.27 (1.178e-005s) | 1.00 (9.291e-006s)
gamma_p_inva and gamma_q_inva | 1.20 (2.765e-005s) | 1.00 (2.311e-005s)