I’ve recently been delving into functional programming especially Haskell and F#, the prior more so. After some googling around I could not find a benchmark comparison of the more prominent functional languages (Scala,F# etc).
I know it’s not necessarily fair to some of the languages (Scala comes to mind) given that they are hybrids, but I just wanna know which outperforms which on what operations and overall.
8
According the Great Benchmarks Game, ATS is faster than the rest with Haskell, Scala, and one of the variants of Common Lisp in a rough tie for speed close behind that. After that Ocaml and F# are in roughly the same speed category with Racket and Clojure lagging behind…
However, almost none of this means anything at all really. It’s all a question of problem, machine, compiler, coding techniques, and in some cases, plain luck. Generally speaking, Directly machine coded languages like Haskell will outperform VM compiled languages like F# and vastly outperform purely interpreted languages. Also generally, Statically typed languages are faster than Dynamically typed due to static analysis allowing all type operations to be calculated at compile rather than run time. Again, these are general rules, there will always be exceptions. “Paradigms” have little to do with it.
4
It should also be pointed out that you cannot measure / quantify the performance of a programming language. The best you can do is measure the performance of a specific implementation of the language on specific platforms, running specific programs.
So when you ask about “the fastest functional language”, what you are really asking about the best of the current implementations of the language(s).
@igouy’s comment raises the point that there are other performance measures for language implementation; e.g. compilation time. But that doesn’t change the fact that application program’s run time is an (indirect) measure of a language’s implementation, not a measure of the language itself.
Consider Java for example. Suppose I write a single-threaded benchmark using solely language features of classic (Java 1.0) Java. If I compile and run using JDK 1.0, I will get a poor performance (‘cos JDK 1.0 didn’t have a native code compiler). If I go from JDK 1.1 to … JDK 1.7, I will most likely get progressively better results. But this is not due to changes to the Java language … because my benchmark is using the same language subset. Rather the speedup is due to improvements in the compilers, the runtime system and / or the implementation of class libraries. These are all implementation issues.
The other point is that these implementation differences can be really significant (e.g. orders of magnitude) for the same language. So the fact that the best implementation for language X is faster than the best (or only) implementation of language Y doesn’t necessarily tell you a lot about the language itself.
8
If you are looking at languages only on speed of execution you are missing some major points. Speed is a good thing, but it is not the only thing.
Haskell uses a very robust type system to create programs that will be much more likely to be bug free and robust.
Erlang uses its built in monitoring system to allow you to create fault systems that can give you a huge level of reliability in the face of various types of faults. In addition Erlang can give you a level of concurrency that is hard to match in other languages.
In truth I would consider speed of execution in the modern day to be rather far down on the list of what I would consider in most cases. (OK if I was doing massive numeric computation I would probably want to use fortran for speed but otherwise Its just not important enough to matter)