Comparing implementations of the actor model

Comparing implementations of

the Actor ModelJim Roepcke<[email protected]>

Concurrency Summit 2008

1

Actor models?

2

This kind?3

No, not that kind...

4

The kind in Joe Armstrong’s Erlang,

5

The kind in Joe Armstrong’s Erlang,

6

Evan Phoenix’s Rubinius,

7

Martin Odersky’s Scala,

8

and Steve Dekorte’sIo.

9

What is theActor Model?

10

It’s a trendy model for

concurrent programming

11

Massively parallel future

• The future has begun!

• We had lots of time to figure this out

• Programmers are still using threads and mutexes in “high level” code

• Bad programmer!

• ABSTRACTION FTW!

12

What’s old is new again

• Actors defined by Hewitt in 1973

• More work by his PhD students in the 80s, Clinger, Agha

• Adopted by Erlang in the late 80s for the telecom industry

• Picking up steam as concurrency becomes a hot issue again

13

Actors win because they are simple

14

Actors communicate15

Actors spawn16

Actors run in parallel17

Actors listen18

Actors avoid deadlock19

Actors perform great!20

Now: up close21

ComparingActors to Actors

• Implemented a program in Erlang, Rubinius, Scala and Io

• My experiences with each

22

OM NOM NOM!

• Implemented the “burger problem” from CSC 464 Assignment 1 in all four languages

23

supervisor

spawn!

24

Student

Cook

Student

Student

Order Line

CookCook

Burger Line

Student

StudentStudent

Burger Burger

Burger

hungry

burger!

enjoy!

ok

mmm

supervisor 25

Actors communicate26

Communication

• Asynchronous Message Passing

• Encourages no memory sharing

• Each actor has a “mailbox” which queues messages sent

• “send” mechanism to deliver a message to an actor

27

Sending messages

Erlang

pid ! message

Rubinius

actor << message

Scala

actor ! message

Io

obj @@method(args)

28

Actors and burgers29

Actors spawn30

Creating actors

• To create concurrency, actors create more actors and send them messages

• Actors are independently executing entities

31

Creating actors

Erlang

pid = spawn(fun)

Rubinius

actor = Actor.spawn ...

Scala

sa = new SomeActor()sa.start()

Io

sa := SomeActor clone

32

Erlang Actors

• Actors are called processes

• Process creation and context switching is very fast and lightweight

• Processes cannot share memory

• Typically run a tail-recursive function

33

Rubinius Actors

• Actor class comes with Rubinius VM

• Green Ruby thread per actor

• VM assigns a Mailbox per thread

• Remote Actors new, not perfect yet

• “Orders of magnitude” worse than Erlang: Rubinius developer on IRC

34

Scala Actors

• scala.actors package comes with Scala

• Hybrid execution model, actors run in their own thread or via events

• Claim massive scalability using events and thread pools

• Remote Actors supported

• act() loops to stay alive

35

Io Actors

• Io uses coroutines for concurrency

• Scheduling is FIFO, no prioritization

• One kernel thread per VM, async I/O

• @@ runs the method on a dedicated per-object coroutine for messages

• Remote actors not supported

36

Actors run in parallel37

Parallelism: Erlang

• SMP Erlang automatically puts processes on different cores/CPUs

• Messaging actors in remote VMs is seamless

• spawn(Node, fun) to spawn an actor on a different VM which may be remote

38

Parallelism: Rubinius

• One kernel thread per Rubinius VM

• Processor affinity for multi-core?

• Use VMActor to create an actor on a remote VM

• Messaging actors in remote VMs is seamless thanks to duck typing

39

Parallelism: Scala

• When using event-based actors, Scala creates multple threads to balance load across cores

• Use RemoteActor class to find an actor on a different VM

• Messaging actors in remote VMs is seamless

40

Parallelism: Io

•Nope :-(

•One kernel thread per VM

•No support for remote actors built-in

41

Actors listen42

Receiving messages

• Take a message off the mailbox queue

• Decide if you want to deal with it

• Messages are data

• Timeouts

43

Receiving messagesErlang

loop(State) -> % a tail-recursive function receive {hello, From} -> greet(From), loop(State) ping -> doPingThing(), loop(State) {goodbye, From} -> From ! {kthxbye, self(), State} % no loop after 100 loop(State+1) % inc # of timeouts end.

44

Receiving messagesRubinius

def actor_process() looping = true while looping Actor.receive do |filter| filter.when Hello do |message| greet(message.from) end filter.when Goodbye do |message| message.from << KThxBye[self] looping = false end endend

45

Receiving messagesScala

def act() loop { receive { case Hello(from) => greet(from) case Ping() => doPingThing() case Goodbye(from) => { from ! KThxBye(self) exit() } } }}

46

Receiving messagesIo

MyActor := Object cloneMyActor hello := method(from, greet(from))MyActor ping := method(doPingThing)MyActor goodbye := method(from, from @@kthxbye(self))

anActor := MyActor clone // create actor instance anActor @@hello(self)anActor @@pinganActor @@goodbye(self) // look ma, no loops!

47

Actors avoid deadlock48

No locks, no dead

• Agha(1985) says the semantics of the Actor model mean that deadlock doesn’t exist in a syntactic sense

• Semantic deadlock can be detected and removed easily using wait-for graphs

49

Actors perform great!50

Fine grained, hot CPU

• Lightweight context switching

• Actors don’t suffer from locking granularity issues because there are no locks

• Actors can run “full out” on as many CPUs/machines as the underlying language can make available

51

Conclusion

• Light, fast processes needed to see huge scalability

• Erlang’s the fastest and most mature (see OTP)

• You can’t sneeze in the JVM without declaring it’s chemical composition

• Io is a beautiful little language

52

“erlang is nice, because

everything just works”

Paul JenkinsApril 11, 2008

53

What next?

• Iolang... Io with:

• Support for multiple cores

• Easy way: one VM per core?

• Selective receive

• Support for remote actors

54

No cows were hurt...55

Picture creditsBillie Joe: http://flickr.com/photos/15034493@N00/112357008/sizes/l/

Joe Armstrong: http://flickr.com/photos/mbiddulph/2037845171/sizes/l/Evan Phoenix: http://flickr.com/photos/scoop/1403258349/sizes/o/Steve Dekorte: http://flickr.com/photos/x180/276960722/sizes/o/

Martin Odersky: http://picasaweb.google.com/JavaPolis.com/JavaPolis2007/photo#5144254997958003122Bruno: http://www.smh.com.au/ffximage/2006/10/31/bruno_wideweb__470x329,0.jpg

Coady: http://flickr.com/photos/sebastian_bergmann/116486823/sizes/o/Ships: http://flickr.com/photos/lesec/361956524/sizes/o/

Jim: http://flickr.com/photos/kteague/278136366/sizes/o/LOLcode: http://flickr.com/photos/i-marco/534996407/sizes/o/

Triplets: http://flickr.com/photos/origamijoel/217238954/sizes/l/Spawn: http://flickr.com/photos/austenhaines/399622840/

Parallel runners: http://flickr.com/photos/moodeous/205711924/sizes/o/Microscopic: http://flickr.com/photos/braid44/2232461763/sizes/o/

Emoburger: http://flickr.com/photos/gx9/269025682/Cow: http://flickr.com/photos/66164549@N00/542696674/sizes/o/

icanhascheezburger: http://icanhascheezburger.com/2007/01/11/i-can-has-cheezburger/

Thanks for listening

56

QuestionsMake it quick, Paul’s next

57

Dedicated toCheryl, Cyan, Xavier, and

Justin

58