Thank you for the explanation. Inlining does explain the behavior I
was seeing, and -fno-state-hack does make the program behave the way
I'd expect.
I would like to humbly submit that perhaps this optimization should be
off by default. It seems to me that any compiler optimization which
can potentially increase your program's runtime by an order of
complexity is dangerous. Also, while the Haskell Report doesn't seem
to specify anything about lazy evaluation behavior, it seems to me
that in order to program in Haskell, assuming that a computation
assigned to a variable won't be recomputed multiple times is almost as
necessary an assumption as assuming that the compiler will optimize
away tail recursion. For instance GHC FAQ entry 7.2 implicitly
assumes this is true:
http://haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F
In my real program where I ran into this problem it took me quite a
while to figure out why my program's performance wasn't making any
sense, and why seemingly irrelevant changes to my code made the
performance problem go away.
Thank you,
Adam
On Feb 3, 2008, at 3:18 PM, Stefan O'Rear wrote:
On Sun, Feb 03, 2008 at 02:37:42PM -0500, Adam P Jenkins wrote:
The haskell program below demonstrates an optimization bug with the
GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and
on a Linux i686 machine. This email should build as a literate
haskell
program. Build the program as
While this may be unfortunate, it is a consequence of document
behavior; thus I would not consider it a bug per-se. Try with
-fno-state-hack; the documentation for this option, I believe, should
explain what is going on. (Hint: IO a ~ State# -> (State#, a))
Stefan
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
