[zeromq-dev] Actor Model

[Bennie Kloosteman]

>1. Each thread has one socket. You hash the unique name of the actor and assign it accordingly to a thread.
advantages: no contention.
disadvantages: it cannot work if actors have different processing needs.

You rely on the randomization of the hash function to balance the work.

this is pretty useful for a graph processing system(millions++ of actors)

BK> Yes this relies on all actors being the same type , which is pretty hard.

2.You have a central broker which implements a locking mechanism.
Threads ask for work, they receive the actors name plus the message
that needs to be processed.
All the actors data are shared by all the threads.

advantage:load balancing works all the time
disadvantage: latency because each thread has to request for work.


>From an algorithmic point of view, how is a disruptor pattern faster
than a queue when we want to implement an actor model?

BK> The basic idea with disruptor is the thread is  working all the
time with no context switches / TLB or Cache flushes , no  contention
and no  IO blocking or locking ...if you want IO you send an async
message to an IO process then process the next message . If the IO has
a result its a new message. Because there is no thread syncronization
etc you get a big boost in cache hits  so you end up easily processing
100K messages per second   , and the LMAX people pushed it to 6M
transactions per second on standard PC HW with Java on 1 thread !  .
Martin Fowler has a good paper on it.   BTW They tried actor first
but found this model better . Latency is quite low due to the huge
processing capacity.  Also note even though there are call backs its
all single threaded so easy to code ..

I do think you can do better than Disruptor with Actor like services
eg  you need to have actors of certain types processed by a service
with a message pump ( which could be load balanced )  , similar /
related work grouped into the same actor and and all inter actor
communication point to point - No service bus / router with contention
etc.  With point to point queues you can do lock-less reading and
writing . Obviously managing these queues and wiring them up is not
trivial .

Lastly you really want actors that are chatty talking via shared
memory or grouped in the same domain by the time you go to an IP stack
your performance will be attract much higher latency  and a throughput
penalty  .

I would be interested to know how akka or erlang solve the above
problem of distributing actors to threads.

BK> Erlang is good but its more from the point of safety and ease of
coding than performance.  If you don't need extreme performance you
should use it !.