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