13

I have several number-crunching operations that account for a good portion of the CPU time. One example of such operations is this function:

import Data.Number.Erf
import Math.Gamma
import Math.GaussianQuadratureIntegration as GQI

-- Kummer's' "1F1" a.k.a M(a,b,z) Confluent Hypergeometric function
-- Approximation by the Gaussian Quadrature method from 128 up to 1024 points of resolution
kummer :: Double -> Double -> Double -> Double -> Double
kummer a b z err = gammaFactor * integralPart
    where
        gammaFactor       = (gamma b) / (gamma a * gamma (b-a))
        integralPart      = (integrator err) fun 0 1
        fun               = (\t -> (e ** (z * t)) * (1-t) ** (b-a-1) * t ** (a-1))
        e                 = exp 1
        integrator err
                | err > 0.1   =  GQI.nIntegrate128
                | err > 0.01  =  GQI.nIntegrate256
                | err > 0.001 =  GQI.nIntegrate512
                | otherwise   = GQI.nIntegrate1024

SO, I was wondering if there are some rules to follow about when a function should be INLINE to improve performance. REPA Authors suggest to:

Add INLINE pragmas to all leaf-functions in your code, especially ones that compute numeric results. Non-inlined lazy function calls can cost upwards of 50 cycles each, while each numeric operator only costs one (or less). Inlining leaf functions also ensures they are specialized at the appropriate numeric types.

Are these indications also applicable to the rest of the numerical calculations or only to array computations? or is there a more general guide to decide when a function should be inline?

Notice that this post: Is there any reason not to use the INLINABLE pragma for a function? does not address directly the question about if the hints provided by the programmer truly help the compiler to optimize the code.

Community
  • 1
  • 1
felipez
  • 1,212
  • 9
  • 21
  • Style side-question: In the ``integralPart = `` line, would it not be more readable if he wrote ``(integrator err) fun 0 1``? (With brackets)? – BitTickler Apr 21 '15 at 19:52
  • possible duplicate of [Is there any reason not to use the INLINABLE pragma for a function?](http://stackoverflow.com/questions/9709823/is-there-any-reason-not-to-use-the-inlinable-pragma-for-a-function) – crockeea Apr 21 '15 at 20:03
  • 1
    I'm not an expert on this, but I'd follow this recipe. 1) Profile to be really sure this is a performance bottleneck. 2) Check GHC Core (-O2) to see if this is already inlined. 3) Experiment with inlining/LLVM/etc and see what happens (criterion might help here). – chi Apr 21 '15 at 20:05
  • You might also want to experiment with [strictness bang patterns](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html) – Ari Fordsham Oct 26 '20 at 17:47

0 Answers0