Bernd Brassel wrote:
There is another point that makes me wonder now. If the update frame for
the recursive call is the problem then my solution with foreign C
functions would produce a bad stack also. But this is not the case.
The code looks now like this:
sim [] = True
sim (_:xs) = yags (sim xs)
ref = cinitialize
yags x = replace (C_Ref ref) x ()
And it is running within 0.15M of stack.
Did your explanation also account for this phenomenon?
Sorry to take that much time off you with this!
Bernd
The stack of update frames is not in itself a problem, because stack
squeezing removes them leaving you with O(1) stack again. The problem with
unsafePerformIO was that the duplication-protection was interfering with
stack squeezing.
Regarding sharing analysis, we did used to have an update analyser in GHC,
but it was expensive to run and rarely gave worthwhile benefits, so
eventually we dropped it. Perhaps there are some trivial examples of
unshared thunks that we could spot, though.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
