防止在 Criterion 基准测试中缓存计算答案

【问题标题】：Preventing caching of computation in Criterion benchmark防止在 Criterion 基准测试中缓存计算
【发布时间】：2015-03-30 06:55:05
【问题描述】：

以下代码（由 Reid Barton 在Criterion causing memory consumption to explode, no CAFs in sight 建议）有一个基准时间，它与num成比例 使用O0 优化编译时。然而，使用O3 优化似乎会导致基准时间独立与num。结果被缓存在核心的哪个位置，我可以做些什么来防止它被缓存？

代码是：

{-# OPTIONS_GHC -fno-cse #-}
{-# LANGUAGE BangPatterns #-}
module Main where
import Criterion.Main
import Data.List

num :: Int
num = 100000000

lst :: a -> [Int]
lst _ = [1,2..num]

myadd :: Int -> Int -> Int
myadd !x !y = let !result = x + y in
  result

mysum = foldl' myadd 0

main :: IO ()
main = defaultMain [
  bgroup "summation" 
    [bench "mysum" $ whnf (mysum . lst) ()]
  ]

核心是：

main7
main7 = unpackCString# "mysum"#

main8
main8 = unpackCString# "summation"#

Rec {
$wlgo
$wlgo =
  \ ww_s6vW w_s6vT ->
    case w_s6vT of _ {
      [] -> ww_s6vW;
      : x_a4dz xs_a4dA ->
    case x_a4dz of _ { I# ipv_s4d4 ->
    $wlgo (+# ww_s6vW ipv_s4d4) xs_a4dA
    }
    }
end Rec }

lst1
lst1 = efdtInt 1 2 100000000

lvl_r6yu
lvl_r6yu = case $wlgo 0 lst1 of ww_s6w5 { __DEFAULT -> I# ww_s6w5 }

Rec {
main_$s$wa
main_$s$wa =
  \ sc_s6xB sc1_s6xC sc2_s6xD ->
    case tagToEnum# (<=# sc1_s6xC 0) of _ {
      False ->
    case seq# lvl_r6yu sc2_s6xD of _ { (# ipv_a4BO, ipv1_a4BP #) ->
    main_$s$wa sc_s6xB (-# sc1_s6xC 1) ipv_a4BO
    };
      True -> (# sc2_s6xD, () #)
    }
end Rec }

main6
main6 =
  \ w_s6w9 w1_s6wa ->
    case w_s6w9 of _ { I64# ww1_s6wd ->
    main_$s$wa () ww1_s6wd w1_s6wa
    }

main5
main5 = Benchmark main7 (main6 `cast` ...)

main4
main4 = : main5 ([])

main3
main3 = BenchGroup main8 main4

main2
main2 = : main3 ([])

main1
main1 = \ eta_B1 -> defaultMain2 defaultConfig main2 eta_B1

main9
main9 = \ eta_B1 -> runMainIO1 (main1 `cast` ...) eta_B1

lst
lst = \ @ a_a40V _ -> lst1

main
main = main1 `cast` ...

myadd
myadd =
  \ x_a3Io y_a3Ip ->
    case x_a3Io of _ { I# ipv_s4d1 ->
    case y_a3Ip of _ { I# ipv1_s4d4 -> I# (+# ipv_s4d1 ipv1_s4d4) }
    }

mysum
mysum =
  \ w_s6w2 ->
    case $wlgo 0 w_s6w2 of ww_s6w5 { __DEFAULT -> I# ww_s6w5 }

num
num = I# 100000000

main
main = main9 `cast` ...

我在哪里标记了-ddump-simpl -fforce-recomp -O3 -dsuppress-all 到调用的ghc --make -no-link ... 命令的末尾通过cabal build。我正在使用标准 1.1.0.0 和 GHC 版本 7.8.3。

【问题讨论】：

你可以试试-fno-full-laziness in OPTIONS。
@AndrásKovács 嘿，谢谢，这似乎成功了！你知道结果被缓存在核心的什么地方吗？

标签： haskell ghc

【解决方案1】：

结果被缓存在您的lvl_r6yu 中。可以看到lst1是[0..num]提升到顶层，从$wlgo 0 lst1可以看出求和的结果也提升了。

如果我们添加顶级定义foo = mysum . lst，然后查看foo 的核心，就更容易看到发生了什么。您可以在那里看到foo 是一个返回求和结果的常量函数。

如果我们添加{-# OPTIONS -fno-full-laziness #-}，则子表达式将不会被提升，因此基准测试将按预期工作。

一般来说，使用criterion 通过提供给whnf 的参数来控制评估是一个好主意。在我们的例子中：

bench "mysum" $ whnf (\size -> mysum [1..size]) num

无论优化或提升，这都能正常工作。

【讨论】：