David Menendez wrote: > On Sun, Nov 1, 2009 at 7:12 AM, Heinrich Apfelmus > <apfel...@quantentunnel.de> wrote: >> Even then, the results are mixed. The Church-encoding shines in GHCi as >> it should, but loses its advantage when the code is being compiled. I >> guess we have to look at the core if we want to know what exactly is >> going on. > > What optimization level did you compile with?
No optimization. From the bottom of the paste http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10686#a11420 Results: In ghci, the church encodings clearly win. *Main> force testTree () (1.63 secs, 13948748 bytes) *Main> test findMaybe 0 100000 (1.70 secs, 15026356 bytes) *Main> test findChurch 0 100000 (0.72 secs, 15553668 bytes) *Main> test findChurch' 0 100000 (0.71 secs, 13456600 bytes) But when compiling, the algebraic data types wins. ghc --make Test.hs data Maybe mean: 90.08407 ms, lb 86.36974 ms, ub 94.13646 ms Church encoding mean: 152.0198 ms, lb 144.0916 ms, ub 161.0063 ms Church encoding optimised mean: 114.0715 ms, lb 107.3498 ms, ub 122.6881 ms I am a bit surprised. Then again, I probably shouldn't be surprised that the cost model is not like I imagine it to be. Regards, apfelmus -- http://apfelmus.nfshost.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
