Interesting benchmark performance (was RE: Pitiful benchmark perf ormance)

[per@REDACTED]

Sean Hinde <Sean.Hinde@REDACTED> 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 */
            return 0;

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
>check i/o.

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.

--Per Hedeland
per@REDACTED