Hacker News new | comments | show | ask | jobs | submit login
Why Scala Actors are Slow (dzone.com)
9 points by Adrock on Feb 25, 2010 | hide | past | web | favorite | 17 comments

A lot of people are using Akka for this instead: http://akkasource.org/

From http://www.scala-lang.org/node/4791: "Akka is now 2-3 times faster than Scala Actors (both event and thread-based) in shootout benchmark."

One of the selling points of Scala is that actors were created as a library without special syntax or compiler support as described in this paper:


One of the advantages of this is that improved implementations can be provided by third parties such as Akka and Lift. Its a shame the current default implementation is so slow but for me this doesn't reflect badly on Scala the language.

Lift is moving (or has moved?) from Scala actors to it's own actor implementation as well.


Well, actually this article fails to answer the main question. I would restate the article as: "Why are my code snippets in Scala perform slow compared to my favorite (and well known) library?" This title would be fair then.

That would be too hard. It's much easier to simply say "I'm right. Everyone else is wrong. This language sucks compared to my favorite language."

I'm quite curious how Scala performs against Erlang in terms of this sort of programming. Scala looks like it brings a decent implementation to a language that's perhaps a little bit more within the grasp of ordinary programmers and also has a vast amount of Java code available through the JVM. However, I'm curious how that all works out in practice...

You should also check out mozart/oz and alice/ml which are better in most respects than erlang

Mozart/Oz does not implement actors though, they are data flow threads.

Actors are threads with state that communicate by message passing. Mozart allows you to create 'active objects' very easily that also can use OO inheritance. Check out the documentation and ctm book.

Sure, I'm not denying you can implement the actor model in Mozart. I just don't think it's quite a fair comparison to say Mozart/Oz does actors better than Erlang. That's just my opinion though.

Actually, a few years ago mozart/oz had better performance of actors than erlang, I don't know what the case is today. Mozart/oz came a decade later than erlang and they incorporated it's lessons into the language - mozart/oz is a multiparadigm language and has a lot of functionality.

You should read the "Capabilities for Uniqueness and Borrowing" paper. There is a compiler extension to support them. It should make actors much faster (no need to synchronize on messages).


Aren't Actors and Closures the same thing?

No, sir. :)

Then would someone mind clarifying this statement by Paul Graham?

"... A famous example of this is Steele & Sussman's discovery, during the writing of Scheme, that Actors and closures were the same thing."

-ref: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

Closures are a convoluted way of of doing things that objects and actors do better.

"Asynchronious message passing is old and great idea. Instead of synchronizing objects and dealing with deadlocks we try to isolate objects and let them exchange messages. Erlang proved it to be extremly powerful tool applicable to wide range of highly scalable mission critical applications.

In JVM landscape big interest to this approach started after introducing Scala actors. "

That statement is so very poorly informed! JMS ("surprise"?) has been a sign of "interest" in "Asynchronious message passing" in the "JVM landscape".

I am not up on my Scala, but the author fails to convey (based on what I do know ;) the competence level that would lend weight to his attempt to address (much less support) the topic.

For those interested in other JVM alternatives, Kilim seems quite promising and seems to hold its own quite well in benchmarks against Erlang.



http://sujitpal.blogspot.com/2009/01/more-java-actor-framewo... [scroll to end to see the impressive results for Kilim.]


[edit: added pdf link]

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact