#4005: paraffins: slowdown of ca 2 with -O2
-----------------------------+----------------------------------------------
Reporter: hwloidl | Owner: igloo
Type: bug | Status: new
Priority: high | Milestone: 6.12.3
Component: Compiler | Version: 6.12.1 RC1
Keywords: optimisation | Difficulty:
Os: Linux | Testcase: see attached (compile and run) log
Architecture: x86 | Failure: Runtime performance bug
-----------------------------+----------------------------------------------
Comment(by simonmar):
Some more information on this:
* It appears to be a generational GC effect, in the sense that running
the program with `+RTS -G1` eliminates the difference between the
versions. Apparently when using generational GC, a thunk has been
promoted into the old generation, subsequently causing a lot of data to be
promoted, despite the fact that it would all be unreachable if we had done
a major GC.
* what is strange is that increasing the nursery size doesn't fix the
problem. So apparently this is not just one thunk, but a large supply of
long-lived thunks. Perhaps the program is allocating a lot of long-lived
thunks at the beginning, and then evaluating them sequentially. So it
doesn't matter when we do young-generation collection, we will always
promote floating garbage.
Here's a snippet of `+RTS -S` showing the high promotion rate from the
young generation, followed by an old-generation collection reducing the
heap size back to around 300k:
{{{
524208 272 322584 0.00 0.00 2.01 4.81 0 0 (Gen:
0)
524256 288 322600 0.00 0.00 2.01 4.81 0 0 (Gen:
0)
524256 313528 635832 0.00 0.00 2.01 4.81 0 0 (Gen:
0)
524248 335488 970432 0.00 0.00 2.01 4.81 0 0 (Gen:
0)
524208 334688 1304816 0.00 0.00 2.01 4.81 0 0 (Gen:
0)
524248 293400 322152 0.00 0.00 2.01 4.81 0 0 (Gen:
1)
524288 296 322152 0.00 0.00 2.01 4.81 0 0 (Gen:
0)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4005#comment:8>
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
