#8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): What is the status of this ticket? I've tried the patch suggested in comment:34, but my results of nofib were quite different, with some clear regressions (below I've removed anything where the difference was <2%) {{{ NoFib Results -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- CSD -0.4% 0.0% +7.4% +7.4% 0.0% S -0.5% 0.0% +3.2% +3.3% 0.0% VS -0.5% 0.0% -4.4% -4.4% 0.0% VSM -0.5% 0.0% +8.7% +8.7% 0.0% bspt -0.5% 0.0% 0.003 0.003 +50.0% constraints -0.4% 0.0% +2.5% +2.6% 0.0% cryptarithm1 -0.4% 0.0% +6.0% +6.0% 0.0% exact-reals -1.2% 0.0% -2.7% -2.7% 0.0% fannkuch-redux -0.4% 0.0% -2.5% -2.5% 0.0% fasta -0.4% 0.0% +7.7% +7.6% 0.0% k-nucleotide -0.8% +0.0% +17.9% +18.0% 0.0% lambda -0.4% 0.0% -2.2% -2.1% 0.0% linear -1.2% 0.0% -5.9% -5.9% 0.0% mate -0.4% 0.0% -2.2% -2.2% 0.0% n-body -0.9% 0.0% +3.2% +3.2% 0.0% -------------------------------------------------------------------------------- Min -1.4% -0.2% -5.9% -5.9% 0.0% Max -0.2% +0.0% +17.9% +18.0% +50.0% Geometric Mean -0.7% -0.0% +1.7% +1.6% +0.4% }}} I've tried to have a look into `k-nucleotide`, which slowed down the most. My current understanding is that there's a tight loop within a single function that goes like this: - A: some computation, eventually goes to B - B: case on `andI# variable 127#` (one alternative is the slow path that allocates, the other is fast that doesn't) - C: alternative that does a bit of computation (but no allocation) and jumps back A Now with the change we get a heap check in front of the case, which will now be executed on every iteration and slow everything down. NOTE: I don't have much experience with investigations like this, so the whole analysis might be quite wrong. ;) Please let me know if something seems off. I'll attach the dump of STG/cmm/asm from both versions of `k-nucleotide` (with and without the patch). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8326#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler