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

Sean Hinde Sean.Hinde@REDACTED
Fri Jun 15 09:06:25 CEST 2001


> > What would happen if you e.g. change INPUT_REDUCTIONS in erl_vm.h
> > from (2* CONTEXT_REDS) to CONTEXT_REDS, doubling the I/O poll
> > frequency?  (CONTEXT_REDS is set to 1000)
> > 
> > If basically all that happens in the erlang vm is that some 
> > process is waiting for I/O, ports may not be polled with any
> > predictably high frequency (then again, this is only guessing
> > wildly. Perhaps it effectively gives the ports even higher
> > priority...)
> 
> I didn't try this but did get the benchmark to spawn an 
> additional process

OK, here is my take on this:

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.

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.

Maybe schedule() might be modified so that in addition to returning after
INPUT_REDUCTIONS it keeps track of activity in each pass through all
processes and returns if there has been no activity detected for a whole
pass.

As far as I can make out this would not slow things down significantly in a
busy system but would improve i/o responsiveness under normal load quite
considerably.

Please, someone who really understands these things, help me out here!

Thanks,
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