Interesting benchmark performance (was RE: Pitiful benchmark perf ormance)
Mon Jun 18 15:28:48 CEST 2001
Sean Hinde <> wrote:
>The main emulator loop appears to be the code at the very end of sys.c. This
>calls schedule() and waits for it to return before any i/o is checked.
>schedule() in erl_process.c will *only* return when INPUT_REDUCTIONS have
>all been used up.
Of course not, that would be totally broken - when no processes are
runnable, it will return immediately:
case 0: /* No process at all */
This will happen when all processes are sitting in 'receive', which is
in some sense the "normal" case. Note also that this will cause the
subsequent poll()/select() to be *blocking* (until the next scheduled
timeout, basically) instead of polling.
>As far as I can make out the only reason the echo/server benchmark doesn't
>deadlock is that there is enough going on in the background in an otherwise
>quiescent system to eventually use up the 2000 function calls required to
Unless your code is doing it, there is basically nothing "going on in
the background". I.e. if there is nothing to do, the whole runtime will
sit in a blocking poll()/select() call (you can easily verify this by
using 'strace' or equivalent on the beam process), which should provide
optimal responsiveness to I/O.
So, while the improved benchmark performance with a background busy loop
is "interesting", it seems to me that the explanations so far are on the
wrong track - unfortunately I don't have a right track to suggest, but
by all means keep looking.:-) I'm pretty sure it isn't due to any
intentional optimization for a "busy system", though.
More information about the erlang-questions