【发布时间】：2017-09-21 22:50:36
【问题描述】：
虽然我有一个很好的 LSFR C 实现，但我想我会在 Haskell 中尝试同样的方法 - 只是想看看效果如何。到目前为止，我想出的比 C 实现慢两个数量级，这就引出了一个问题：如何提高性能？ 显然，摆弄位操作是瓶颈，并且分析器确认了这一点。
这是使用列表和Data.Bits 的基本 Haskell 代码：
import Control.Monad (when)
import Data.Bits (Bits, shift, testBit, xor, (.&.), (.|.))
import System.Environment (getArgs)
import System.Exit (exitFailure, exitSuccess)
tap :: [[Int]]
tap = [
[], [], [], [3, 2],
[4, 3], [5, 3], [6, 5], [7, 6],
[8, 6, 5, 4], [9, 5], [10, 7], [11, 9],
[12, 6, 4, 1], [13, 4, 3, 1], [14, 5, 3, 1], [15, 14],
[16,15,13,4], [17, 14], [18, 11], [19, 6, 2, 1],
[20, 17], [21, 19], [22, 21], [23, 18],
[24,23,22,17], [25, 22], [26, 6, 2, 1], [27, 5, 2, 1],
[28, 25], [29, 27], [30, 6, 4, 1], [31, 28],
[32,22,2,1], [33,20], [34,27,2,1], [35,33],
[36,25], [37,5,4,3,2,1],[38,6,5,1], [39,35],
[40,38,21,19], [41,38], [42,41,20,19], [43,42,38,37],
[44,43,18,17], [45,44,42,41], [46,45,26,25], [47,42],
[48,47,21,20], [49,40], [50,49,24,23], [51,50,36,35],
[52,49], [53,52,38,37], [54,53,18,17], [55,31],
[56,55,35,34], [57,50], [58,39], [59,58,38,37],
[60,59], [61,60,46,45], [62,61,6,5], [63,62] ]
xor' :: [Bool] -> Bool
xor' = foldr xor False
mask :: (Num a, Bits a) => Int -> a
mask len = shift 1 len - 1
advance :: Int -> [Int] -> Int -> Int
advance len tap lfsr
| d0 = shifted
| otherwise = shifted .|. 1
where
shifted = shift lfsr 1 .&. mask len
d0 = xor' $ map (testBit lfsr) tap'
tap' = map (subtract 1) tap
main :: IO ()
main = do
args <- getArgs
when (null args) $ fail "Usage: lsfr <number-of-bits>"
let len = read $ head args
when (len < 8) $ fail "No need for LFSR"
let out = last $ take (shift 1 len) $ iterate (advance len (tap!!len)) 0
if out == 0 then do
putStr "OK\n"
exitSuccess
else do
putStr "FAIL\n"
exitFailure
基本上，它测试tap :: [[Int]] 中为任何给定位长度定义的LSFR 是否具有最大长度。 （更准确地说，它只是检查 LSFR 在 2n 次迭代后是否达到初始状态（零）。）
根据分析器，最昂贵的线路是反馈位d0 = xor' $ map (testBit lfsr) tap'。
到目前为止我已经尝试过：
- 使用
Data.Array：尝试放弃，因为没有foldl/r - 使用
Data.Vector：比基线略快
我使用的编译器选项是：-O2、LTS Haskell 8.12 (GHC-8.0.2)。
参考C++程序可以在gist.github.com找到。
不能期望 Haskell 代码 (?) 运行得和 C 代码一样快，但是两个数量级太多了，必须有更好的方法来做位摆弄。
更新：应用答案中建议的优化的结果
- 输入为 28 的参考 C++ 程序使用 LLVM 8.0.0 编译，在我的机器上运行时间为 0.67 秒（与 clang 3.7 相同，稍慢，0.68 秒）
- 基准 Haskell 代码的运行速度大约慢 100 倍（由于空间效率低下，请勿尝试使用大于 25 的输入）
- 改写@Thomas M. DuBuisson，仍然使用默认的GHC后端，执行时间下降到5.2s
- 随着@Thomas M. DuBuisson的重写，现在使用LLVM后端（GHC选项
-O2 -fllvm），执行时间下降到1.7s- 使用 GHC 选项
-O2 -fllvm -optlc -mcpu=native将这个时间缩短到 0.73 秒
- 使用 GHC 选项
- 在使用 Thomas 的代码时（使用默认的“本机”后端和 LLVM），将
iterate替换为 @cirdec 的iterate'没有区别。但是，当使用基线代码时，它确实会有所不同。
所以，我们的速度从 100x 到 8x 再到 1.09x，即仅比 C 慢 9%！
注意
GHC 8.0.2 的 LLVM 后端需要 LLVM 3.7。在 Mac OS X 上，这意味着使用 brew 安装此版本，然后符号链接 opt 和 llc。见7.10. GHC Backends。
【问题讨论】：
-
你是怎么编译的？什么编译器？什么版本？你是如何执行它的？什么论据？你为什么在这里使用foldr？用于比较的 C 实现在哪里？
-
尝试用更直接的
2^len替换shift 1 len并重新进行基准测试。 -
提前分行是怎么回事？如果您使用
advance ... = shifted .|. fromEnum d0，它似乎更像是其他代码的形式。 -
1.更换分支：好点。但它只会使速度提高 5%。
-
2.将
shift 1 len替换为2 ^ len：2.259s -> 0.178s - 这很奇怪，2^len 只需要一次，为什么这会有所不同？
标签： haskell bit-manipulation bit-fields lfsr