...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
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 Boostdevelopment 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 
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 forloop.
Note that if the order of the polynomial or rational function is
a runtime parameter, or the order is greater than the value of 
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 
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 
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 
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.161e007s)

1.13
(9.777e008s)

1.07
(9.289e008s)

1.00
(8.678e008s)

Microsoft C++ 8.0, Rational evaluation 
1.00
(1.443e007s)

1.03
(1.492e007s)

1.20
(1.736e007s)

1.07
(1.540e007s)

Intel C++ 10.0 (Windows), Polynomial evaluation 
1.03
(7.702e008s)

1.03
(7.702e008s)

1.00
(7.446e008s)

1.03
(7.690e008s)

Intel C++ 10.0 (Windows), Rational evaluation 
1.00
(1.245e007s)

1.00
(1.245e007s)

1.18
(1.465e007s)

1.06
(1.318e007s)

GNU G++ 4.2 (Linux), Polynomial evaluation 
1.61
(1.220e007s)

1.68
(1.269e007s)

1.23
(9.275e008s)

1.00
(7.566e008s)

GNU G++ 4.2 (Linux), Rational evaluation 
1.26
(1.660e007s)

1.33
(1.758e007s)

1.00
(1.318e007s)

1.15
(1.513e007s)

Intel C++ 10.0 (Linux), Polynomial evaluation 
1.15
(9.154e008s)

1.15
(9.154e008s)

1.00
(7.934e008s)

1.00
(7.934e008s)

Intel C++ 10.0 (Linux), Rational evaluation 
1.00
(1.245e007s)

1.00
(1.245e007s)

1.35
(1.684e007s)

1.04
(1.294e007s)

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

1.48
(1.387e007s)

1.00
(9.377e008s)


1.11
(4.009e007s)

1.00
(3.598e007s)


1.29
(5.354e006s)

1.00
(4.137e006s)


ibeta_inv and ibetac_inv 
1.44
(2.220e005s)

1.00
(1.538e005s)

1.25
(7.009e005s)

1.00
(5.607e005s)


1.26
(3.116e006s)

1.00
(2.464e006s)


1.27
(1.178e005s)

1.00
(9.291e006s)


1.20
(2.765e005s)

1.00
(2.311e005s)
