Re: [GHC] #1600: Optimisation: CPR the results of IO

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Here is a nother reason why nested CPR is not very successful: The requirement of definite termination is not easy to meet. One would think that the extended Euclidean algorithm is a good candidate for nested CPR: {{{ #!haskell extendedEu2 :: Int -> Int -> (Int, Int) extendedEu2 a 0 = (1, 0) extendedEu2 a b = (t, s - q * t) where (q, r) = quotRem a b (s, t) = extendedEu b r }}} but it is not: With a return type of `dm(d,dm(d))` we cannot do more than unbox the tuple. Now with a few iterations between the code and the core, one can find a strictness annotation that makes it work: With {{{ #!haskell extendedEu :: Int -> Int -> (Int, Int) extendedEu a 0 = (1, 0) extendedEu a b = let b' = s - q * t in b' `seq` (t, b') where (q, r) = quotRem a b (s, t) = extendedEu b r }}} we infer `dm(tm(d),tm(d))` and the worker gets type `GHC.Types.Int -> GHC.Prim.Int# -> (# GHC.Prim.Int#, GHC.Prim.Int# #)`. So likely nested CPR might help those who are careful to use strictness annotation and use strict data types (which some people are doing almost exclusively), but not a lot with the usual lazy programming. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1600#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC