几个月来,我一直在业余时间学习 Haskell。关于内存子系统(L1、L2、L3 缓存),我想知道 Haskell 在当前库存硬件上的表现如何。有人可以指出任何关于 Haskell 的缓存友好性的报告/研究,因为它的延迟评估/按需调用?有没有办法让我们获得关于发生了多少数据缓存未命中和指令缓存未命中的信息,并查看这是否是由于语言的惰性评估性质造成的?
谢谢。
几个月来,我一直在业余时间学习 Haskell。关于内存子系统(L1、L2、L3 缓存),我想知道 Haskell 在当前库存硬件上的表现如何。有人可以指出任何关于 Haskell 的缓存友好性的报告/研究,因为它的延迟评估/按需调用?有没有办法让我们获得关于发生了多少数据缓存未命中和指令缓存未命中的信息,并查看这是否是由于语言的惰性评估性质造成的?
谢谢。
这是运行时值表示的主要问题。Haskell 中的大多数类型都是“提升的”,即它们可能包含bottom
. 实际上,这意味着 evenInt
由指针表示,指向机器 Int 或计算(可能发散,即 b bottom
)。
这是盒装与提升(与原始)的快速入门。即,Array#
没有提升,因为它可能不是底部,但它是装箱的,因为它可能包含提升的值。
那么这与非严格评估有什么关系呢?未评估的计算称为“thunk”。拥有一个指向 Ints 的指针链表对于缓存局部性来说要糟糕得多,然后拥有一个紧凑的机器整数数组,追逐指向 thunk 的指针也是如此。
这就是为什么有很多研究和工程需求分析的原因——如果无论如何都需要计算的值,则可以将其严格化。
AFAIK,“boxity”分析是需求分析的一部分。无论如何,GHC 会尽可能地摆脱指针。
但不幸的是,我没有这方面的任何经验数据或研究。
编辑:更多关于严格性/盒子分析的阅读:
理查德·艾森伯格的 SO 回答,对“轻浮”(提升/未提升)、底部和undefined
.
编辑2:
从 2002 年找到一篇论文: Nethercote,Mycroft;大型惰性函数程序在库存硬件上的缓存行为