[GHC] #11707: Don't desugar large lists with build
GHC
ghc-devs at haskell.org
Tue Mar 15 12:52:08 UTC 2016
#11707: Don't desugar large lists with build
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by bgamari):
I've pushed a simple approach to avoid `build`-based list desugaring for
large lists to Phab:D2007. Here we simply threshold on the list length. I
have a few concerns about this approach,
* This threshold introduces a "performance cliff", where users will
suddenly see drastically different performance characteristics as their
literal lists grow.
* There isn't really a good way to choose this size. Ideally we'd want a
smaller threshold with larger consumers and vice-versa, but we have no way
of knowing what will be consuming our list in the desugaring.
From a runtime performance perspective, applying `build` more liberally
should rarely hurt (it can only expose further optimization opportunities;
if no fusion is possible it will eventually get rule-rewritten back to a
list)
Consequently, the threshold we introduce here is a bit concerning since
we are limiting contexts in which we'll use `build`, potentially hiding
optimizations.
Regardless, `nofib` shows no change in allocations after this change, so
it at very least doesn't hurt any of the cases there. Moreover, it shows a
30% reduction in compiler allocations in `T9961` (from 745044392 to
745044392 bytes).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11707#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list