Realtime capabilities?

[Tim Peters]

[Aahz Maruch]
> In other words, if the original poster is doing more than a tiny amount
> of I/O, standard Python/OS threads will probably beat Erlang processes
> for fairness,

I don't know how Erlang deals with C-style I/O, so can't guess.

> but if an application is almost completely compute-bound,
> Erlang will probably beat even Stackless Python.

Why?  Scheduling fairness has nothing directly to do with speed, it has to
do with whether a process ready to run is assured to get a chance to run
"soon".  A process that needs to deliver a result within a given time delta
needs to know (at least) that it can't be swapped out for longer than that
time delta.  The speed of each process on its own is at best a second-order
effect on that, compared to the granularity and fairness of the time-slicing
policy, and especially when running thousands of processes (which Erlang is
designed for).  I *expect* Erlang switches context more frequently than
Stackless, so all else being equal (which I'm sure it's not), it would be
slower overall (due to higher switching overhead, simply because switching
more often) if so.  Real-time has to do with getting specific pieces of work
done by specific times, not primarily with maximizing the amount of work
done per unit time (if the latter is your goal-- "peak speed" --best to stay
away from context switching entirely).