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

[GHC]

#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