Malcolm Wallace wrote:
Jules Bean <[EMAIL PROTECTED]> wrote:
GHC's scheduler lacks any hard timeliness guarantees.
This is probably not a fundamental problem with haskell. It's a
problem with the compiler/RTS which we happen to be using.
Actually, I would say it is much worse than that. It is not merely a
question of implementation. We do not have _any_ predictable theory of
resource usage (time, memory) for a lazy language. There is no analysis
(yet) which can look at an arbitrary piece of Haskell code and tell you
how long it will take to execute, or how much heap/stack it will eat.
What is more, it is very hard to do that in a modular way. The
execution time of lazy code is entirely dependent on its usage/demand
context. So you can't just apply WCET to single functions, then combine
the results.
That's true but I'm not sure you need to solve that (hard, interesting)
problem just to get *some* kind of timeliness guarantees.
For example the guarantee that a thread is woken up within 10us of the
MVar it was sleeping on being filled doesn't require you to solve the
whole problem. It requires you to be able to bound GC time, or preempt
the GC, but that's feasible isn't it?
Then there is the possibility of a strict DSL (probably but not
necessarily a Monad) within haskell which has strong timeliness guarantees.
Jules
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
