[GHC] #15103: Speed optimizations for elimCommonBlocks
GHC
ghc-devs at haskell.org
Mon Jun 4 16:25:16 UTC 2018
#15103: Speed optimizations for elimCommonBlocks
-------------------------------------+-------------------------------------
Reporter: AndreasK | Owner: AndreasK
Type: task | Status: patch
Priority: normal | Milestone: 8.6.1
Component: Compiler | Version: 8.5
Resolution: | Keywords: CodeGen
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D4597
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by AndreasK):
Replying to [comment:9 simonpj]:
> Terrific. Would you like to do a nofib run before-and-after, and dump
the `nofib-analyse` summary in here? It's very helpful just to record the
benefits of particular changes, for posterity.
{{{
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
maillist 0.0% 0.0% 0.024 0.025 +6.5%
mate -0.0% 0.0% +4.6% +4.6% 0.0%
cryptarithm1 0.0% 0.0% -1.7% -1.8% 0.0%
--------------------------------------------------------------------------------
Min -0.0% -0.0% -1.7% -1.8% 0.0%
Max +0.0% +0.1% +4.6% +4.6% +6.5%
Geometric Mean -0.0% +0.0% +0.3% +0.3% +0.1%
Compile Times
-------------------------------------------------------------------------------
Program logNoOpt logWithOpt
-------------------------------------------------------------------------------
-1 s.d. ----- -1.9%
+1 s.d. ----- +1.5%
Average ----- -0.2%
Compile Allocations
-------------------------------------------------------------------------------
Program logNoOpt logWithOpt
-------------------------------------------------------------------------------
-1 s.d. ----- -0.3%
+1 s.d. ----- -0.1%
Average ----- -0.2%
}}}
These runtime results took me by surprise!
It turns out code layout depends on uniques. And the final uniques change
with this patch.
So we get slightly different codelayout.
I verified that the code for mate is otherwise the same.
Using different starting or increment values for uniques also lead to
different results with up to the same performance spread.
So I don't think the runtime change is representative.
Compiler performance impact is as expected.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15103#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list