【发布时间】:2021-06-21 03:28:05
【问题描述】:
我不太了解 Haskell 优化在内部是如何工作的,但我一直在使用过滤器,非常希望它们被优化成类似于 C++ 中的简单 if 的东西。例如
mapM_ print $ filter (\n -> n `mod` 2 == 0) [0..10]
将编译成等价于
for (int i = 0; i < 10; i++)
if (i%2 == 0)
printf("%d\n", i);
对于长列表(10 000 000 个元素),基本的filter 似乎是正确的,但如果我使用单子filterM,会有很大的不同。我为此速度测试编写了一段代码,很明显filterM 的使用持续时间比使用when 的命令式方法要长得多(250 倍)。
import Data.Array.IO
import Control.Monad
import System.CPUTime
main :: IO ()
main = do
start <- getCPUTime
arr <- newArray (0, 100) 0 :: IO (IOUArray Int Int)
let
okSimple i =
i < 100
ok i = do
return $ i < 100
-- -- of course we don't need IO for a simple i < 100
-- -- but my goal is to ask for the contents of the array, e.g.
-- ok i = do
-- current <- readArray arr (i `mod` 101)
-- return$ i `mod` 37 > current `mod` 37
write :: Int -> IO ()
write i =
writeArray arr (i `mod` 101) i
writeIfOkSimple :: Int -> IO ()
writeIfOkSimple i =
when (okSimple i) $ write i
writeIfOk :: Int -> IO ()
writeIfOk i =
ok i >>= (\isOk -> when isOk $ write i)
-------------------------------------------------------------------
---- these four methods have approximately same execution time ----
---- (but the last one is executed on 250 times shorter list) ----
-------------------------------------------------------------------
-- mapM_ write$ filter okSimple [0..10000000*250] -- t = 20.694
-- mapM_ writeIfOkSimple [0..10000000*250] -- t = 20.698
-- mapM_ writeIfOk [0..10000000*250] -- t = 20.669
filterM ok [0..10000000] >>= mapM_ write -- t = 17.200
-- evaluate array
elems <- getElems arr
print $ sum elems
end <- getCPUTime
print $ fromIntegral (end - start) / (10^12)
我的问题是:这两种方法(使用writeIfOk / 使用filterM ok 和write)不应该编译成相同的代码(迭代列表、询问条件、写入数据)吗?如果没有,我是否可以做一些事情(重写代码、添加编译标志、使用内联编译指示或其他东西)以使它们在计算上等效,或者在性能至关重要时我是否应该始终使用 when?
【问题讨论】:
-
你的最后一次测试只适用于
10000000,而不是10000000*250? -
filterM需要更多时间这一事实并不奇怪:它不受 list fusion 的约束,而且会导致大量的包装和展开在IO对象中,如果没有得到有效优化。 -
您实际上是在要求编译器发现
ok没有副作用,尽管其签名中有IO,并针对这种情况进行优化以启用流式传输。编译器可能会使用足够高级的静态分析来做到这一点,但当前的 GHC 不会。我想这种情况并不常见,因为 Haskell 程序员往往不会将实际上纯粹的东西标记为IO,并且尽可能使用非IO例程。 -
@WillemVanOnsem,列表融合在这里无关紧要。
-
@chi,这还需要一些非常花哨的终止分析才能看到
filterM将始终成功完成。
标签: performance haskell optimization monads io-monad