tl;dr: "we remark that all 3 languages provide easy-to-use, high-level and efficient support for parallelism. Haskell has an edge in its rich libraries and aggressive optimisation. Through laziness, top-level parallelism can be specified in a more modular way, minimising the need to modify components and avoiding any notion of explicit threads. Thus, Haskell is the language of choice for minimally intrusive parallelism. F# and Scala provide several mechanisms for parallelisation, some as high level as Haskell’s, some lower level with more potential for performance tuning. Thus, these languages provide a more direct route to controlling low level aspects and can use object-oriented and impure language features."

It would be cool to see a similar contrast between Data Parallel Haskell (http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell / http://www.youtube.com/watch?v=NWSZ4c9yqW8) and others.

Small quibble: this is not a "white paper," but a research paper at a workshop: http://www.hiperfit.dk/fhpc12.html

CS "Workshops" are still academic in nature, but as opposed to a conference, they encourage papers that present work that is still in progress, or not large enough in scope for a conference paper.

I'm glad to see F# mentioned. All to often it's dismissed in my discussions with friends, because. Net is uncool in general or because they didn't know that F# is officially backed and therefor quite likely here to stay.

Seeing a link here where it is mentioned with/compared to Scala and Haskell is a refreshing change.

I have enough difficulty convincing people in my .NET based company that it's a fully supported language that ships with Visual Studio and the .NET runtime.

I recently had someone complaining that they'd have to install extra software to use it! Took a lot of convincing otherwise.

This story sounds familiar...

Difficult to see why measurements from the benchmarks game n-body task were shown in section 5.2 Baseline, Table 1.

Instead of 5 bodies, 50M iterations - the problem was changed to 16k bodies, 1 iteration.

There doesn't seem to be any basis for comparison.

(The benchmarks game programs weren't even used as starting points for parallelisation.)

Interesting to see the performance difference among implementations and OSs.

Quite interesting, but it seems they used the old Mono gc, when testing F# on linux

I tried to replicate their results (it wasn't really easy to setup, so I only ran few tests) to show the difference when using the SGEN gc, these are my results on my corei7 860 (4 cores + hyperthreading)

F# on Windows8 64bit (it should be .net 4.5)

.\fsharpbench.exe 80000 1 bharr 3

6.94s

F# on Linux (Mono 2.10.8)

mono-sgen Main.exe 80000 1 bharr 3

13.69s

mono Main.exe 80000 1 bharr 3

20.54s

and, by changing the gc's write barrier, you can shave off an half second more:

env MONO_GC_PARAMS="wbarrier=remset" mono-sgen Main.exe 80000 1 bharr 3

13.02s

Linux Scala 2.10M7

scalac-2.10 bh-impure.scala

scala-2.10 Simulation 80000 True 1

5.641 s

Scala 2.9

scalac bh-impure.scala

scala Simulation 80000 True 1

7.676 s

so, F# on Linux is still slower than Scala and F# on Windows, but the situation is not as bad as in the paper (4/5 times slower, or worse): it's in the same ballpark (a little more than 0.5 the speed on Windows) imho: definitely usable (on single core loads it is also much more competitive, from the few lines of F# that I've written)

btw: it seems also that Scala2.10 is quite faster than Scala2.9 :D