bulat.ziganshin:
Hello Simon,
Monday, July 10, 2006, 1:12:13 PM, you wrote:
numerical speed is poor in ghc 6.4, according to my tests. it's 10-20 times worse than of gcc. afair, the mandelbrot benchmark of Great Language Shootout proves this - despite all optimization attempts, GHC entry is still 5-10 times slower than gcc/ocaml/clean ones
We average 1.3x slower than C in the shootout. Thanks to Don Stewart for the following stats...
as i once wrote, most of shootout benchmarks depends on the libs. for example, multi-threading benchmark is much faster on GHC than on GCC because former has user-level threads support pre-included and for later the external libs should be used (testing policy prohibits using of additional libs)
The numerical floating-point-intensive benchmarks:
mandelbrot 2.7x C (Clean 1.7x, OCaml 2.4x, C++ 2.6x) n-body 2.1x C (Clean 0.9x, OCaml 1.3x, C++ 1.4x)
that is the benchmarks that i had in mind
http://shootout.alioth.debian.org/gp4/benchmark.php?test=mandelbrot&lang=all
the same benchmark with N=600 and Sempron processor:
http://shootout.alioth.debian.org/debian/benchmark.php?test=mandelbrot&lang=all
here GHC is 10x slower than GCC and more than 5 times compared to Clean and Ocaml. i think that this is the real computing speed difference while with N=2000 C/Ocaml/Clean programs was really limited by memory speed.
Ah! In this case, on the debian, the benchmark has been compiled _without_ -fexcess-precision, that's what's causing the big slow down. We had to turn it on, on the gp4, but it seems the flag wasn't propagated to the debian/sempron builds for some reason. Looks like the ghc/mandelbrot benchmarks just needs to be rerun with -fexcess-precision in this case. -- Don