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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sean Hinde-2
Hi,

> 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
to do this:

busy() ->
  busy().

The time to complete the benchmark came down to:

real    0m34.032s
user    0m22.190s
sys     0m11.640s

from:

real    0m45.845s
user    0m32.910s
sys     0m11.790s

while also completing some huge amount of additional work..

We have a number of machines working as pure mnesia servers running small
transactions - pretty much exactly what this benchmark is simulating. I will
do some more testing but it looks like in this sort of OLTP type
applications where there is little else going on in the emulator except -
read message from tcp/ip, do small work, wait for next message there might
be a useful boost in throughput available.

More thoughts anyone?

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



Reply | Threaded
Open this post in threaded view
|

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

Ulf Wiger-4

This was interesting.

Erlang strikes me as more and more human.  ;)
I seem to function in the same way: when I have lots to do, I
become more efficient; when I have little to do, I become very
inefficient.

Seriously, Erlang *has been* highly optimized for the very type
of systems where there are lots of things going on at once. This
reflects on the I/O, for example, where Erlang tries to handle up
to hundreds of active I/O ports fairly, rather than handling only
one extremely well.

Perhaps for example the ETOS implementation could focus more
squarely on efficiently running applications with much less
concurrency? It seems to be very good at that already.

/Uffe

On Thu, 14 Jun 2001, Sean Hinde wrote:

>Hi,
>
>> 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
>to do this:
>
>busy() ->
>  busy().
>
>The time to complete the benchmark came down to:
>
>real    0m34.032s
>user    0m22.190s
>sys     0m11.640s
>
>from:
>
>real    0m45.845s
>user    0m32.910s
>sys     0m11.790s
>
>while also completing some huge amount of additional work..
>
>We have a number of machines working as pure mnesia servers running small
>transactions - pretty much exactly what this benchmark is simulating. I will
>do some more testing but it looks like in this sort of OLTP type
>applications where there is little else going on in the emulator except -
>read message from tcp/ip, do small work, wait for next message there might
>be a useful boost in throughput available.
>
>More thoughts anyone?
>
>- 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.
>
>

--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB