Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
sylvain.nahas:
Hi,
This compiler is very promising, for the least.
Here is a small dummy Haskell program. countdown :: Int -> IO () countdown 0 = putStrLn "finished" countdown x = do putStrLn (show x) countdown (x-1) main = countdown 10000000
and the C program that comes to closest. #include
int main(void) { int i; for(i=0; i<10000000; i++) { printf("%d\n",i); } printf("finished\n"); return 0; } GHC is 6.10.1, gcc is 4.3.2, jhc is 0.6.0 arch is i386/Linux(Ubuntu)
$ ghc hello.hs -o hello1 $ jhc hello.hs -o hello2 $ gcc hello.c -o hello3
Oh boy. Compile with optimizations on please! ghc -O2 et al.
Le samedi 21 mars 2009 à 09:58 -0700, Don Stewart a écrit :
Oh boy. Compile with optimizations on please! ghc -O2 et al.
Hi. I had done that, actually, before even my first post, and knew that it changes little to the picture, at least on my system. Please check the other post, where I publish the results with optimization turned on. http://www.haskell.org/pipermail/jhc/2009-March/000311.html I have also tested with another program, from the "Great Computer Language Shootout". http://www.haskell.org/pipermail/jhc/2009-March/000313.html Sylvain Nahas
sylvain
Le samedi 21 mars 2009 à 09:58 -0700, Don Stewart a écrit :
Oh boy. Compile with optimizations on please! ghc -O2 et al.
I had done that, actually, before even my first post, and knew that it changes little to the picture, at least on my system.
I think Bulat was right on the money here: you're essentially testing the efficiency of writing integers. Presumably, JHC is better than GHC at specializing/inlining this library function. -k -- If I haven't seen further, it is by standing in the footprints of giants
On Mon, Mar 23, 2009 at 08:40:02AM +0100, Ketil Malde wrote:
I had done that, actually, before even my first post, and knew that it changes little to the picture, at least on my system.
I think Bulat was right on the money here: you're essentially testing the efficiency of writing integers. Presumably, JHC is better than GHC at specializing/inlining this library function.
Indeed, but isn't being better at specializing/inlining exactly what an optimizing compiler should do. :) In any case, these results are not atypical, generally, if jhc can compile something, it ends up being 2-3x faster than ghc. After all, C-comparable (or even superior) speed is the main goal of jhc development. And if anything, I am more convinced than when I started that the goal is achievable. With jhc today, C comparable performance from numerical code is not difficult to achieve with some attention to strictness annotations. John -- John Meacham - ⑆repetae.net⑆john⑈
Those are impressive results. Typically on programming language benchmarks,
the speed of ghc-generated code fares well against C, sometimes
outperforming it, at best being 20x faster, at worst being 3x slower. Since
it already seems "fast enough", I'm astonished that jhc could make it even
faster.
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=gcc&box=1
Where ghc-generated code fares poorly against other languages is memory
usage. Has there been an effort in jhc to reduce the memory footprint of
generated code? How does it fare against ghc in this area?
Thanks,
Lyle
On Mon, Mar 23, 2009 at 1:09 AM, John Meacham
On Mon, Mar 23, 2009 at 08:40:02AM +0100, Ketil Malde wrote:
I had done that, actually, before even my first post, and knew that it changes little to the picture, at least on my system.
I think Bulat was right on the money here: you're essentially testing the efficiency of writing integers. Presumably, JHC is better than GHC at specializing/inlining this library function.
Indeed, but isn't being better at specializing/inlining exactly what an optimizing compiler should do. :)
In any case, these results are not atypical, generally, if jhc can compile something, it ends up being 2-3x faster than ghc. After all, C-comparable (or even superior) speed is the main goal of jhc development. And if anything, I am more convinced than when I started that the goal is achievable. With jhc today, C comparable performance from numerical code is not difficult to achieve with some attention to strictness annotations.
John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Hi, your post gave me the idea to profile the memory usage of the generated binary with valgrind.
Has there been an effort in jhc to reduce the memory footprint of generated code?
In this release of jhc, the problem is handled in a quite radical way. It seems that no free() is ever emitted, the allocated heap memory is not released. Well, this classifies like a bug, I guess. On the bright side, when I removed all memory deallocation from the C version, supposing (naively maybe) that it would radicaly reduce the difference in performance, jhc's still ran twice faster. Sylvain Nahas
participants (5)
-
Don Stewart -
John Meacham -
Ketil Malde -
Lyle Kopnicky -
sylvain