#2252: Extreme performance degradation on minor code change
----------------------+-----------------------------------------------------
Reporter: simona | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: Linux |
----------------------+-----------------------------------------------------
Comment (by simona):
Gosh I hope this isn't happening since I used the timing results of the
good code in a paper.
Adding `-fno-full-laziness` to the compilation of `GoodPerform.hs` changes
nothing (thankfully). Note also that the good performer is less likely to
benefit from lazyness optimization since it first runs one loop for 1000
times, then another loop for 1000 times. The bad one has the potential for
optimization since it runs two nearly identical calculations 1000 times. I
might be possible, of course, that the loops in the good code are simple
enough for optimizations to kick in whereas they are too big in the bad
case. However, I ran other, more complex loops that have a good
performance, too. I'm still assuming that it is the bad code that triggers
some bad behavior.
There is one side-effect in each loop iteration which tests some invariant
on the result. There are quite a few computations that call the external
library but which are pure, so I've wrapped them in `unsafePerformIO`. I
don't know if that matters.
Also, I should mention that both programs run in constant space (around
20MB virtual space), hence it's not a space leak that keeps back the
tighter loop in `BadPerform.hs`. I compiled the code without any -O flags
and I attach the two simplifier outputs. There are no `lvl_` strings in
either file.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2252#comment:2>
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
