[GHC] #7850: Strangely high memory usage on optimized Ackermann function

[GHC]

#7850: Strangely high memory usage on optimized Ackermann function
---------------------------------+------------------------------------------
    Reporter:  dolio             |       Owner:                         
        Type:  bug               |      Status:  new                    
    Priority:  normal            |   Milestone:                         
   Component:  Compiler          |     Version:  7.6.2                  
    Keywords:                    |          Os:  Unknown/Multiple       
Architecture:  Unknown/Multiple  |     Failure:  Runtime performance bug
  Difficulty:  Unknown           |    Testcase:                         
   Blockedby:                    |    Blocking:                         
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by applicative):

 No one seems to be pointing out that this this program ''does'' return and
 more importantly ''gives the correct answer'' on `ghc-7.6.2`. On this
 dubious macbook air (osx 10.8, 4gb , 2.4ghz, 2 cores etc), the world does
 not end, this wiki does not freeze, my files are not threatened; it takes
 as much memory as the os is willing to give it -- ~2gb  -- and looks like
 so:
 {{{
 $ ghc -O2 ackermanbug.hs -fforce-recomp  # ghc-7.6.2  64bit
 $ time ./ackermanbug
 65533   real    1m47.372s; user 0m26.577s; sys  0m17.641s
 }}}
 The distinction between `real` and `user` is of course suggestive of
 pathology -- but not a bug in the strict sense -- and is indeed handsomely
 repaired in
 {{{
 $ khc -O2 ackermanbug.hs -fforce-recomp  # ghc HEAD
 $ time ./ackermanbug
  65533     real    0m24.081; user  0m23.920s; sys  0m0.133s
 }}}
 If I add the news that "ack n 1 = n + 2", ghc does fine in either version;
 and of course it clunks along never to return with `ack 4 2`.  **With the
 same emendation http://hpaste.org/86212 the vaunted `gcc` gives a
 segmentation fault instantly**.

 What I wonder is whether gcc's segfault is a 'bug' we should be
 hysterically reporting on the gcc trak, or if the `gcc` devs just put in
 an ack-detector because they got tired of people whining about such
 things, preferring to focus on what matters.

 What is more interesting is that e.g. `ocamlopt` takes 5s for `ack 4 1`
 where `ghc-HEAD` takes 24s. I cannot replicate the superiority the SO guy
 found with the `gcc` . It seems about the same as `ocamlopt`.  If I add
 ''any help at all'' to the program, e.g. that ack 1 = (+2) -- ghc becomes,
 for all actually calculable arguments, just as fast as gcc.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7850#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler