Before Haskell took off with parallelism, it was assumed that Haskell would be trivial to run concurrently on cores because majority of Haskell programs were pure, so you could simply run different functions on different cores and string the results together when your done
It turned out that using such a naive method created massive overhead (to the point where it wasn't worth it), and so different concurrent paradigms were introduced into Haskell to provide parallelism (nested data structures, parallel strategies, collections, STM). In I believe almost every case for these algorithms, there is a compromise between ease of implementation vs performance gains.
Haskell is still by far one of the best languages to deal with concurrency/parallelism. In most other conventional languages used today (with are imperative or multi-paradigm), parallelism breaks modularity/abstraction (which is one of the main reasons why most desktop applications/games are still single core, and the few exceptions use parallelism in very trivial cases). This is of course mainly to to deal with state (semaphores/mutex). Although it is possible to program in other languages using 'pure' code, its often very ugly (and in that case you may as well use Haskell)
On Tue, Sep 7, 2010 at 8:37 AM, Johannes Waldmann
<waldmann@imn.htwk-leipzig.de> wrote:
Don Stewart <dons <at>
galois.com> writes:
> Note that DPH is a programming model, but the implementation currently
> targets shared memory multicores (and to some extent GPUs), not
> distributed systems.
but I'd sure want to use ghc-generated code on a (non-distributed) GPU.
I keep telling students and colleagues that functional/declarative code
"automatically" parallelizes, with basically "no extra effort"
from the programmer (because it's all in the compiler) - but I would
feel better with some real code and benchmarks to back that up.
GPU computing via ghc could be a huge marketing opportunity -
if it works, it should be all over the front page of haskell.org?
J.W.