I noticed that you send the "native threading" case through your library as well. Have you compared to just using "naive" Java - Threads and a BlockingQueue?
Also: if the Google patches for the user-mode threading are adopted, will Quasar have any advantages over a JVM that uses the same syscalls? Can you explain where this would come from?
I think what you've done is genuinely cool, I'm just trying to better understand what the 10x advantage actually comes from.
The channels used are just like BlockingQueue. They're a queue with a synchronized condition variable.
If user-mode threading is adopted, Quasar could work without instrumentation, but instrumentation is a very small part of the Quasar code base.
Quasar gives you the scheduler, channels, actors, etc.
The 10x performance boost comes from the fact that there can be non-negligible latency from the time you unpark a thread to the time it starts running, while for fibers that latency is much shorter.
I looked and your wrapper did look similar (and not obviously incorrect), but if you plan on publishing this benchmark, I would suggest including a comparison against raw Java code, for credibility's sake.
I guess I'm really wondering: let's say Java 9 mutexes use Linux 4's user-mode threading syscall; in that case do we need Quasar's scheduler, channels, actors etc. Or can we just use "good-old" threads and mutexes? Where would Quasar's benefits come from?
It sounds to me like the subtext to Google's patches is that rather than accepting the conventional wisdom that "threads don't scale", they've instead just fixed threads.
That's not how those kernel modifications work. You can't just use them with a mutex. The idea is that a thread will be able to say, I'm yielding the CPU to this other thread. When you unlock a mutex you don't necessarily want to park yourself. These changes require either an app-level scheduler, or the use of synchronization mechanisms that can better specify what you want in terms of scheduling. An example for such a mechanism would be an API that says: I'm sending a message to this other actor, but I'm going to wait for it to reply. In this case, the implementation would tell the OS, switch me out and switch that other guy in instead.
OK, I was being sloppy in my phrasing (and probably thinking also)!
Trying again: Taking your example benchmark, you aren't really calling any special methods that provide any hints for cooperative threading (to my untrained eye). That's great - you've got a great abstraction. But then, what opportunities for optimization does Quasar have, that are not also available to a JVM using the magic syscall?
I'm sure there's something here, but I'd appreciate a hint!
Just to clarify: it's not that easy. The syscalls are the first step, and then you'll need a scheduler. Once you have those two, you still need new synchronization mechanisms and APIs.
Quasar doesn't just provide lightweight threads. It has rich libraries that help you make the best of them.
Also: if the Google patches for the user-mode threading are adopted, will Quasar have any advantages over a JVM that uses the same syscalls? Can you explain where this would come from?
I think what you've done is genuinely cool, I'm just trying to better understand what the 10x advantage actually comes from.