#1168: Optimisation sometimes decreases sharing in IO code
-------------------------------------+--------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: nofib/spectral/calendar | Architecture: Unknown
Os: Unknown |
-------------------------------------+--------------------------------------
Changes (by simonpj):
* cc: [EMAIL PROTECTED] (added)
Comment:
Adding Adam Jenkins to the cc list. At the end of the above thread he
writes (reasonably enough):
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1168#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
