Benchmarking Actor/Fiber Implementations

[Volkan Yazıcı]

Hi!

I have just released a new project (fiber-test) for the purpose of benchmarking a multitude of fiber/thread implementations on JVM. As of now, benchmarks include Java Threads, Akka/Quasar actors, and Quasar fibers. In order to exploit Quasar to its utmost potential, I will be happy if you can share your optimization enhancements on QuasarActorRingBenchmark and QuasarFiberRingBenchmark classes. Any comments will be really appreciated.

Best.

[Volkan Yazıcı]

Hi!

I just uploaded a new blog post that presents a performance comparison between Akka Actors, Quasar Actors, and Quasar Fibers. Figures show that while Quasar fibers show superior performance, Quasar Actors do slightly worse compared to Akka Actors and the profiler results point that the employed channel implementation might be the problem. In addition, Quasar Fibers show random hiccups when used along with taskset. Before making an announcement on Reddit or similar portals, I would like to hear your comments.

Best.

[pron]

Hi Volkan. Nice work!

My main contribution would be this: Quasar and Akka provide completely different abstractions. Quasar provides fibers while Akka provides an asynchronous-programming framework based on callbacks. Both libraries then implement actors using their respective abstractions. As you mention yourself, fibers are lightweight threads, which means that their most important property — even before being light-weight — is being threads. The thread abstraction is a series of sequential computations with the ability to block — on IO or synchronization. Callbacks, on the other hand, are a completely different abstraction. Akka’s callbacks (and therefore actors), are not allowed to block, and therefore do not provide a thread abstraction; hence they’re not fibers.

Quasar’s main design goal was the desire to make the simple, familiar, threading abstraction (i.e., synchronous, blocking code) cheap, as kernel threads are expensive, and blocking a kernel thread carries a lot of overhead. Quasar is used to run servlets that serve hundreds of thousands of concurrent requests — instead of mere thousands — all without changing your existing Java code. We want developers get the full performance benefits of asynchronous code — which Akka also offers — while keeping their APIs and synchronous programming model — which Akka certainly doesn’t. Quasar makes threading cheap, while Akka abandons the thread abstraction altogether. In that respect, Quasar is a lot more similar to Erlang and Go (which, of course, provided the inspiration to Quasar), which also use the thread abstraction but provide a lightweight thread implementation. 

Akka’s design goals are different, and we think Quasar is far simpler to use than Akka, requires less mental overhead and far-less re-engineering, while at the same time being more feature-rich. 

[Volkan YAZICI]

Thanks so much for the detailed explanation!

I shamelessly plugged your post into the "Akka and Quasar" section.

--
You received this message because you are subscribed to a topic in the Google Groups "quasar-pulsar-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/quasar-pulsar-user/NrYOyUTqdcg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to quasar-pulsar-u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pron]

Quasar and Akka section of what?

Also, there’s another big (practical, not philosophical) difference between Quasar and Akka. Akka works particularly well with Scala, and while it does have a Java API, it feels very foreign to Java programmers. Quasar, on the other hand, does not yet support Scala, while it has a very familiar, natural, Java and Clojure APIs, and will have official support for Kotlin very soon. So, while they’re both JVM libraries, Akka and Quasar currently target different ecosystems.

On Tuesday, September 2, 2014 8:26:39 PM UTC+3, Volkan Yazıcı wrote:

Thanks so much for the detailed explanation!

I shamelessly plugged your post into the "Akka and Quasar" section.

To unsubscribe from this group and all its topics, send an email to quasar-pulsar-user+unsub...@googlegroups.com.

[Volkan YAZICI]

"Akka and Quasar" titled section in the blog post I mean.

To unsubscribe from this group and all its topics, send an email to quasar-pulsar-u...@googlegroups.com.

[Wen Tao]

Quasar seems like using exception to unwind the stack while kilim is using return. Is that true? Is there any performance difference between quasar and kilim. That might be a good benchmark candidate.

[pron]

Yes, Quasar uses an exception; I don’t know what Kilim uses. But there are many other things much likelier to cause performance differences than this: use of a different scheduler, queue implementation etc. (BTW, our queues could be made much faster, very easily; fixing them is just not a burning issue at the moment). An exception (that’s reused and has no stack trace) is very efficient, and I doubt switching to return would have any positive noticeable performance benefits.

Besides that, Kilim is a beautiful project that served as partial inspiration to Quasar (in fact, back when Quasar was very young, we considered using Kilim as the foundation), but Quasar both has a much wider scope and applicability, and is under constant development. While Kilim isn’t defunct, it is not a very active project anymore.