使用Int64的haskell中的内存消耗

-1 64-bit haskell memory-consumption

问题是找到最后一个元素.它运行良好整数类型.使用Int类型溢出,但是当我尝试Int64时,似乎垃圾收集器停止工作.

module Main (main) where
import Data.Int
import System.Environment

getNum :: Int -> Int64

merge [] s2 = s2
merge s1 [] = s1
merge (s1:s1s) (s2:s2s)
      | s1 < s2 = s1 : (merge s1s (s2:s2s))
      | s1 > s2 = s2 : (merge (s1:s1s) s2s)
      | otherwise = s1 : (merge s1s s2s)

scaleStreams scale = map $ (*) scale       

getNum n = s_3_56!!n
    where s_3_56 = 1:(merge (scaleStreams 2 s_3_56)
                     (merge (scaleStreams 3 s_3_56)
                     (scaleStreams 5 s_3_56 )))

main = do
    snum:_ <- getArgs
    putStrLn $ show $ getNum (read snum) 
Run Code Online (Sandbox Code Playgroud)

UPD.错过了导入Data.Int.需要100,000,000个元素.使用Int64时,它只是停止响应或停止使用处理器.

也许我需要ghc的一些关键因此它可以清理我不需要的元素.

这些都是关于基准测试,所以我需要更清楚的整数.

ham*_*mar 6

根据数字的大小,很明显你会溢出IntInt64.这会搞砸比较merge.

将其更改为使用任意大小Integer,我们可以观察到您的算法似乎表现出近似线性的时间和空间复杂度.

*Main> :set +s
*Main> getNum 10
15
(0.05 secs, 15791376 bytes)
*Main> getNum 100
1600
(0.04 secs, 15805848 bytes)
*Main> getNum 1000
51840000
(0.05 secs, 16849584 bytes)
*Main> getNum 10000
288555831593533440
(0.10 secs, 26238720 bytes)
*Main> getNum 100000
290237644800000000000000000000000000000
(0.39 secs, 149698872 bytes)
*Main> getNum 1000000
519381797917090766274082018159448243742493816603938969600000000000000000000000000000
(3.57 secs, 1440858488 bytes)
*Main> getNum 10000000
16244249195502759967226308067328000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(36.49 secs, 15318940632 bytes)
*Main> getNum 100000000
18140183964781799067475734441903054103752590419562119585784549199072397211943448001454797147212334274622985787416351057209969867746413217762757199393702760885526212114105820164278263467669252072928640885180135225440700708077201852574944496154785156250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(398.26 secs, 173628505536 bytes)
Run Code Online (Sandbox Code Playgroud)

据我所知,垃圾收集器似乎正常工作.100,000,000的运行分配总共173GB内存,但我在任何一次观察到的最高峰值大约是900MB.

  • @rudzon:我的观点是,溢出不仅影响你的计算结果,而且它还会导致像s1 <s2`这样的比较在其中一个溢出并且变为负数时被抛弃,导致你的程序遵循不同的执行路径,甚至可能没有终止.在这种情况下,您无法进行合理的速度测量. (6认同)