Hacker News Reader

Comment by thermodynthrway | Hacker News Reader

I appreciate the time obviously spent on this, but i see a couple errors and ommissions. C# and F# are VM languages that run on the CLR which is extremely similar to the JVM.

Also, Go and Erlang use fiber blocking threads (userspace threads). A fair comparison would use fiber blocking in Scala/Java as well using Comsat/Quasar.

I have a feeling JVM based languages would perform far better than Erlang, and possibly even as fast as Go if fiber blocking threads were used.

Edit: they're using Akka which (I believe) IS fiber blocking so part of my critique may not apply. However, Scala is known for generating somewhat slower code than Java so I would expect Java with fibers to perform 2-10x better

View on HN

Akka is built on top of the JVM which doesn't support fibers (yet: see http://openjdk.java.net/projects/loom/). Akka implements its own scheduling atop Java's fork-join thread pool. Fibers at the JVM layer would be faster.

Similar to Quasar then I assume. I'm sure native fibers would be faster, but bytecode is fairly close to ASM and i don't think the performance difference is large.

Benchmarks I've seen for Quasar show no performance difference to regular threads at low paralellism but it can scale much higher

Found a great article comparing Akka's Actors vs Quasar http://blog.paralleluniverse.co/2015/05/21/quasar-vs-akka/

Not only that, its non blocking. Meaning you can have a very small thread pool with great performance. Think 1 thread per core.

Quasar is Loom. Hopefully pron chimes in.

Loom is quite a bit different than Quasar, but pron (aka Ron Pressler), is leading the way on both. Loom is essentially Quasar would have loved to have baked into the JVM. It's the solution for the bytecode rewriting hackery and resulting limitations it faced.

I don't think erlang procs are fibers, they are allotted a certain timeslice and if the instructions for the function exceed the timeslice the function is preempted and the VM comes back to it later, it's also preempted if it blocks on io or waiting for a message, of course.

Erlang does not preempt, a reduction is always completed before the scheduler decides on whether or not to move on to another thread. Reductions are small enough that this isn't a problem.

http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...

sorry, i should have said "reductions" not "instructions", and proc, not function. I'm an Erlang noob.

>C# and F# are VM languages that run on the CLR

well normally, there are some cases where you can compile C# and f# native now:

mono can do it, that is how it targets IOS microsoft has tooling that does it for universal apps and coming soon! AOT native compilation for anything you want.

But yes, the normal way of things with C# and F# is just like Java, and Java has special cases where you can do AOT compilation too.

Actually you can compile VB.NET, C#, Managed C++ (latter C++/CLI) and eventually F# to native since .NET exists, but many seem to keep forgetting about NGEN, as it requires strong assemblies.

Likewise Java always had AOT compilers to native code, but since Sun was religious against it, only commercial third party JDKs offered it as option. It is quite common in embedded deployments.

But as usual among recent trends regarding dev tools, very few were willing to pay for them.

> Scala is known for generating somewhat slower code than Java so I would expect Java with fibers to perform 2-10x better

Got a source for that?

Benchmarks game used to have stats for Scala but apparently not anymore.

Many of Scalas abstractions, unlike Kotlin, have runtime cost

Well, you don't have to use those abstractions. But yes, it's a sad fact that when programming in Scala, the closer to Java-style you program, the faster your program will be.

I haven't read this paper closely, but it looks like it's more measuring the performance of Akka, rather than the performance of Scala. Akka does reasonably well here compared to Erlang, so I don't think there's anything we can complain about.

Could you get all of Akka's features with better performance if it was made in Java? I doubt it. Optimized Scala and Java code should be identical.

This depends on the VM you are using. Currently GraalVM gives Scala a huge speedup (sadly the speedup comes with startup cost, etc, which would not benefit the bechnmarks game)

> Many of Scalas abstractions, unlike Kotlin, have runtime cost

Whoa there, many of Kotlin's do too. Because one uses an option class and another inserts precondition checks in a lot of places, doesn't mean the latter is zero cost. While Kotlin overall probably has less overhead with better primitive use and what not, there are cases where Scala is less because of macro support.

Reply on news.ycombinator.com