Hacker News Reader

Comment by yankoff | Hacker News Reader

Go example seems off too from what the author intentions were. As for the dispatcher, I don't believe it will actually give any resource to a future that is already complete? OP wanted to have messages going through 1M actors, so there would be a moment when each actor gets a thread from a thread pool.

View on HN

However it makes a difference if I create 1M actors and dispatch them via reflection or if I create some of them and passing results back and forth. actually goroutines would use static dispatching and don't have a lot of overhead. however a scala actor is totally different than any goroutines or erlang actors, they are keeping a lot of state. a promise/future is actually a little bit better in this kind of sense, still the jvm version will actually (even when optimized) use way more memory.

This is a silly argument. If I read you right, you are saying that a goroutine is closer to a promise/future than a Scala actor in terms of resources used, and therefore it's OK to use futures instead of actors in the Scala code and compare them that way.

That betrays the whole benchmark. The basic point of the benchmark is to answer the question, "How expensive is it to create and run 1,111,111 actors in various languages?" You can't make a manual optimization that causes only 111,111 actors to be created and then say that it's a better comparison.

goroutine is not an actor. its a concurrency mechanism. so a goroutine is not an actor, however a future (http://doc.akka.io/docs/akka/2.4.1/scala/futures.html#Use_Di...) is definitly closer to an actor than a goroutine. so you can't compare golang and scala/erlang. too bad, huh?

And when you are clever you would be comparing monads, which actually a goroutine could be. and a future/promise, too.

Btw. Even a Future does more than a goroutine do. it won't crash your whole program when it fails, which a goroutine does.

Yes, goroutines are a concurrency mechanism. Actors are also a concurrency mechanism, so I fail to see why the comparison is unfair. As you say, Actors are safer in that uncaught exceptions in an actor will not bring down a program. They have a few more dials and knobs, you can store references to them, and they are more heavyweight. They have more overhead as can be expected from these facts and this is exhibited in benchmarks like this one.

Futures are not a concurrency mechanism precisely. They are a monadic data structure around possibly-concurrent execution. You can wrap a Future around concurrent execution by an Actor, or you can do what you have done and wrap a Future around a sequential recursive computation. As with the synchronous .NET core implementation of the benchmark, the performance is better due to not having the overhead of Actors or other concurrency. Like the synchronous .NET core implementation writing the computation this way is not a fair comparison to the other languages in the benchmark and the high performance does not indicate anything about the efficiency of the concurrency mechanisms available in Scala.

Reply on news.ycombinator.com