#9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:67 simonpj]:
I think there is an option to force GC to happen more frequently, but I can't see it in the manual. Simon Marlow might know.
In any case, getting an accurate residency profile, by using one generation and frequent gcs, is a Good Thing. when you do that, to the residency profiles of the two versions differ? I didn't understand the
There's `-i`, but that only seems to work in conjunction with `-h`: {{{ -h Heap residency profile (output file <program>.hp) -i<sec> Time between heap profile samples (seconds, default: 0.1) }}} Also, even with `-i0.0001s -h` the sampled maximum residency doesn't come close to the 192/196MB above. figures you show above. Sorry for causing you trouble to understand what I wrote, I really have to figure out better ways to present my results. So, yeah, using one generation and 'just the right GC frequency' is basically what I did in comment:65. I defined 'just the right frequency' by choosing the `-A$iM` setting (which determines the points at which GC happens) for which maximum residency is at its maximum for each of the two candidates. For the `default`, which looks at closure growth, this setting was `-A56M` with a maximum residency of 192MB. For the version where we also lift said `go` function (which we normally would not), maximum residency was at 196MB for `-A76M`. That's worse than the baseline, as I initially expected. The fuzz above was all for nothing, because I once again merely measured the RTS parameterisation. In comment:66 I remembered that despite better runtime measurements with the baseline, counted instructions regressed when 'turning off' GC with `-A128M`. That's strange, but I'll probably refer to runtime measurements in the paper now and ignore counted instructions completely. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9476#comment:68 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler