Benchmarking GHC

[Arjen van Weelden]

John Meacham wrote:
> 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.

The Clean compiler does it also (including Doubles), and it seems to
work well. Re-boxing small/basic types introduces a small penalty, but
specializing polymorphic functions for basic types usually helps. Lazy
and higher-order function applications are (relatively) slow anyway.

> 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
> 
The (unboxed) Bool type in Clean is also implemented as an (unboxed)
Int, other enums are not unboxed however. I found that using only the
values 0 and 1 for booleans, as Clean does, can be a pain when wrapping
foreign C calls, since C uses any non-zero value for True.

	Arjen