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
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/
sorry, i should have said "reductions" not "instructions", and proc, not function. I'm an Erlang noob.
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.
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.
Got a source for that?
Many of Scalas abstractions, unlike Kotlin, have runtime cost
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.
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.
Regarding unused variables, the only solutions I am aware of involve renaming to underscore, commenting out or passing to a function like fmt.Println.
These are pretty outdated, it would be interesting to see numbers on the latest versions. I'd be especially curious to compare with Erlang/OTP 21.0 (coming out today) as they did a lot of optimization work on the attributes tested in this benchmark.
(1) Cloud Haskell is primarily designed for execution on distributed memory architectures where the messages pass over a network. So expect that the it would show high communication latency in the first PingPing benchmark.
(2) GHC Haskell processes are lightweight, i.e. maintained in the GHC Runtime Environment, and elsewhere in this discussion called fibres. So expect that it would have fast process creation and be able to sustain a large maximum number of processes (second benchmark).
(3) It's hard to speculate on throughput (third benchmark). The high communication latency may be hidden in a steady state by having multiple requests in the network. Haskell execution time is slower than many languages, but is probably comparable with Erlang and Scala.
Do you have specifics on that matter ?
GHC Haskell is an advanced optimising compiler that will produce considerably faster functional code than both Erlang and Java. For maximum performance, it is perfectly possible to write imperative array-oriented code in Haskell, in which case performance should be comparable to Java.
Please consider all the things Phil Trinder likely knows about GHC ;-)
So it's a good thing that those "benchmarks do not compare like-for-like" because that allows the inclusion of idiomatic Haskell code?
It's a useful resource, but I think we should we wary of making very general remarks based on the results.
The benchmarks game is not restricted to "the idiomatic style" so it isn't a problem that "the idiomatic style" for a particular problem is often not clear.
> Many of the Haskell solutions also look quite old…
We would be very happy to accept new programs:
I doubt crystal is mature enough in its multithreading model (which is still nascent, and IIRC not fully supported in the current rev, and inherited from ruby's in concept) to perform well at all in this. Erlang, Go and Akka were all conceived of specifically to handle multithreaded connections.
With regards the "alternatives considered", Section 2 outlines key characteristics of server languages, and Table 1 analyses a selection of languages against these characteristics.
We welcome others to report results for other languages using the benchmarks.
One thing you might find interesting - a small, crude experiment suggests that changing maxBlocking.erl to use process hibernation for those dormant processes could almost double the max number of processes Erlang can support.
I changed maxBlocking.erl's final few lines to read
erlang:hibernate(?MODULE, q, ).
C#, F#, Go, and Rust can share memory between threads. Those are just ones on the list I am sure about.
So you probably should not make "games with go".