Benchmarking GHC

[John Meacham]

On Mon, Oct 23, 2006 at 01:06:48PM +0100, Simon Marlow wrote:
> Right, this occurred to me too.  Alternatively we could have the strictness 
> analyser represent a strict enumeration by Int# (I believe there's a ticket 
> for this).
> 
> I think when we discussed this for GHC the conclusion was that the latter 
> was probably easier to implement, because we'd have to re-architect more of 
> GHC to handle a data type with a representation that had a different number 
> of constructors from the source data type (currently the difference between 
> source and representation data types is only handled on a per-constructor 
> basis).
> 
> Still, I prefer the Bool# solution because it seems to expose more to the 
> simplifier.

Yeah, I can probably get some better numbers on how often this
transformation is used, but for the cases of Bool and Ordering, it is _a
lot_. most functions that return Bool do so in a CPR fashion, and most
that take a Bool are strict in it, all of these get unboxed.

Of course, many of these probably would have been inlined away anyway,
so it is hard to say what the actual effect on performance is. but the
code sure looks a lot nicer on inspection. :)   


An alternative to representing them as Int#'s which I considered for a
while was..

data Bool = False | True 

==>

data Bool = Bool# Bool#
data unboxed Bool# = False# | True#
False = Bool# False#
True = Bool# True#

(and at code generation False# just becomes 0 and True# just becomes 1)

this would make a new unboxed type, isomorphic to a subset of the
integers, but a distinct type from them. the advantage being type safety
and not inhibiting optimizations that could benefit from knowing that
the unboxed bool type can only take on two values. Also, I imagine it
might be a bit easier to see what is going on when reading core.

in the end I decided to go with the plain old Int# route, but I am not
fully committed to staying with that choice..

        John

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