Quelques benchmarks avec Ackermann

Un billet qui va peut-être intéresser quelqu’un et répondre à une question que je me pose.

$ gcc -Wall ./ackermann.c -o ackermann-c
$ go build -o ackermann-go ./ackermann.go
$ ocamlc ./ackermann.ml -o ackermann-ocaml
$ ghc ./ackermann.hs -o ackermann-haskell
$ python -c "import ackermann-python"
$ time ./ackermann-c 3 12
32765

real    0m4.345s
user    0m4.320s
sys     0m0.012s
$ time ./ackermann-go 3 12
32765

real    0m4.453s
user    0m4.436s
sys     0m0.000s
$ time ./ackermann-ocaml 3 12
32765

real    0m13.094s
user    0m13.053s
sys     0m0.000s
$ time ./ackermann-haskell 3 12
32765

real    1m11.108s
user    1m10.616s
sys     0m0.268s
$ time python ackermann-python.pyc 3 12
32765

real    2m33.121s
user    2m32.518s
sys     0m0.088s

Voici les codes respectifs: ackermann.c, ackermann.go, ackermann.ml, ackermann.hs et ackermann.py. Évidemment, j’ai fais les tests avec la version correspondant à la définition de la fonction (version naïve). Je peux même lancer tous les tests en même temps grâce aux 8 coeurs de li7. Ça ne change pas beaucoup les résultats!

Je pense que vous avez compris quelle est ma question. J’ai fais plusieurs tests et lécart entre la version OCaml et Haskell est toujours aussi important (y compris en utilisant ocamlrun ./ackermann-ocaml). Les résultats avec les mplémentations C, Go et Python ne sont pas vraiment une surprise.

Il y a tout de même presque une minute de différence entre les versions OCaml et Haskell. J’aimerai bien savoir ce que fait le compilateur OCaml afin d’avoir de si bons résultats (qui ne devrait pas être comparé à du C en fait).

Related Posts