Comparing Languages for Engineering Server
Software: Erlang, Go, and Scala with Akka
http://www.dcs.gla.ac.uk/~trinder/papers/sac-18.pdf
Contains nice performance/throughput/latency comparison
5 Likes
Erlang performance is not so bad - far better process spawn time, throughput very similar to Scala + akka, a bit worser than Golang one
For those who canāt download PDFs at work etc, hereās the conclusion (Iāve highlighted mentions of Erlang):
Conclusion
We have investigated programming language characteristics that support the engineering of multicore web servers. Crucially these languages must be able to support massive concurrency on multi- core machines with low communication and synchronisation over- heads. We have analysed 12 languages considering computation, coordination, compilation, and popularity, and selected three rep- resentative high-level languages for detailed analysis: Erlang, Go, and Scala/Akka (Section 2). We have designed three server bench- marks that analyse key performance characteristics of the languages, i.e. inter-process communication latency, process creation time, the maximum number of supported processes, and throughput (Sec- tion 3).
A summary of the recommendations based on this small set of benchmarks is as follows. For a server where minimising message latency is crucial, Go and Erlang are the best choice (Figure 3). Interestingly Akka significantly reduces communication latency in Scala (Figures 3(a) and 3(b)). Scala/Akka are capable of maintaining the largest number of dormant processes (ā¼11M processes in Figure 4(a)), while Erlang performs the best when processes are short lived and the goal is to ensure minimal spawn time, e.g. Erlang takes 58s to spawn 9M processes (Section 4.2). In server applications where up to 100,000 processes are frequently spawned, Erlang and Go minimise process creation time and scale smoothly (Figure 4(b)). Experiments with communicating pairs of processes show that Go provides the highest throughput independent of the number of cores and the number of process pairs (Figure 5).
Comparing the performance of complete case study servers im- plemented in each language would significantly reinforce these results, and one possibility is an Instant Messaging (IM) bench- mark [4]. It would also be interesting to study the performance overheads of providing fault tolerance and of recovering from faults, another key server capability. Finally we could compare the perfor- mance of server languages on distributed memory architectures, e.g. a cluster of multicores.
2 Likes
As Chris mentioned elsewhere, Phoenix pubsub is the only one of the pubsub implementations tested that supports being distributed.
4 Likes
In my opinion this isnāt a fair comparison; these are not āprocessesā they are Futures. Scalaās monad comprehensions can make your Future code look sequential, but is not sequential, and you cannot use traditional IO libraries at all outside of a dedicated thread-pool or you will block your entire scheduler.
4 Likes
This is one of the things that bugs me about C++ with ASIO libsāslip up and make one lousy call to the wrong standard function, and now you have a latent performance disaster that will not show up in any test but is just waiting to collapse throughput under a critical load.
2 Likes
