TL;DR - 我认为这种情况下的罪魁祸首是 - 将 GHC 默认为 Integer。
诚然，我对 python 的了解不够，但我的第一个猜测是 python 仅在必要时才切换到“bigint”——因此所有计算都是在我的机器上使用 Int 又名 64 位整数完成的。
第一次检查
$> ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
Prelude> maxBound :: Int
9223372036854775807
显示总和的结果 (5000000050000000) 小于该数字，因此我们不必担心 Int 溢出。
我猜你的示例程序大概是这样的
sum.py
print(sum(xrange(100000000)))
sum.hs
main :: IO ()
main = print $ sum [1..100000000]
为了让事情更明确，我添加了类型注释(100000000 :: Integer)，用它编译
$ > stack build --ghc-options="-O2 -with-rtsopts=-sstderr"
并运行您的示例，
$ > stack exec -- time sum
5000000050000000
3,200,051,872 bytes allocated in the heap
208,896 bytes copied during GC
44,312 bytes maximum residency (2 sample(s))
21,224 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 6102 colls, 0 par 0.013s 0.012s 0.0000s 0.0000s
Gen 1 2 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s
INIT time 0.000s ( 0.000s elapsed)
MUT time 1.725s ( 1.724s elapsed)
GC time 0.013s ( 0.012s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 1.739s ( 1.736s elapsed)
%GC time 0.7% (0.7% elapsed)
Alloc rate 1,855,603,449 bytes per MUT second
Productivity 99.3% of total user, 99.4% of total elapsed
1.72user 0.00system 0:01.73elapsed 99%CPU (0avgtext+0avgdata 4112maxresident)k
确实重现了大约 3GB 的内存消耗。
将注释更改为(100000000 :: Int) - 彻底改变了行为
$ > stack build
$ > stack exec -- time sum
5000000050000000
51,872 bytes allocated in the heap
3,408 bytes copied during GC
44,312 bytes maximum residency (1 sample(s))
17,128 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s
Gen 1 1 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s
INIT time 0.000s ( 0.000s elapsed)
MUT time 0.034s ( 0.034s elapsed)
GC time 0.000s ( 0.000s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 0.036s ( 0.035s elapsed)
%GC time 0.2% (0.2% elapsed)
Alloc rate 1,514,680 bytes per MUT second
Productivity 99.4% of total user, 102.3% of total elapsed
0.03user 0.00system 0:00.03elapsed 91%CPU (0avgtext+0avgdata 3496maxresident)k
0inputs+0outputs (0major+176minor)pagefaults 0swaps
感兴趣的朋友
如果您使用 conduit 或 vector 之类的库（装箱和未装箱），haskell 版本的行为不会有太大变化。
示例程序
sumC.hs
import Data.Conduit
import Data.Conduit.List as CL
main :: IO ()
main = do res <- CL.enumFromTo 1 100000000 $$ CL.fold (+) (0 :: Int)
print res
sumV.hs
import Data.Vector.Unboxed as V
{-import Data.Vector as V-}
main :: IO ()
main = print $ V.sum $ V.enumFromTo (1::Int) 100000000
使用的版本足够有趣
main = print $ V.sum $ V.enumFromN (1::Int) 100000000
比上述情况更糟 - 即使documentation 另有说明。
enumFromN :: (Unbox a, Num a) => a -> Int -> Vector a
O(n) 产生一个给定长度的向量，其中包含值 x, x+1
等等。这个操作通常比 enumFromTo 更有效。
更新
@Carsten 的评论让我很好奇 - 所以我查看了整数的来源 - 准确地说是 integer-simple，因为对于 Integer 存在其他版本 integer-gmp 和 integer-gmp2 使用 libgmp。
data Integer = Positive !Positive | Negative !Positive | Naught
-------------------------------------------------------------------
-- The hard work is done on positive numbers
-- Least significant bit is first
-- Positive's have the property that they contain at least one Bit,
-- and their last Bit is One.
type Positive = Digits
type Positives = List Positive
data Digits = Some !Digit !Digits
| None
type Digit = Word#
data List a = Nil | Cons a (List a)
所以当使用Integer 时，与Int 或者更确切地说是未装箱的Int# 相比，内存开销相当大 - 我想这应该被优化，（尽管我还没有确认）。
所以Integer 是（如果我计算正确的话）
- 1 x
Word 用于 sum-type-tag（此处为 Positive
- n x (
Word + Word) 代表Some 和Digit 部分
- 1 x
Word 最后一个None
计算中每个 Integer 的内存开销为 (2 + floor(log_10(n)) + 累加器的内存开销更大。