Home » forums » LtU Forum

What is an Actor?

There seems to be some confusion about the Actor model. In fact, I may have inadvertently contributed!

So (tongue in cheek), I wrote the following in Common sense for inconsistency robust information integration using Direct Logic(TM) and the Actor Model:

Question: Isn't procedure calling faster than message passing?
Answer: No, they are equivalent.

Question: Doesn't every Actor have a X (where X is thread, mailbox, queue, etc.)?
Answer: Is X an Actor?

Question: What is an Actor?
Answer: Anything that obeys the axioms!

By Hewitt at 2011-02-20 13:44 | LtU Forum | previous forum topic | next forum topic | other blogs | 6124 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Performance

Isn't procedure calling faster than message passing? Answer: No, they are equivalent.

I don't believe so. This really must be answered under the assumptions of (a) optimizations being applied, (b) modularity (optimizer only has access to 'chunks' of the program), (c) no such thing as a 'sufficiently smart' compiler (optimizations are expressed as pattern-recognition and transform rules, and must justifiably not violate functional behavior; no hand-waving allowed).

Under those conditions, message passing and procedure calls do not seem to have equivalent performance (efficiency, utilization, scalability, latency/real-time) characteristics. Certainly, we should assume they are distinct unless you have proven a simple transform on the optimizations that allow optimizations on one to apply to the other (e.g. as achieved with SSA and CPS).

A major difference is that procedure calls are 'wait on send', and developers must code with this expectation. Concurrency in a procedural system is achieved by creating explicit 'threads'. The 'wait on send' ensures at least one nice performance characteristic that actors do not have: the amount of memory involved in waiting operations is bounded by the number of threads (e.g. similar to CSP or bounded-buffer concurrency).

In general, an implementation of a stateful actor will involve no-wait sends and intermediate queues. It seems difficult to "inline" message passing the way one might "inline" procedure calls.

Could you point me to a paper that justifies the two paradigms to be performance equivalent?

By dmbarbour at Sun, 2011-02-20 17:35 | login or register to post comments

Producedure calling is *not* faster than message passing

Fortunately, considerable progress has been made in implementing Actors since they were invented in 1972. See
ActorScript(TM) extension of C sharp (TM), Java(TM), and Objective C(TM)

By Hewitt at Sun, 2011-02-20 19:22 | login or register to post comments

Okay, I'll grant that

Okay, I'll grant that throwing half a dozen carefully selected variations of message-sends at the problem, as documented in that paper, could potentially solve your performance issues. It is the complex instruction set approach to performance: take common design patterns and specialize them into the language. All it costs is simplicity.

By dmbarbour at Sun, 2011-02-20 20:41 | login or register to post comments

ActorScript is a very simple programming language

ActorScript is a very simple programming language with few primitive constructs.

By Hewitt at Mon, 2011-02-21 02:34 | login or register to post comments