[erlang-questions] Strange observation running in an SMP environment.

Jesper Louis Andersen <>
Tue Jun 12 21:36:49 CEST 2012


On Mon Jun 11 21:48:20 2012, Ronny Meeus wrote:

[Ring benchmark - showing that 2 rings is considerably slower than one]

> Can somebody explain this?

There are a couple of factors which plays a role here. First of all, 
you can use the nice percept tool to look at your code:

https://gist.github.com/2919608

run t:start(), t:analyze(), t:server(). Then point your browser to 
localhost:8989 and have fun :)

The first problem is that the concurrency of your rings are 1 both of 
them. This means you can at most keep one core busy on each ring and 
your maximum speedup is thus 2. To see this, note that one one process 
can run in the ring at a time. All others are waiting for the token to 
come to them. This is also shown in the percept graph: At the start, 
you have a very high concurrency level because you just spawned a lot 
of processes and they are now runable. Then the ring connect phase 
happens and this blocks many of them in a receive waiting for a 
{connect, ...} message. When we run around the ring, the concurrency 
level is hovering around 2 to 4. Which makes sense since we added two 
Led-processes which also needs to run from time to time.

The second problem is that your benchmark is not doing work. So what 
you are measuring is locking overhead from the Erlang VM and your 
kernel. Passing a message is VERY fast in Erlang and that is all you 
are doing. If you have 4 cores in your machine, they are stealing work 
from each other all the time and this accounts for the overhead. You 
could try playing around with `erl +sbt tnnps` as an erlang flag, but 
it may/may not give you anything here.

it is also worth trying to disable SMP entirely `erl -smp disable` 
since this avoids any kind of locking. In some cases that is faster for 
some workloads. And yours might be one.

--
Jesper Louis Andersen
  Erlang Solutions Ltd., Copenhagen, DK



More information about the erlang-questions mailing list