4 ms·

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 simil

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

deleted 8y ago
[deleted]
richdougherty 8y ago
Akka is built on top of the JVM which doesn't support fibers (yet: see http://openjdk.java.net/projects/loom/ 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.
- thermodynthrway 8y ago
  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/ http://blog.paralleluniverse.co/2015/05/21/quasar-vs-akka/
- stephen123 8y ago
  Not only that, its non blocking. Meaning you can have a very small thread pool with great performance. Think 1 thread per core.
  - deleted 8y ago
    [deleted]
- yanslookup 8y ago
  Quasar is Loom. Hopefully pron chimes in.
  - kjeetgill 8y ago
    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.
dnautics 8y ago
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.
- jacquesm 8y ago
  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.
  - dnautics 8y ago
    http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html 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.
gameswithgo 8y ago
>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.
- pjmlp 8y ago
  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.
monksy 8y ago
> 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?
- thermodynthrway 8y ago
  Benchmarks game used to have stats for Scala but apparently not anymore. Many of Scalas abstractions, unlike Kotlin, have runtime cost
  - DavidTNcl 8y ago
    > Many of Scalas abstractions, unlike Kotlin, have runtime cost Got a source for that?
  - tormeh 8y ago
    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.
    - deleted 8y ago
      [deleted]
  - merb 8y ago
    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)
  - kodablah 8y ago
    > 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.
deleted 8y ago
[deleted]

deleted 8y ago

[deleted]

richdougherty 8y ago

Akka is built on top of the JVM which doesn't support fibers (yet: see http://openjdk.java.net/projects/loom/ 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.

thermodynthrway 8y ago
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/ http://blog.paralleluniverse.co/2015/05/21/quasar-vs-akka/
stephen123 8y ago
Not only that, its non blocking. Meaning you can have a very small thread pool with great performance. Think 1 thread per core.
- deleted 8y ago
  [deleted]
yanslookup 8y ago
Quasar is Loom. Hopefully pron chimes in.
- kjeetgill 8y ago
  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.

dnautics 8y ago

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.

jacquesm 8y ago
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.
- dnautics 8y ago
  http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html 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.

gameswithgo 8y ago

>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.

pjmlp 8y ago
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.

monksy 8y ago

> 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?

thermodynthrway 8y ago
Benchmarks game used to have stats for Scala but apparently not anymore. Many of Scalas abstractions, unlike Kotlin, have runtime cost
- DavidTNcl 8y ago
  > Many of Scalas abstractions, unlike Kotlin, have runtime cost Got a source for that?
- tormeh 8y ago
  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.
  - deleted 8y ago
    [deleted]
- merb 8y ago
  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)
- kodablah 8y ago
  > 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.

deleted 8y ago

[deleted]