Programming language for functional parallelism: F# vs Haskell [closed]

Question

Functional programming has immutable data structures and no side effect which are inherently suitable for parallel programming. I investigate how to exploit multicore computation in a functional language, and target production code for some numerical applications.

F# has Microsoft behind its back, and its parallel constructs such as PLINQ, TPL, Async Workflow have been well-documented and shown some potentials. However, research about parallelism in Haskell is very active at the moment, and it posseses many nice features which haven't been supported by F# yet:

• Data Parallel Haskell
• par and pseq
• Strategies
• Software Transactional Memory

My question is which language I should choose for functional parallelism? If F# is chosen, are there any pointers to build up what they currently have in Haskell?

UPDATE:

I chose Simon's answer because it brought out some nice discussion about garbage collector, memory allocation and cache miss. I will stick to F#, and I think these answers are helpful for me to study functional parallelism.

Answer 1

If the kind of code you have in mind allocates memory heavily, then you might find that the GHC garbage collector scales better than the .NET garbage collector. There's some anedcodal evidence that the .NET GC becomes a bottleneck when multiple threads are allocating heavily, and this is also a thorn in the side of most Java collectors too. On the other hand we've paid quite a lot of attention to achieving good locality and scalability in the GHC garbage collector - mainly because we have no choice, most idiomatic Haskell code allocates heavily anyway. I have benchmarks that allocate like crazy and keeping scaling beyond 24 cores.

In Haskell note that you get a guarantee of determinism from the type system, which you don't get in F#.

You mentioned Data Parallel Haskell: a cautionary note here, it isn't ready for production use at the present time, although the DPH team are expecting that the forthcoming GHC 7.2.1 release will have a stable DPH implementation.

Answer 2

First of all, I agree with others that there is no objective answer.

However, I think that the idea of functional parallelism is a bit overrated. Surely, you can easily find data dependencies in your program and if you're processing lots of data, you can use some data-parallel library to easily and safely parallelize it. However, this can be done even in C# (using TPL and PLINQ) if you're a bit careful about what you're writing.

The problem is, that most of the programs don't need to be parallelized, because they simply don't do enough CPU-intensive work. For example, F# async solves (I think) more important problem of enabling asynchronous I/O, which is the reason for most "hangs" in connected applications. I think the popularity of Node.js demonstrates this importance quite nicely.

The real value of functional languages is in the expressivity of the language - you can easily define abstractions for your problem, write code in a more succinct way that is easier to understand, reason about and test. You get this in both F# and Haskell.

To answer your specific question about parallelism - I believe that the status of parallelism support in F# is more stable (but then, I'm an F# person). You can choose between async, TPL and (Erlang-inspired) F# agents (which are all quite stable libraries). On the Haskell side, there is still a lot of evolution going on. The most recent work is just few weeks old. I also find it easier to use parallelism in a language with clearly specified evaluation model, but that may be just my personal preference.