Haskell 列表生成器高内存使用

Question

在处理一个竞争性编程问题时，我发现了一个有趣的问题，它大大降低了我的一些代码的性能。经过大量实验后，我设法将问题简化为以下最小示例：

module Main where

main = interact handle

handle :: String -> String
-- handle s = show $ sum l
-- handle s = show $ length l
-- handle s = show $ seq (length l) (sum l)
  where
    l = [0..10^8] :: [Int]

如果您单独取消注释每个注释行，使用ghc -O2 test.hs 编译并使用time ./test > /dev/null 运行，您应该会得到如下内容：

对于sum l：

0.02user 0.00system 0:00.03elapsed 93%CPU (0avgtext+0avgdata 3380maxresident)k
0inputs+0outputs (0major+165minor)pagefaults 0swaps

对于length l：

0.02user 0.00system 0:00.02elapsed 100%CPU (0avgtext+0avgdata 3256maxresident)k
0inputs+0outputs (0major+161minor)pagefaults 0swaps

对于seq (length l) (sum l)：

5.47user 1.15system 0:06.63elapsed 99%CPU (0avgtext+0avgdata 7949048maxresident)k
0inputs+0outputs (0major+1986697minor)pagefaults 0swaps

看看峰值内存使用量的巨大增长。这在一定程度上是有道理的，因为 sum 和 length 都可以懒惰地将列表作为流消耗，而 seq 将触发对整个列表的评估，然后必须存储该列表。但是seq 版本的代码只使用了 8 GB 的内存来处理一个仅包含 400 MB 实际数据的列表。 Haskell 列表的纯函数性质可以解释一些小的常数因素，但内存增加 20 倍似乎是无意的。

这种行为可以由许多事情触发。也许最简单的方法是使用Control.DeepSeq 中的force，但我最初遇到这种情况的方式是在使用Data.Array.IArray（我只能使用标准库）并尝试从列表构造数组时。 Array 的实现是一元的，因此强制对构造它的列表进行评估。

如果有人对这种行为的根本原因有任何见解，我很想知道为什么会发生这种情况。当然，我也很感谢有关如何避免此问题的任何建议，请记住，在这种情况下我必须只使用标准库，并且每个 Array 构造函数都会采用并最终强制一个列表。

我希望你和我一样觉得这个问题很有趣，但希望不那么令人困惑。

编辑： user2407038 的评论让我意识到我忘记发布分析结果。我已经尝试分析此代码，分析器只是声明 100% 的分配是在handle.l 中执行的，所以似乎任何强制评估列表的东西都会使用大量内存。正如我上面提到的，使用来自Control.DeepSeq 的force 函数，构造一个Array，或者任何其他强制列表的东西都会导致这种行为。我很困惑为什么它需要 8 GB 的内存来计算包含 400 MB 数据的列表。即使列表中的每个元素都需要两个 64 位指针，这仍然只是 5 的因数，我认为 GHC 将能够做一些比这更有效的事情。如果不是，这对于Array 包来说是一个明显的瓶颈，因为构造任何数组本质上都需要我们分配比数组本身更多的内存。

所以，最终：有谁知道为什么强制列表需要如此大量的内存，而这会带来如此高的性能成本？

编辑： user2407038 提供了指向非常有用的GHC Memory Footprint 参考的链接。这准确地解释了一切的数据大小，几乎完全解释了巨大的开销：[Int] 被指定为需要 5N+1 个字的内存，每个字 8 个字节，每个元素 40 个字节。在此示例中，建议使用 4 GB，占总峰值使用量的一半。然后很容易相信 sum 的评估会添加一个类似的因素，所以这回答了我的问题。

感谢所有评论者的帮助。

编辑：正如我上面提到的，我最初遇到了这种行为，为什么要构造Array。在对GHC.Arr 进行了一些研究之后，我发现了我认为在构造数组时这种行为的根本原因：构造函数折叠列表以在 ST monad 中编写一个程序，然后运行该程序。显然 ST 在完全组合之前无法执行，在这种情况下，ST 构造将很大并且与输入的大小呈线性关系。为了避免这种行为，我们必须以某种方式修改构造函数，以便在将元素添加到 ST 时从列表中流式传输元素。

Answer 1

这里有多种因素在起作用。第一个是 GHC 会懒惰地将 l 从 handle 中提取出来。这将使handle 能够重用l，这样您就不必每次都重新计算它，但在这种情况下会造成空间泄漏。如果你-ddump-simplified core，你可以检查一下：

Main.handle_l :: [Int]                                                   
[GblId,                                                                  
 Str=DmdType,                                                            
 Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False,         
         WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 40 0}]    
Main.handle_l =                                                          
  case Main.handle3 of _ [Occ=Dead] { GHC.Types.I# y_a1HY ->             
  GHC.Enum.eftInt 0 y_a1HY                                               
  }

计算[0..10^7] ^₁ 的功能隐藏在其他函数中，但本质上，handle_l = [0..10^7] 位于顶层 (TopLvl=True)。它不会被回收，因为您可能会也可能不会再次使用handle。如果我们使用handle s = show $ length l，l 本身将被内联。您将找不到任何类型为 [Int] 的 TopLvl=True 函数。

所以 GHC 检测到您使用了两次 l 并创建了一个顶级 CAF。 CAF 有多大？ Int 需要两个字：

data Int = I# Int#

I# 一个，Int# 一个。 [Int]多少钱？

data [a] = [] | (:) a ([a]) -- pseudo, but similar

[] 一个字，(:) a ([a]) 三个字。因此，大小为 N 的 [Int] 列表的总大小为 (3N + 1) + 2N 个字，在您的情况下为 5N+1 个字。鉴于你的记忆，我假设你平台上的一个单词是 8byte，所以我们最终得到

5 * 10^8 * 8 bytes = 4 000 000 000 bytes

那么我们如何摆脱这个列表呢？我们的第一个选择是摆脱l：

handle _ = show $ seq (length [0..10^8]) (sum [0..10^8])

由于foldr/buildr 规则，它现在将在恒定内存中运行。虽然我们有两次[0..10^8]，但它们的名字不同。如果我们检查-stats，我们会看到它在常量内存中运行：

> SO.exe +RTS -s                                                                
5000000050000000   4,800,066,848 bytes allocated in the heap                    
         159,312 bytes copied during GC                                         
          43,832 bytes maximum residency (2 sample(s))                          
          20,576 bytes maximum slop                                             
               1 MB total memory in use (0 MB lost due to fragmentation)        

                                     Tot time (elapsed)  Avg pause  Max pause   
  Gen  0      9154 colls,     0 par    0.031s   0.013s     0.0000s    0.0000s   
  Gen  1         2 colls,     0 par    0.000s   0.000s     0.0001s    0.0002s   

  INIT    time    0.000s  (  0.000s elapsed)                                    
  MUT     time    4.188s  (  4.232s elapsed)                                    
  GC      time    0.031s  (  0.013s elapsed)                                    
  EXIT    time    0.000s  (  0.001s elapsed)                                    
  Total   time    4.219s  (  4.247s elapsed)                                    

  %GC     time       0.7%  (0.3% elapsed)                                       

  Alloc rate    1,146,284,620 bytes per MUT second                              

  Productivity  99.3% of total user, 98.6% of total elapsed

但这并不是很好，因为我们现在必须跟踪[0..10^8] 的所有使用情况。如果我们改为创建一个函数呢？

handle :: String -> String
handle _ = show $ seq (length $ l ()) (sum $ l ())
  where
    {-# INLINE l #-}
    l _ = [0..10^7] :: [Int]

这可行，但我们必须内联l，否则如果我们使用优化，我们会遇到与以前相同的问题。 -O1（和-O2）启用-ffull-laziness，它与公共子表达式消除一起会将l () 提升到顶部。所以我们要么需要内联它，要么使用-O2 -fno-full-laziness 来防止这种行为。

---

^₁ 必须减小列表大小，否则我会开始交换。