This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Scala and the fly likes Scala vs erlang Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Languages » Scala
Bookmark "Scala vs erlang" Watch "Scala vs erlang" New topic
Author

Scala vs erlang

Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
Hi,

How much is it more expensieve to create new process in scala comparing to erlang?

Thanks a lot,

Stephane Clinckart
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Hi Stephane,

what exactly do you mean with "process"? Maybe threads or real OS level processes? Unfortunately I don't know Erlang, but I think Scala typically only uses threads (despite the fact that it probably would be possible to execute native parts which could use real processes).

Marco
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
Marco Ehrentreich wrote:Hi Stephane,

what exactly do you mean with "process"? Maybe threads or real OS level processes? Unfortunately I don't know Erlang, but I think Scala typically only uses threads (despite the fact that it probably would be possible to execute native parts which could use real processes).

Marco


Please check on this:
http://yarivsblog.com/articles/2008/05/18/erlang-vs-scala/


Scheduling


The Erlang VM schedules processes preemptively. Each process gets a certain number of reductions (roughly equivalent to function calls) before it’s swapped out for another process. Erlang processes can’t call blocking operations that freeze the scheduler for long periods. All file IO and communications with native libraries are done in separate OS threads (communications are done using ports). Similar to Erlang’s per-process heaps, this design ensures that Erlang’s lightweight processes can’t block each other. The downside is some communications overhead due to data copying, but it’s a worthwhile tradeoff.

Scala has two types of Actors: thread-based and event based. Thread based actors execute in heavyweight OS threads. They never block each other, but they don’t scale to more than a few thousand actors per VM. Event-based actors are simple objects. They are very lightweight, and, like Erlang processes, you can spawn millions of them on a modern machine. The difference with Erlang processes is that within each OS thread, event based actors execute sequentially without preemptive scheduling. This makes it possible for an event-based actor to block its OS thread for a long period of time (perhaps indefinitely).

According to the Scala actors paper, the actors library also implements a unified model, by which event-based actors are executed in a thread pool, which the library automatically resizes if all threads are blocked due to long-running operations. This is pretty much the best you can do without runtime support, but it’s not as robust as the Erlang implementation, which guarantees low latency and fair use of resources. In a degenerate case, all actors would call blocking operations, which would increase the native thread pool size to the point where it can’t grow anymore beyond a few thousand threads.

This can’t happen in Erlang. Erlang only allocates a fixed number of OS threads (typically, one per processor core). Idle processes don’t impose any overhead on the scheduler. In addition, spawning Erlang processes is always a very cheap operation that happens very fast. I don’t think the same applies to Scala when all existing threads are blocked, because this condition first needs to be detected, and then new OS threads need to be spawned to execute pending Actors. This can add significant latency (this is admittedly theoretical: only benchmarks can show the real impact).

Depends on what you’re doing, the difference between process scheduling in Erlang and Scala may not impact performance much. However, I personally like knowing with certainty that the Erlang scheduler can gracefully handle pretty much anything I throw at it.

Kind regards,

Stephane
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Unfortunately I know almost nothing about Erlang and not very much about the internals of Scala's actor implementation, so guess I can't give you a helpful answer :-) But from your short overview here I get the impression that both - Scala and Erlang - and their implementation / runtime platform is not exactly comparable. It seems like the details are in fact really different inside...

On the other hand I wonder how much relevance potential performance differences have for real world applications which are usually doing a lot more things besides executing jobs in parallel. Do you think there's a big impact on overall application performance?

Marco
 
GeeCON Prague 2014
 
subject: Scala vs erlang