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. at least the same situation was for trivial "a[i]=b[i]+c[i]" benchmark discussed half-year ago - when arrays was small enough to fit in cpu cache, speed difference was 20 times. on large arrays C program was limited by memory speed and speed difference was only 3 times
* 2.5x C * 3.2x C * 11.0x C * 22.0x C
* Known, or expected, to improve under Data.ByteString
one more sign that this is more testing of libraries than compilers. for example, revcomp test performs only about 1000 operations in main language but calls regex functions with 100kb strings. not strange that in this test TCL is now fastest entry about numerical apps - afair, Manuel Chakravarty works on new version of his parallel arrays engine -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com