Re: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
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
Re: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
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=alllang=ghclang2=gccbox=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 j...@repetae.net wrote: 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
On Thu, Mar 19, 2009 at 03:22:33PM +0100, Alberto G. Corona wrote: The last version still uses a region inference algoritm instead of a garbage collector?. It turns out the choice of garbage collector is fairly independent of the rest of the compiler, so there is a flag to decide on what garbage collector to use (or none). Right now, however, there isn't really a universally good choice, the boehm gc will work, but it is quite slow. I am working on a middle of the road solution between full static analysis and garbage collection based on the mercury garbage collector for compilation to C, but of course, when compiling to something like llvm or C--, a different garbage collector might be in order. So, It is likely jhc will have multiple choices when it comes to garbage collection for a while until an obviously correct answer emerges. In the meantime, improving the static analysis (such as full region inference will do) helps all back ends so I will likely spend some time focusing on that. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
