Hi.
Simon Peyton-Jones wrote:
| I've definitely run into the odd other case where point-freeing
| a bit of code messes with the complexity.
That should not happen -- except for the state-hack. Which is this:
Consider
f1 :: Char -> IO ()
f1 = \c. let i = ord c in \s. print i s
Here s::State World. Is this equivalent to
f2 = \c.\s. print (ord c) s
The latter is very much more efficient than 'f1', because it doesn't build an
intermediate lambda. This matters a lot in I/O-intensive programs. But if
'f' is called thus:
forever (f 'w')
then (ord 'w') is computed once for each call of f2, but is shared among all
calls to f1. And that can make a big difference too.
Thanks for the explanation. State World here really means the IO and ST
monad, not the State monad, right?
Compiling with -fno-state-hack actually does actually lead to both
versions (the point-free and explicit) being equally fast (14.4s instead
of 15.2s resp. 14.0s). Though I am not sure why. Running in profiled
mode makes all difference vanish.
I tested this on an Intel(R) Pentium(R) 4 CPU 3.00GHz and got the
reported speed difference there. Using instead an AMD Athlon(tm) 64
Processor 3800+ I got no difference even without using -fno-state-hack.
I have no idea whether this is playing a role in the example you are discussing
-- my guess is not, and there may be another performance bug lurking. So
eliciting a small demo would be great.
I am sorry, I completely failed to do that. The parser builds up a data
structure from several data types using memoization. Any significant
simplification of the code base reduced the performance gap until it
quickly disappeared.
Alexander
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
