Hacker Newsnew | comments | ask | jobs | submitlogin
White Paper: Haskell vs. F# vs. Scala [pdf] [scribd] (hw.ac.uk)
78 points by Toshio 585 days ago | comments

thirsteh 585 days ago | link

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.


scott_s 585 days ago | link

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 585 days ago | link

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 585 days ago | link

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 584 days ago | link

This story sounds familiar...


igouy 585 days ago | link

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


pjmlp 585 days ago | link

Interesting to see the performance difference among implementations and OSs.


b3rdario 583 days ago | link

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


F# on Linux (Mono 2.10.8)

mono-sgen Main.exe 80000 1 bharr 3


mono Main.exe 80000 1 bharr 3


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


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


Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library