以下代码(由 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。
最佳答案
结果被缓存在你的 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
无论优化或提升如何,这都可以正常工作。
关于haskell - 防止在 Criterion 基准测试中缓存计算,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/29340053/