Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is an old version of boost. Click here for the latest version's documentation home page.
PrevUpHomeNext

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 49. A Comparison of Polynomial Evaluation Methods

Compiler/platform

Method 0

Method 1

Method 2

Method 3

Microsoft C++ 9.0, Polynomial evaluation

1.26

(7.421e-008s)

1.22

(7.226e-008s)

1.00

(5.901e-008s)

1.04

(6.115e-008s)

Microsoft C++ 9.0, Rational evaluation

1.00

(1.008e-007s)

1.00

(1.008e-007s)

1.43

(1.445e-007s)

1.40

(1.409e-007s)

Intel C++ 11.1 (Windows), Polynomial evaluation

1.18

(6.517e-008s)

1.18

(6.505e-008s)

1.00

(5.516e-008s)

1.00

(5.516e-008s)

Intel C++ 11.1 (Windows), Rational evaluation

1.00

(8.947e-008s)

1.02

(9.130e-008s)

1.49

(1.333e-007s)

1.04

(9.325e-008s)

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 50. 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)



PrevUpHomeNext