[Haskell-cafe] Re: Chameneos

[Simon Marlow]

Hi Chris,

Rather than try to explain what I'm going on about, I decided to tweak 
the code a bit myself.  My version is about 10% faster than yours, and 
doesn't use any explicit unboxery.  I've put it in the wiki after your 
version.

http://www.haskell.org/hawiki/ChameneosEntry

Could someone upload this to the shootout?

Cheers,
	Simon

Chris Kuklewicz wrote:
> Simon Marlow wrote:
> 
>>I'm not keen on using explicit unboxed values in these benchmarks, since
>>it looks so ugly.  In most cases you can convince GHC to do the unboxing
>>for you, and I'm pretty sure it should be the case here too.  Just use
>>ordinary Ints.
> 
> 
> The syntax is not so pleasing, but it is consistant.
> 
> 
>>It's interesting you're getting some benefit from using integers instead
>>of enumerations.  We've known for a while that enumerations in GHC
>>aren't optimised as well as they could be. 
> 
> 
> So what I am seeing was well known.
> 
> 
>>So, at least for now, this
>>is a useful trick: instead of
>>
>>  data T = A | B | C
>>
>>write
>>
>>  newtype T = T Int
>>
>>  a = T 1
>>  b = T 2
>>  c = T 3
>>
>>and then GHC will be able to unbox T in a constructor field (ie. {-#
>>UNPACK #-} !T will work), and it will also be able to unbox T in a
>>strict argument position.
> 
> 
> I have never used UNPACK or -funbox-strict-fields before. I tried
> several variations -- all slower.
> 
> I never declare "data Foo = Foo Color" so "Foo {-# UNPACK #-} !Color" is
> not possible right now.  I do make a tuple of (Color,MVar Color) and put
> this into an MVar.  Replacing this with data ID = ID {-# UNPACK #-}
> !Color !(MVar Color) has made things a bit worse.
> 
> 
>>Of course you do lose the ability to do pattern matching.
> 
> 
> Which may cause other speed issues.  But I set "complement _ _ = red" to
> remove any performance hit there.
> 
> 
> 
>>Cheers,
>>    Simon
>>
> 
> 
> So I cannot seem to benefit form UNPACK or -funbox-strict-fields at the
> moment.
>