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.