Home

LCA2007: Concurrency and Erlang

Extremely attractive overview and slides about a one-hour Erlang talk by André Pang at linux.conf.au 2007.

I gave a talk titled Concurrency and Erlang at Linux.conf.au in January, 2007. Thank you so much to everybody who attended it and made me feel welcome: I got overwhelmingly positive feedback from it, and it was an honour to speak at such an esteemed conference.

Another reason I wish I'd talked myself into attending this conference!

By Luke Gorrie at 2007-01-21 20:50 | General | other blogs | 11787 reads

Comment viewing options

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

Not persuaded that the Erlang model can handle games

Since games(and generally simulations) can not afford to avoid variable updating, how does the Erlang concurrency model apply to languages that are not purely functional? The slides show how hard is to make a multithreaded game, then goes on to show how Erlang handles massive concurrency, but the two are not put together. It seems that the application of the Erlang concurrency model onto games is left as an exercise for the viewer...

By Achilleas Margaritis at Mon, 2007-01-22 11:10 | login or register to post comments

tail recursion + mailbox simulates mutable variables

Basically, to access or set the variable you send a message. The listening process takes appropriate action, calls itself with a new state, and listens again. Since it's tail recursive, the stack doesn't blow up.

I think the .pdf of the erlang book shows how to maintain a state machine with this method.

By grant at Mon, 2007-01-22 15:12 | login or register to post comments

Harder problem than it sounds

I have been doing lots of thinking and experimentation with how Erlang could be used to write games, and I think your comment above oversimplifies things. Sure, you can encapsulate data with tail recursive calls, but that's only the beginning.

Moving every game object into its own process is not necessarily the right way to go--for Erlang. It is a great way to write a state machine, but all object positions and animation states (etc.) need to be accessible somewhere. You could have a bunch of objects and processes reporting to a database process that tracks everything, but it's not clear if this is a real concurrency win. (Remember, in a game everything operates in lock-step fashion based on internal ticks of the clock.) Each object process also needs to respond to various messages from outside stimuli, and it's not clear how to nicely write a state machine that can also respond to these events.

Additionally, I've found that being functionally pure within a single process isn't as much of a win as I once thought it would be. For simulation-style programs, it can lead to contrived code. Many a time I've wished for both updateable local and process-global variables (and I've done quite a bit of functional programming, so this isn't coming from inexperience).

By James Hague at Mon, 2007-01-22 15:41 | login or register to post comments

Not suggesting that Erlang is the be-all-and-end-all

There was a very brief comment in one of the slides near the middle of the talk -- the one that said "Concurrency-Oriented Programming" -- where I talked about the possibility of using one thread of execution per game object. If there are 1,000 soldiers walking around in the gaming battlefield, having lightweight threads opens up the possibility of using one thread of execution per soldier (i.e. 1,000 threads). I've had a look at some UnrealScript concepts, and its use of actors, times, states etc seem to map quite closely to what Erlang does.

I'm not actually suggesting that one use Erlang to implement a game, mind you: it's really not the best choice for that kind of task due to games being e.g. heavily CPU-bound. I'm merely suggesting that having a concurrency-oriented mindset to solving the problem can help -- a lot! (Perhaps using some form of lightweight threads in C++ might do, for example.)

I'm sure Tim Sweeney can comment a lot more -- hopefully he won't kill me for plastering a big photo of him on my slides...

By Andre Pang at Mon, 2007-01-22 13:57 | login or register to post comments

BTW

Should we take your enthusiasm for Erlang in parallel computing combined with your educational background as a damning indictment of the state of data-parallel Haskell? :-)

By Luke Gorrie at Mon, 2007-01-22 23:18 | login or register to post comments

Don't know much about data-parallel Haskell

Laugh, not at all. I don't know much about Parallel Haskell, so I'm certainly not damning it in the least. From what little I know about Data Parallel Haskell, DPH is probably much more suitable for parallel applications where computations and maximising CPU power are important, such as scientific computations. A lot of the motivation for the recent work on Associated Types in Haskell came from the scientific application background. Erlang, on the other hand, is much more suitable for highly concurrent I/O-bound applications, where CPU isn't so important, such as network servers.

By Andre Pang at Tue, 2007-01-23 01:29 | login or register to post comments

Talk was 30 minutes, not one hour

Oh, and just as a very small pedantic correction to the LtU story, the talk was 30 minutes, not an hour :).

By Andre Pang at Mon, 2007-01-22 23:07 | login or register to post comments

Excellent talk in an excellent conference

I did manage to get to LCA2007, and I even managed to get to Andre's talk. It was well attended and well received, I have to congratulate Andre on an excellent presentation.

The presentation was recorded, but it doesn't look like it has made it out of post-production yet.

By Andrae Muys at Thu, 2007-01-25 07:39 | login or register to post comments

Very good!!

This was a really good talk. It's pretty exciting to think of Erlang being properly introduced to such a well-suited audience. André, you'll never pay for beer at an Erlang conference. :-)

I wouldn't say that it's usually important to request Erlang processes to shutdown like with the diediedie message. Terminating an Erlang process with exit is like terminating a Unix process with SIGTERM or SIGKILL. Erlang processes have separate heaps so they categorically don't have the problems of e.g. Java's Thread.stop() or Lisp's INTERRUPT-THREAD where a half-finished update can put a shared heap into a funny (or perhaps "hilarious") state.

The normal way to build an Erlang system is so that it neatly handles the termination of any process at any point of execution so that you're robust to your own bugs. Once you've done this it's not particularly scary to deliberately crash things, even in live telecom systems. It's like the comfort and predictability you have in kill'ing processes on a Unix system.

The crash-only software paper said this the best. I would imitate Dijkstra and summarise that "Graceful shutdown is just a special case of crashing, and not a particularly interesting one at that."

NOTE: I can't edit that inappropriate "I disagree" out of the subject so please just ignore it. :-)

By Luke Gorrie at Sun, 2007-01-28 09:23 | login or register to post comments

[OT] the subject line elves...

...have fixed your subject line. The DIY solution is to delete the newline at end to see the hidden bits.

By Anton van Straaten at Sun, 2007-01-28 11:41 | login or register to post comments

Thanks!

Thanks for the kind comments Andrae and Luke (and also to dnz -- I didn't even realise that the video was up yet). Not paying for beer at an Erlang conference may be a bad idea after a few hours, though!

By Andre Pang at Wed, 2007-01-31 01:55 | login or register to post comments