

White Paper: Haskell vs. F# vs. Scala [pdf] - Toshio
http://www.macs.hw.ac.uk/~dsg/gph/papers/pdf/fhpc12.pdf

======
thirsteh
tl;dr: "we remark that all 3 languages provide easy-to-use, high-level and
efﬁcient support for parallelism. Haskell has an edge in its rich libraries
and aggressive optimisation. Through laziness, top-level parallelism can be
speciﬁed 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.

------
scott_s
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.

------
darklajid
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.

~~~
sitharus
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.

~~~
jamiepenney
This story sounds familiar...

------
igouy
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.)

------
b3rdario
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

------
pjmlp
Interesting to see the performance difference among implementations and OSs.

