Not totally fair

[quilombodigital]

I think the test may have some issues:

• Scala uses the java vm, that is well know to need a time to "warm-up" and the JIT compiler kick-in. Some info: http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java and http://www.oracle.com/technetwork/articles/java/architect-benchmarking-2266277.html
• Scala, Erlang and Go actors have truly different features, like network and even monitoring support. And java objects will always be slower to instantiate, no matter what.
• You are mixing the instantiation metrics with the execution metrics, so you are targeting a very specific use-case (an application where you have very short lived calls, with a very short computation performed). In real world scenarios, actors are more resilient, and live through the user session lifecycle. At this moment, inter-actor communication becomes more important than everything, and all these languages have different approachs to the problem.

Good job anyway, []s, Ricardo Mello

[megri]

Also, the C# example uses Task which are similar to Scala Future. Actors — at least how they are envisioned in Scala — are constructs which encapsulate accessible state in a concurrent environment. There is no need for accessible state in these examples so the overhead is probably unnecessary.

[wizzard0]

Yep, IMHO Go, C# and Haskell examples are close (task-based), so are Erlang and Akka ones (actor-based). There's a PR with Future-based Scala example, need to measure that :)

[jadbox]

The Node example using Promises also puts it into an entirely different category. It would be better to use the async module for Node or use the Cluster feature (although that creates an entirely new process).

[ochrons]

Yeah, Node version is not concurrent at all. If we allow for that, all examples would be quite different and probably perform better since the actual "computation" is a no-op.

[ghost]

As for Node's asynchrony: Note that you're actually benchmarking a Promise library, not native promises.

[ondrej-li]

@ochrons Totally agree. Just because you call something async doesn't mean it is in fact async! And that's why the node version is so fast - it just does the calculation without any overhead that is normally associated with concurrent programing (IPC, thread management etc.).

[joshburgess]

I think the README should be updated to remove the word actors. C# Tasks are not actors, which makes the following sentence inaccurate and misleading:

"Creates an actor (goroutine, whatever), which spawns 10 new actors, each of them spawns 10 more actors, etc. until one million actors are created on the final level."

Actors and async tasks are not the same thing.

Something like actors do exist in the .NET world in the Orleans framework, but they are different than what's found in Akka or Erlang. For more info on Orleans' "Virtual Actors":

https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md

http://daprlabs.com/blog/blog/2014/04/03/microsoft-orleans-why-its-cool-useful/

For that matter, Goroutines and Elixir/Erlang processes are also a bit different from each other

Anyway, like others have said, it doesn't make sense to compare Tasks/Futures/Promises/etc. with Actors/Virtual Actors/Goroutines/Erlang processes, as they aren't really doing the same things.

[shashwata]

One another thing I noticed was the delay in Akka test runs were mainly due to GC. I increased the JVM memory and ran the tests again and I got better performance. @atemerev, can you please the memory consumed by each implementation so that we understand we were not too unfair with JVM.