Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

Post by igouy » Wed, Jun 20, 2018, 4:12 PM UTC

willtim wrote: post #48

trinder wrote: post #37

Earlier quoted context omitted.

There are various multi-language benchmarks, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/

Those benchmarks do not compare like-for-like. Often the Haskell versions try to solve the problems elegantly with high-level functional code at the expense of performance, e.g. see Mandelbrot. 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 Haske…

Post by igouy » Thu, Jun 21, 2018, 12:28 AM UTC

willtim wrote: post #52

igouy wrote: post #51

Earlier quoted context omitted.

> GHC Haskell is… Please consider all the things Phil Trinder likely knows about GHC ;-) https://scholar.google.co.uk/citations?user=3Bs_EA0AAAAJ

My post was more for the benefit of other readers, who might have otherwise concluded that modern GHC is "slow". There are many ways to compare the 'execution time' of e.g. Java and Haskell. Idiomatic Haskell code may well be slower than (traditional) idiomatic Java code. But these days more and more functional code is written in Java/Scala/Clojure and the JVM does not optimise such code nearly as well as GHC.

Post by willtim » Thu, Jun 21, 2018, 7:02 AM UTC

igouy wrote: post #53

willtim wrote: post #52

Earlier quoted context omitted.

My post was more for the benefit of other readers, who might have otherwise concluded that modern GHC is "slow". There are many ways to compare the 'execution time' of e.g. Java and Haskell. Idiomatic Haskell code may well be slower than (traditional) idiomatic Java code. But these days more and more functional code is written in Java/Scala/Clojure and the JVM does not optimise such code nearly as well as GHC.

> Idiomatic Haskell code may well be slower… So it's a good thing that those "benchmarks do not compare like-for-like" because that allows the inclusion of idiomatic Haskell code?

Post by tome » Fri, Jun 22, 2018, 6:36 AM UTC

igouy wrote: post #56

willtim wrote: post #55

Earlier quoted context omitted.

I can certainly see merit in that idea. The problem is that it's often not clear what the idiomatic style for a particular language applied to a particular problem is. Many of the Haskell solutions also look quite old, predating for example the now standard Haskell "Vector" library. It's a useful resource, but I think we should we wary of making very general remarks based on the results.

We should we wary of making very general remarks, period. 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: https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

Post by trinder » Sat, Jun 23, 2018, 5:20 PM UTC

tonyg wrote: post #50

trinder wrote: post #28

Earlier quoted context omitted.

There were many languages that we would like to have considered. We do expect the performance of Elixir to be pretty similar to Erlang as it runs on the same VM (BEAM). 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 benc…

Hi Phil, 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 p() -> erlang:hibernate(?MODULE, q, []). q() -> receive "hello" -> io:format("Hello") end. RabbitMQ uses hibernation in many places…