7

好吧，事实证明我在我的程序代码中定义了这个函数：

st_zipOp :: (a -> a -> a) -> Stream a -> Stream a -> Stream a
st_zipOp f xs ys = St.foldr (\x r -> st_map (f x) r) xs ys

它做它看起来做的事情。它使用 type 的内部运算符压缩（多次应用运算符，是的）两个 type 元素Stream a，这是一个类似列表的类型a。定义非常简单。

一旦我以这种方式定义了函数，我就尝试了另一个版本：

st_zipOp :: (a -> a -> a) -> Stream a -> Stream a -> Stream a
st_zipOp = St.foldr . (st_map .)

据我所知，这与上面的定义完全相同。它只是先前定义的无点版本。

但是，我想检查是否有任何性能变化，我发现，确实，无点版本使程序运行得稍差（无论是在内存上还是在时间上）。

为什么会这样？如果有必要，我可以编写一个重现此行为的测试程序。

如果这有所作为，我正在编译-O2。

简单的测试用例

我编写了以下代码，试图重现上述行为。这次我使用了列表，性能的变化不太明显，但仍然存在。这是代码：

opEvery :: (a -> a -> a) -> [a] -> [a] -> [a]
opEvery f xs ys = foldr (\x r -> map (f x) r) xs ys

opEvery' :: (a -> a -> a) -> [a] -> [a] -> [a]
opEvery' = foldr . (map .)

main :: IO ()
main = print $ sum $ opEvery (+) [1..n] [1..n]
 where
  n :: Integer
  n = 5000

使用opEvery（显式参数版本）的分析结果：

total time  =        2.91 secs   (2906 ticks @ 1000 us, 1 processor)
total alloc = 1,300,813,124 bytes  (excludes profiling overheads)

分析结果使用opEvery'（无点版本）：

total time  =        3.24 secs   (3242 ticks @ 1000 us, 1 processor)
total alloc = 1,300,933,160 bytes  (excludes profiling overheads)

但是，我希望这两个版本是等效的（在所有意义上）。

4

2 回答 2

12

对于简单的测试用例，两个版本在使用优化编译时产生相同的内核，但没有进行分析。

在启用分析 ( -prof -fprof-auto) 的情况下编译时，pointfull 版本被内联，导致主要部分是

Rec {
Main.main_go [Occ=LoopBreaker]
  :: [GHC.Integer.Type.Integer] -> [GHC.Integer.Type.Integer]
[GblId, Arity=1, Str=DmdType S]
Main.main_go =
  \ (ds_asR :: [GHC.Integer.Type.Integer]) ->
    case ds_asR of _ {
      [] -> xs_r1L8;
      : y_asW ys_asX ->
        let {
          r_aeN [Dmd=Just S] :: [GHC.Integer.Type.Integer]
          [LclId, Str=DmdType]
          r_aeN = Main.main_go ys_asX } in
        scctick<opEvery.\>
        GHC.Base.map
          @ GHC.Integer.Type.Integer
          @ GHC.Integer.Type.Integer
          (GHC.Integer.Type.plusInteger y_asW)
          r_aeN
    }
end Rec }

（没有分析你会得到更好的东西）。

当编译启用分析的无点版本时，opEvery'不是内联的，你得到

Main.opEvery'
  :: forall a_aeW.
     (a_aeW -> a_aeW -> a_aeW) -> [a_aeW] -> [a_aeW] -> [a_aeW]
[GblId,
 Str=DmdType,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False,
         ConLike=False, WorkFree=False, Expandable=False,
         Guidance=IF_ARGS [] 80 60}]
Main.opEvery' =
  \ (@ a_c) ->
    tick<opEvery'>
    \ (x_ass :: a_c -> a_c -> a_c) ->
      scc<opEvery'>
      GHC.Base.foldr
        @ a_c
        @ [a_c]
        (\ (x1_XsN :: a_c) -> GHC.Base.map @ a_c @ a_c (x_ass x1_XsN))

Main.main4 :: [GHC.Integer.Type.Integer]
[GblId,
 Str=DmdType,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False,
         ConLike=False, WorkFree=False, Expandable=False,
         Guidance=IF_ARGS [] 40 0}]
Main.main4 =
  scc<main>
  Main.opEvery'
    @ GHC.Integer.Type.Integer
    GHC.Integer.Type.plusInteger
    Main.main7
    Main.main5

当您添加一个{-# INLINABLE opEvery' #-}pragma 时，即使在编译分析时它也可以被内联，给出

Rec {
Main.main_go [Occ=LoopBreaker]
  :: [GHC.Integer.Type.Integer] -> [GHC.Integer.Type.Integer]
[GblId, Arity=1, Str=DmdType S]
Main.main_go =
  \ (ds_asz :: [GHC.Integer.Type.Integer]) ->
    case ds_asz of _ {
      [] -> lvl_r1KU;
      : y_asE ys_asF ->
        GHC.Base.map
          @ GHC.Integer.Type.Integer
          @ GHC.Integer.Type.Integer
          (GHC.Integer.Type.plusInteger y_asE)
          (Main.main_go ys_asF)
    }
end Rec }

这甚至比 pragma-less pointfull 版本快一点，因为它不需要勾选计数器。

该案很可能发生了类似的影响Stream。

外卖：

  • 分析会抑制优化。没有分析的等效代码可能没有分析支持。
  • 切勿使用为分析或未优化而编译的代码来衡量性能。
  • 分析可以帮助您找出代码中的时间花在哪里[但是，有时启用分析可以完全改变代码的行为；任何严重依赖重写规则优化和/或内联的东西都是发生这种情况的候选者]，但它不能告诉你你的代码有多快。
于 2013-01-31T12:39:45.843 回答
2

这是我要说的一个很大的假设，但我认为编译器没有足够的信息来优化你的程序。虽然没有直接回答您的问题，而是将Eq a约束添加到两个函数（作为测试），但我从 pointfree 变体中得到了改进。见附图（拆分说明）

Right -> TOP = everyOp initial, BOTTOM = everyOp' initial
Left  -> TOP = everyOp with Eq a constraint, BOTTOM = everyOp' Eq a constraint

在此处输入图像描述

编辑：我正在使用 GHC 7.4.2

于 2013-01-31T12:00:27.933 回答