Erlang (BEAM) emulator version 5.6.5 [smp:2] [async-threads:0]

consulting .erlang in "C:/Program Files/erl5.6.5/bin"
c:/Erlang/code
Now in:"c:/Erlang/code"
Eshell V5.6.5  (abort with ^G)
1> c(ring_benchmark, {d, trace}).
{ok,ring_benchmark}
        

2> ring_benchmark:start(3,3).
Creating a ring of 3 processes.

First, the start/2 function resets two system timers to measure CPU time and elapse time.

The message to be passed around the ring is then bound to the variable Blah.

Then a new process instance of the newLink/3 function is spawned. The parameters it passes are the number of processes yet to be created, a reference to the previous link in the chain and a reference to the start link in the chain. Since this is the first link to be created, the value of the previous link and the starting link are the same.

The start/2 process then sits and waits for a message to arrive. The only message it will respond to is one that matches the pattern {connect, NextLink}. In otherwords, the message must start with the atom connect followed by a single value. Since the variable NextLink is unbound at this point in time, it doesn't actually matter at what the second value is. Whatever value is received will therefore be bound to the variable NextLink.

When this message is received, the process creation phase of the program has completed. So the current CPU and elapse timer values are stored and the message round phase of the program begins.

The message round phase is started by sending the next link in the chain the message {M, Blah} - where the variable M is bound to the start parameter defining the number of laps, and the variable Blah is bound to the message value. Function passMsgOn/1 will respond to this message.

The lapCounter/1 function is then called with the process id of the next link in the chain. This function receives a message at the end of each lap, and is responsible for invoking the next lap. It continues to do this until the lap counter reaches 1, at which point all the laps have been completed and the program terminates.

The final step is to output the elapse and CPU time values for the message round phase of the program.

2> ring_benchmark:start(3,3).
Creating a ring of 3 processes.
<0.29.0> is link 3
<0.36.0> is link 2
<0.37.0> is the last link in the chain.

<0.37.0> is waiting to send next message to <0.29.0>
<0.36.0> received connect message from <0.37.0>
<0.36.0> is waiting to send next message to <0.37.0>
<0.29.0> received connect message from <0.36.0>
All links in the chain now form a ring.

CPU Time (process creation) = 0 ms
Elapse time (process creation) = 0 ms

When the newLink/3 function is first called, the value of parameter N will be greater than 1, therefore the version of this function seen below will be called.

When the newLink/3 function is finally called with parameter N set to 1, it means this is the last link in the chain. At this point we start a message propagating backwards through the links in the chain. When this message arrives back at the first link (see function start/2, this is the trigger that starts the message round pahse of the program.

The chain is wrapped around into a loop by the fact that function passMsgOn/1 connects back to the id of the start/2 process.

As long as parameter N has some value other than 1, this version of function newLink/3 will be invoked.

newLink/3 iteratively spawns a separate instance of itself using a decremented link counter value.

Then, it sits and waits for a message to arrive. As with function start/2, the only message newLink/3 will respond to is one that matches the pattern {connect, NextLink}. However, the value of NextLink has already been bound by the previous call to spawn/3. Therefore, the only message this process will respond to is one containing the atom connect from precisely the process that is next in the chain. When the connect message is received, it is propagated back to the previous link in the chain.

Finally, function passMsgOn/1 is called. This is the process that performs the actually message passing during the message round phase of the program.

Function passMsgOn/1 is a simple function that simply listens for a message... any message!

Rather that explicitly looking for an atom followed by a value (as newLink/3 does), it simply takes whatever it receives as a single tuple and passes it unparsed to the next link in the chain. Then it calls itself and waits for the next message.

Message propagation continues like this until we get to the instance of passMsgOn/1 that was created by newLink(1, PrevLink, Main). At this point, the instance of lapCounter/1 invoked by start/2 responds, and we know that we have reached the end of a lap.

All other links in the chain pass messages to each other using function passMsgOn/1. But, in order to count the number of laps we've done, we need a different function to do that. Function lapCounter/1 is invoked by function start/2 and only responds to the message sent from the last link in the chain.

Here, the lap counter is decremented, another lap of the circuit is invoked and lapCounter/1 calls itself in order to respond to the message that will be received once the current lap finishes.

This sequence of processing keeps happening until the lap counter gets down to 1. At this point we know we've just finished the last lap, so processing can terminate and control passes back to function start/2.

Starting message round with message "BOO!"
Sending message "BOO!" from <0.29.0> to <0.36.0>
<0.36.0> received message {3,"BOO!"}, passing it on to <0.37.0>
<0.36.0> is waiting to send next message to <0.37.0>
<0.37.0> received message {3,"BOO!"}, passing it on to <0.29.0>
<0.37.0> is waiting to send next message to <0.29.0>
Passing Go, 2 more laps to go
<0.36.0> received message {2,"BOO!"}, passing it on to <0.37.0>
<0.36.0> is waiting to send next message to <0.37.0>
<0.37.0> received message {2,"BOO!"}, passing it on to <0.29.0>
<0.37.0> is waiting to send next message to <0.29.0>
Passing Go, 1 more lap to go
<0.36.0> received message {1,"BOO!"}, passing it on to <0.37.0>
<0.36.0> is waiting to send next message to <0.37.0>
<0.37.0> received message {1,"BOO!"}, passing it on to <0.29.0>
<0.37.0> is waiting to send next message to <0.29.0>
Message round complete

CPU Time (sending message) = 0 ms
Elapse Time (sending message) = 0 ms

CPU Time (total) = 0 ms
Elapse Time (total) = 0 ms
ok

I was really surprised to see the rate at which Erlang can spawn new processes! The average rate from the above tests show that Erlang can consistently create just under 300 processes per millisecond.

Once the process ring had been created, the second part of the test was to send a small message for a certain number of laps around the ring. This is where the CPU time really starts to be consumed.

As can be seen from the table above, the runtime stays very linear as both the number of message laps and the size of the ring increases

The final test shows that the message is passed for 10,000 laps around a 499,900 process ring in just under 7000 seconds. Switching to "bucket maths" mode, this is roughly the same as passing a single message along a chain 5 billion links in length in just under 2 hours. In other words, the message was being passed at a rate of 716 links per millisecond.

Pretty impressive really!

The above graph shows that as the number of processes in the ring and the number of laps rises, the runtime remains very nearly linear.

The X axis shows the number of processes in the ring, the Z axis shows hows many times the message was passed around the ring, and the Y axis shows the overall runtime in milliseconds.

1> ring_benchmark:start(10000,100).
Creating a ring of 10000 processes.

CPU Time (process creation) = 31 ms
Elapse time (process creation) = 63 ms

Starting message round with message "BOO!"
Message round complete

CPU Time (sending message) = 1359 ms
Elapse Time (sending message) = 1360 ms

CPU Time (total) = 1390 ms
Elapse Time (total) = 1423 ms
ok
2>