#5888: Performance regression in 7.4.1 compared to 6.12.3 ---------------------------------+------------------------------------------ Reporter: nickie | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar):
* priority: normal => high * difficulty: => Unknown * milestone: => 7.4.2 Comment: This is more fallout from the change to the representation of `Integer` literals in 7.4.1. The important bit of code looks like this: {{{ shuffle h x y z n = if n `mod` 3 == 0 then ntak shuffle h (n+3) (x-1) y z else if n `mod` 3 == 1 then ntak shuffle h (n+2) (y-1) z x else ntak shuffle h (n+1) (z-1) x y }}} In GHC 7.0.3, {{{n `mod` 3 == 1}}} was compiled to {{{ case ww2_a1es of _ { GHC.Integer.Type.S# i_dIx -> case i_dIx of _ { __DEFAULT -> $w$j3_s1gG; 1 -> $w$j2_s1gI }; GHC.Integer.Type.J# s_dIK d_dIL -> case {__pkg_ccall_GC integer-gmp integer_cmm_cmpIntegerIntzh ... }}} Note how equality has been inlined, and the box around the constant 1 has been optimised away. In 7.4.1 we get {{{ case GHC.Integer.Type.eqInteger ww5_X11T lvl1_r2i7 of _ { GHC.Types.False -> poly_ntak_r2ia @ GHC.Integer.Type.Integer shuffle_r2ic h_akF (GHC.Integer.Type.plusInteger n_akJ lvl1_r2i7) (GHC.Integer.Type.minusInteger z_akI lvl1_r2i7) x_akG y_akH; GHC.Types.True -> }}} equality has not been inlined, and the constant 1 is a top-level `S#` (`lvl1_r2i7`). We could fix this by defining something like {{{ eqIntegerInt# :: Integer -> Int# -> Bool }}} and having builtin RULES for equality where one argument is a constant, but then the tricky bit there is how to get hold of an `Id` for `eqIntegerInt#`. Ideas anyone? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5888#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs