我尝试计算 Ackermann(4,1) ，不同语言/编译器之间的性能差异很大。以下是 Core i7 3820QM，16G，Ubuntu 12.10 64bit 的结果，
C：1.6s ，gcc -O3 （使用gcc 4.7.2）
int ack(int m, int n) {
if (m == 0) return n+1;
if (n == 0) return ack(m-1, 1);
return ack(m-1, ack(m, n-1));
}
int main() {
printf("%d\n", ack(4,1));
return 0;
}
OCaml：3.6s ，ocamlopt （使用ocaml 3.12.1）
let rec ack = function
| 0,n -> n+1
| m,0 -> ack (m-1, 1)
| m,n -> ack (m-1, ack (m, n-1))
in print_int (ack (4, 1))
标准版ML：5.1s mlton -codegen c -cc-opt -O3 （含mlton 20100608）
fun ack 0 n = n+1
| ack m 0 = ack (m-1) 1
| ack m n = ack (m-1) (ack m (n-1));
print (Int.toString (ack 4 1));
球拍：11.5秒 racket （球拍v5.3.3）
(require racket/unsafe/ops)
(define + unsafe-fx+)
(define - unsafe-fx-)
(define (ack m n)
(cond
[(zero? m) (+ n 1)]
[(zero? n) (ack (- m 1) 1)]
[else (ack (- m 1) (ack m (- n 1)))]))
(time (ack 4 1))
Haskell：未完成，在22秒后被系统杀死 ghc -O2 （使用ghc 7.4.2）
Haskell：1.8s ajhc （ajhc 0.8.0.4）
main = print $ ack 4 1
where ack :: Int -> Int -> Int
ack 0 n = n+1
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1))
Haskell版本是唯一一个无法正常终止的版本，因为它占用了太多内存。它会冻结我的机器并在被杀之前填充交换空间。 如果不对代码进行冗长的处理，我该怎么做才能改进呢？
编辑：我很欣赏一些渐近智能的解决方案，但它们并不是我要求的。这更多的是关于查看编译器是否以合理有效的方式处理某些模式（堆栈，尾调用，拆箱等），而不是计算ackermann函数。
编辑2 ：正如几个回复所指出的，这似乎是a bug in recent versions of GHC。我使用AJHC尝试相同的代码并获得更好的性能。
非常感谢：）
答案 0 :(得分：36)
NB：高内存使用问题is a bug in the GHC RTS，在堆上溢出并在堆上分配新堆栈时，未检查垃圾收集是否到期。它已在GHC HEAD中修复。
通过CPS转换ack：
module Main where
data P = P !Int !Int
main :: IO ()
main = print $ ack (P 4 1) id
where
ack :: P -> (Int -> Int) -> Int
ack (P 0 n) k = k (n + 1)
ack (P m 0) k = ack (P (m-1) 1) k
ack (P m n) k = ack (P m (n-1)) (\a -> ack (P (m-1) a) k)
您的原始功能会消耗我机器上的所有可用内存，而这个内存在恒定的空间内运行。
$ time ./Test
65533
./Test 52,47s user 0,50s system 96% cpu 54,797 total
然而，Ocaml仍然更快：
$ time ./test
65533./test 7,97s user 0,05s system 94% cpu 8,475 total
编辑：使用JHC进行编译时，原始程序的速度与Ocaml版本一样快：
$ time ./hs.out
65533
./hs.out 5,31s user 0,03s system 96% cpu 5,515 total
编辑2：我发现的其他内容：使用更大的堆栈块大小（+RTS -kc1M）运行原始程序使其在恒定空间中运行。不过，CPS版本仍然有点快。
编辑3：我设法通过手动展开主循环来生成一个运行速度几乎与Ocaml一样快的版本。但是，它只适用于+RTS -kc1M（Dan Doel has filed a bug关于此行为）：
{-# LANGUAGE CPP #-}
module Main where
data P = P {-# UNPACK #-} !Int {-# UNPACK #-} !Int
ack0 :: Int -> Int
ack0 n =(n+1)
#define C(a) a
#define CONCAT(a,b) C(a)C(b)
#define AckType(M) CONCAT(ack,M) :: Int -> Int
AckType(1)
AckType(2)
AckType(3)
AckType(4)
#define AckDecl(M,M1) \
CONCAT(ack,M) n = case n of { 0 -> CONCAT(ack,M1) 1 \
; 1 -> CONCAT(ack,M1) (CONCAT(ack,M1) 1) \
; _ -> CONCAT(ack,M1) (CONCAT(ack,M) (n-1)) }
AckDecl(1,0)
AckDecl(2,1)
AckDecl(3,2)
AckDecl(4,3)
ack :: P -> (Int -> Int) -> Int
ack (P m n) k = case m of
0 -> k (ack0 n)
1 -> k (ack1 n)
2 -> k (ack2 n)
3 -> k (ack3 n)
4 -> k (ack4 n)
_ -> case n of
0 -> ack (P (m-1) 1) k
1 -> ack (P (m-1) 1) (\a -> ack (P (m-1) a) k)
_ -> ack (P m (n-1)) (\a -> ack (P (m-1) a) k)
main :: IO ()
main = print $ ack (P 4 1) id
测试：
$ time ./Test +RTS -kc1M
65533
./Test +RTS -kc1M 6,30s user 0,04s system 97% cpu 6,516 total
编辑4 ：显然，空间泄漏is fixed in GHC HEAD，以后将不再需要+RTS -kc1M。
答案 1 :(得分：13)
似乎涉及某种错误。您使用的GHC版本是什么？
使用GHC 7，我会得到与您相同的行为。该程序消耗所有可用内存而不产生任何输出。
但是，如果我使用GHC 6.12.1使用ghc --make -O2 Ack.hs编译它，它就可以完美地运行。它在我的计算机上以 10.8s 计算结果，而普通C版本则 7.8s 。
答案 2 :(得分：7)
此版本使用ackermann函数的一些属性。它不等于 其他版本，但它很快：
ackermann :: Int -> Int -> Int
ackermann 0 n = n + 1
ackermann m 0 = ackermann (m - 1) 1
ackermann 1 n = n + 2
ackermann 2 n = 2 * n + 3
ackermann 3 n = 2 ^ (n + 3) - 3
ackermann m n = ackermann (m - 1) (ackermann m (n - 1))
编辑：这是一个带memoization的版本，我们看到很容易在haskell中记忆一个函数，唯一的变化是在调用网站中：
import Data.Function.Memoize
ackermann :: Integer -> Integer -> Integer
ackermann 0 n = n + 1
ackermann m 0 = ackermann (m - 1) 1
ackermann 1 n = n + 2
ackermann 2 n = 2 * n + 3
ackermann 3 n = 2 ^ (n + 3) - 3
ackermann m n = ackermann (m - 1) (ackermann m (n - 1))
main :: IO ()
main = print $ memoize2 ackermann 4 2
答案 3 :(得分：5)
以下是一个惯用的版本，它充分利用了Haskell的懒惰和GHC对常量顶级表达式的优化。
acks :: [[Int]]
acks = [ [ case (m, n) of
(0, _) -> n + 1
(_, 0) -> acks !! (m - 1) !! 1
(_, _) -> acks !! (m - 1) !! (acks !! m !! (n - 1))
| n <- [0..] ]
| m <- [0..] ]
main :: IO ()
main = print $ acks !! 4 !! 1
在这里，我们懒洋洋地为所有 Ackermann函数的值构建矩阵。因此，对acks的后续调用不会重新计算任何内容（即再次评估acks !! 4 !! 1将不使运行时间加倍。）
虽然这不是最快的解决方案，但它看起来很像天真的实现，它在内存使用方面非常高效，并且它重写了Haskell的一种奇怪的特征（懒惰）作为一种强度。
答案 4 :(得分：4)
我根本没有看到这是一个错误，ghc只是没有利用它知道4和1是该函数将被调用的唯一参数的事实 - 也就是说，坦率地说，它不会作弊。它也不会为你做恒定的数学运算，所以如果你写了main = print $ ack (2+2) 1，它就不会计算出2 + 2 = 4直到运行时。 ghc有更重要的事情要考虑。如果你关心它，可以获得后一种困难的帮助http://hackage.haskell.org/package/const-math-ghc-plugin。
如果您进行一些数学计算，ghc会有所帮助，例如这至少比你的C程序快4倍，而4和1作为参数。但试试4＆amp; 2：
main = print $ ack 4 2 where
ack :: Int -> Integer -> Integer
ack 0 n = n + 1
ack 1 n = n + 2
ack 2 n = 2 * n + 3
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1) )
这将在十分之一秒内给出正确的答案，全部~2,000位数，而使用算法的gcc将永远给出错误的答案。
答案 5 :(得分：4)
在Haskell中以类似于在C语言中编写它的方式编写算法并不是相同的算法，因为递归的语义是完全不同的。
这是使用相同数学算法的版本，但我们用符号方式使用数据类型表示对Ackermann函数的调用。这样，我们可以更精确地控制递归的语义。
使用优化编译时，此版本在常量内存中运行，但速度很慢 - 在类似于您的环境中大约需要4.5分钟。但我相信它可以被修改为更快。这只是为了提出这个想法。
data Ack = Ack !Int
ack :: Int -> Int -> Int
ack m n = length . ackR $ Ack m : replicate n (Ack 0)
where
ackR n@(Ack 0 : _) = n
ackR n = ackR $ ack' n
ack' [] = []
ack' (Ack 0 : n) = Ack 0 : ack' n
ack' [Ack m] = [Ack (m-1), Ack 0]
ack' (Ack m : n) = Ack (m-1) : ack' (Ack m : decr n)
decr (Ack 0 : n) = n
decr n = decr $ ack' n
答案 6 :(得分：3)
在Apple XCode更新到4.6.2之后，这个性能问题（显然除了GHC RTS bug）似乎已经在OS X 10.8上修复了。我仍然可以在Linux上重现它（我已经使用GHC LLVM后端进行了测试），但是在OS X上已经不再重复了。在我将XCode更新到4.6.2之后，新版本似乎影响了GHC后端代码生成阿克曼基本上（从我记得从更新前的对象转储）。我能够在XCode更新之前重现Mac上的性能问题 - 我没有这些数字，但它们肯定非常糟糕。因此，似乎XCode更新改进了Ackermann的GHC代码生成。
现在，C和GHC版本都非常接近。 C代码：
int ack(int m,int n){
if(m==0) return n+1;
if(n==0) return ack(m-1,1);
return ack(m-1, ack(m,n-1));
}
执行ack（4,1）的时间：
GCC 4.8.0: 2.94s
Clang 4.1: 4s
Haskell代码：
ack :: Int -> Int -> Int
ack 0 n = n+1
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1))
执行确认4 1的时间（使用+ RTS -kc1M）：
GHC 7.6.1 Native: 3.191s
GHC 7.6.1 LLVM: 3.8s
所有编译都带有-O2标志（和-rtsopts标志，用于GHC for RTS bug解决方法）。尽管如此，这是一个令人头疼的问题。更新XCode似乎与GHC中Ackermann的优化有很大的不同。