[erlang-questions] Erlang vs. Stackless Python

[ok]

>> Remember Joe Armstrong's call in his book:
>> "    Write a ring benchmark. Create N processes in a ring. Send a  
>> message
>>     round the ring M times so that a total of N*M messages get sent.
>>     Time how long this takes [..]
>>
>>     Write a similar program in some other programming language you  
>> are
>>     familiar with. Compare the results. Write a blog, and publish the
>>     results on the internet!
>> "

It's not worth a blog, but here's a Smalltalk version, using Squeak.

SharedQueue>>
ring: numberOfProcesses benchmark: numberOfRounds
   "Create a ring of processes and send a message around that ring  
repeatedly.
    Report how long it takes.
    Each process has access to two SharedQueues 'in' and 'out'
    and a Semaphore 'done'."
   |queues done t0 t1|

   t0 := Time primMillisecondClock.
   queues := (1 to: numberOfProcesses) collect: [:i | SharedQueue  
new: 1].
   done := Semaphore new.
   1 to: numberOfProcesses do: [:i | |in out|
     in := queues at: i.
     out := queues at: (i \\ numberOfProcesses) + 1.
     [ 1 to: numberOfRounds do: [:j | |message|
         message := in next.
         out nextPut: message - 1].
         i = numberOfProcesses ifTrue: [done signal]
     ] fixTemps fork].
   "Fire off the first message."
   (queues at: 1) nextPut: numberOfProcesses * numberOfRounds.
   done wait.
   t1 := Time primMillisecondClock.
   ^t1 - t0

Performance scales fairly linearly with the number of rounds.
With the number of processes, it is not so good:
    10 ->     152 msec
   100 ->    1557 msec
  1000 ->   29480 msec
10000 ->  408182 msec
(All on a 1GHz G4 PowerMac).  These numbers are tolerably well
fitted by a curve time ~ c * nprocs**1.16.  There seems to be more
garbage collection going on than I expected (I love how easy it is
to take a quick profile of any running MacOS process).

SharedQueues are roughly equivalent to Erlang mailboxes, but they
are a heavyweight for this benchmark.  Creating a 'Mailbox' class
that can hold only a single message and using that instead gave

    10 ->     25
   100 ->    267
  1000 ->  12788
10000 -> 161545

This is tolerably well fitted by time ~ c * nprocs**1.31, making the
point that "is faster than" is not the same as "scales better than".

The really important point here is that I *would* considering using
Squeak for a program with low hundreds of processes, but not for a
program with thousands.