#8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:7 simonpj]:
Great. Now, what's happening in `symalg` and `kahan` (+4.7 and 6.7% resp)?
Thunks are happening... (see below)
What is puzzling to me is that I don't think `smartJ#` does ''any'' allocation (apart from its result) so I don't see why allocation should ever increase.
...because I missed the fact that `(# smartJ# ... , smartJ# ... #)` creates a thunk (there was even a source code comment about that pitfall in `quotRemInteger#`) However, I replaced all `smartJ#`-in-`(#,#)` occurences (incl. `decodeDouble`) by `let !x = smartJ# ... in (# x, ... #)` constructs, and the results look better now: {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ... gamteb +0.1% -19.0% 0.03 0.03 +0.0% ... kahan +0.2% -1.2% 0.17 0.17 +0.0% ... mandel +0.1% -7.7% 0.05 0.05 +0.0% ... power +0.1% -40.8% -32.5% -32.5% +0.0% ... symalg +0.2% -0.5% 0.01 0.01 +0.0% ... -------------------------------------------------------------------------------- Min +0.0% -40.8% -32.5% -32.5% -5.1% Max +0.2% +0.1% +2.0% +2.0% +0.0% Geometric Mean +0.1% -1.0% -2.5% -2.5% -0.1% }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8638#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler