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.
--
Chris
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
