On Fri, Aug 10, 2007 at 07:26:28AM +0100, Andrew Coppin wrote:
Stefan O'Rear wrote:
I like pretty pictures.
...and have lots of spare time, apparently. ;-)
Indeed. :)
Probably none. The STG-machine was designed to make user-defined algebraic types very fast.
My program needs to make decisions based on a pair of boolean values. Encoding both values as a single algebraic data type means I have to keep "taking it apart" so I can work with it. I'm not sure how much time this wastes...
Good point...
Probably. I wound up doing something similar with vty, to considerable gain. (I did however use .&. instead of testBit - probably makes no difference, but I'm reminded of the (^2) being much slower than join(*) case...)
Well, perhaps I could define a pair of constants representing the bit masks? (OTOH, won't GHC optimise "testBit <constant>" into something faster anyway?)
Probably not; GHC has few rules for dealing with partial evaluation on numeric arguments. Asking GHC itself: stefan@stefans:/tmp$ ghc -c -ddump-simpl -O2 X.hs ==================== Tidy Core ==================== X.moo [NEVER Nothing] :: forall a_a82. GHC.Base.Int -> a_a82 -> a_a82 -> a_a82 [GlobalId] [Arity 3 NoCafRefs Str: DmdType U(L)LL] X.moo = \ (@ a_a88) (ix_a84 :: GHC.Base.Int) (ift_a85 :: a_a88) (iff_a86 :: a_a88) -> case ix_a84 of wild_acF { GHC.Base.I# x#_acH -> case Data.Bits.$w$s$dmbit 7 of ww1_acN { __DEFAULT -> case GHC.Prim.word2Int# (GHC.Prim.and# (GHC.Prim.int2Word# x#_acH) (GHC.Prim.int2Word# ww1_acN)) of wild1_acO { __DEFAULT -> ift_a85; 0 -> iff_a86 } } } ==================== Tidy Core Rules ==================== stefan@stefans:/tmp$ cat X.hs module X where import Data.Bits {-# NOINLINE moo #-} -- ghc doesn't optimize functions that are deemed small enough for inlining; -- this is a good thing (since when we inline we know more about the context -- and can do a better job if we wait until then), but interferes with small -- experiments like this moo :: Int -> a -> a -> a moo ix ift iff = if testBit ix 7 then ift else iff stefan@stefans:/tmp$ The important bit is the (Data.Bits.$w$s$dmbit 7). Since that function doesn't do IO (no realworld arguments), it could in theory be evaluated at compile time (and judging from context it almost surely evaluates to 128#), but it hasn't been.
Like that time yesterday, I compiled from program and got a weird message about GHC about "ignored trigraphs" or something... What the heck is a trigraph?
Everyone's favorite obscure feature of the ANSI C99 preprocessor. Probably you had something like "this is odd???" in your source code, and were using -cpp. http://www.vmunix.com/~gabor/c/draft.html#5.2.1.1
(I compiled the program again later, and it compiled just fine. Weird...)
Good idea! Maybe it could be fit into the GHC Performance Resource somehow? (http://www.haskell.org/haskellwiki/Performance/GHC)
OK. But it'll probably contain a lot of guessing to start with... ;-)
Wiki pages can be fixed. Private misunderstandings can't, at least not anywhere near as easily. Stefan