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

Sean Hinde Sean.Hinde@REDACTED
Mon Jun 18 15:50:07 CEST 2001


> 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;

Yes, I just didn't see it - I was looking for something which increased the
reduction counter by a certain minimum each time and missed the obvious ;)

> 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.

Yes, I caught this - again is exactly the sort of thing one would expect in
a nicely designed system.

> 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.

Totally agree.

> 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.

I have tried the benchmark on R6B (sending the data as a list rather than a
binary but otherwise the same) and get the following result:

real    0m28.929s
user    0m15.940s
sys     0m11.820s

This is much better than the best I managed with R7B. Maybe it is down to
something in the new inet driver or driver framework.

I'll pass this on to the OTP guys to see what they make of it.

- Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.




More information about the erlang-questions mailing list