Benchmarking GHC

John Meacham john at repetae.net
Fri Oct 20 21:27:30 EDT 2006


On Fri, Oct 20, 2006 at 10:38:39AM +0100, Simon Marlow wrote:
> I'm not sure that -funbox-strict-fields always improves performance, even 
> if you only do it on Ints for example.  If you end up pulling out those 
> fields and passing the Int to a lazy function, the Int will be re-boxed 
> each time, leading to more allocation.  This is the reason that 
> -funbox-strict-fields isn't on by defualt, and why I recommend using {-# 
> UNPACK #-} pragmas.

the happy medium I found in jhc was to always unbox any fields whose
representation was smaller or equal to a pointer. It seems to work well.

another worthwhile optimization that benefits from this is unboxing all
enums.

so 
data Bool = False | True 

desugars into

data Bool = Bool# Int#

False = Bool# 0#
True = Bool# 1#

this gives a lot of things the CPR quality that is so good for
optimization and means they can be unboxed in data constructors.

a small problem is that the compiler now doesn't know that Int#'s pulled
out of a Bool# can only take on the values 0# or 1#, which is useful for
things like case alternative elimination. I am not sure how to best
handle it, but right now I am thinking of supporting 'restricted unboxed
integers' somehow...

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈


More information about the Glasgow-haskell-users mailing list