#9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dolio): Apparently I am not certain. I've conferred with some people, and my example displays the same behavior on 7.6.3. The intention was to simulate the behavior of the following test: {{{ module Main (main) where import qualified Data.Vector.Algorithms.Intro as I import qualified Data.Vector.Unboxed as U main = do let a = U.fromList [0..10000000::Int] print (U.length a) let k = U.modify (\v -> I.sort v) a print (U.length k) }}} which is an order of magnitude slower on 7.8 than on 7.6 (note, if you choose to test this, you must use vector-algorithms 0.6.0.1; I have semi- fixed the issue in 0.6.0.2). Running with -ddump-simpl yields 640 lines on 7.8.{2,3}, and ~4,600 lines on 7.6.3. So clearly the difference involves some variety of inlining or specialization. The type of {{{sort}}} here is: {{{(PrimMonad m, MVector v e, Ord e) => v (PrimState m) e -> m ()}}} and the type of {{{modify}}} is: {{{Unbox a => (forall s. MVector s a -> ST s ()) -> Vector a -> Vector a}}} So my aim was to replicate the kind of specialization as the sorting example. But clearly I've failed. However, if your description is correct, I have no idea why 7.6.3 was inlining/specializing the sort function in this example. It has the same open s, necessarily, due to the higher rank type of {{{modify}}}. Can you think of anything that might be the difference? ---- In another direction, it might be interesting to do the kind of specialization you outline above. The {{{PrimMonad}}} dictionary is completely determined even though the function is polymorphic in {{{s}}}, and specializing the function is key to performance, even if some parts are still polymorphic (as they necessarily are for {{{ST}}}). Failing to unbox all the {{{Int}}} operations and so on merely because we are still abstracting over {{{s}}} makes {{{PrimMonad}}} a rather unusable abstraction. I actually tried (earlier) adding a pragma: {{{ {-# SPECIALIZE sort :: MVector s Int -> ST s () #-} }}} but GHC complained about it. So it seems that it can't even handle what that sort of thing generates, ignoring the fact that it can't generate it itself. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9320#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler