

Multicore Programming in Haskell Now - dons
http://donsbot.wordpress.com/2009/09/05/defun-2009-multicore-programming-in-haskell-now/

======
davidw
I'll ask: with Erlang I understand the mechanism it uses for concurrency
fairly well. From a quick glance at these slides, I get the impression that
Haskell would be very good at doing parallel calculations (it's fast), but am
not quite so certain about doing parallel system tasks, like sockets,
something I know Erlang is good at. Care to elaborate?

Do you guys have a fast/small web server, for instance? Something like
mochiweb?

~~~
dons
There's quite a few on Hackage.
[http://hackage.haskell.org/packages/archive/pkg-
list.html#ca...](http://hackage.haskell.org/packages/archive/pkg-
list.html#cat:network)

E.g. salvia: <http://hackage.haskell.org/package/salvia>

The trick is to use lots of Haskell lightweight threads to hide latency (much
as you would with Erlang).

~~~
davidw
Cool, thank you!

If I may ask you another question, how would one install that and start
fooling around with it? I really don't have time, but... my curiosity has been
piqued! (So much for 'discipline', but hey, it's a Sunday).

(BTW, Google is very fast at indexing conversations here - this thread is the
first thing that turns up for "mochiweb vs salvia")

~~~
dons
Super easy:

* one click: install the Haskell Platform: <http://hackage.haskell.org/platform>

* type: cabal install salvia

Another good one is hyena, <http://hackage.haskell.org/package/hyena>

You can get a concurrent web server going in a dozen lines of code or so.

------
gaius
Lots of great stuff happening in the Haskell community at the moment. What is
it they're doing that the OCaml crowd aren't? This is a genuine question, I
want to know so we can do it too...

~~~
silentbicycle
The OCaml community doesn't have anybody who promotes the language with quite
as much gusto as dons, to my knowledge, and its library situation is a bit
messy - there are _nonstandard community replacements for the standard
library_ [1] because Inria is just not going to fix some major warts. It _has_
libraries[2] (and a pretty good library manager[3]), but OCaml has been around
for quite a while and hasn't ever seemed to aquire critical mass. That degree
of blatant fragmentation probably makes people wary.

Haskell seems to be stealing its thunder now. There are numerous "intro to
Haskell" / monad tutorial / etc. articles out there, and the OCaml community
seems very quiet, by comparison. I don't particularly care for Haskell* , but
its designers and users have done a good job of ensuring people hear about it,
and get at least a roughly accurate first impression of what makes it
noteworthy.

* I don't like laziness as a default, I've been burned a couple times by portability issues (and the way that "whatever GHC does right now" has become a de-facto standard means that portability issues are probably not a priority), and it's academia-centric "avoid success at all costs" attitude doesn't sit right with me.
    
    
      [1]: http://code.google.com/p/ocaml-extlib/
      [2]: http://godi.camlcity.org/godi/toc/toc-3.10.html
      [3]: http://projects.camlcity.org/projects/findlib.html/

~~~
ericlavigne
"I've been burned a couple times by portability issues (and the way that
"whatever GHC does right now" has become a de-facto standard means that
portability issues are probably not a priority)"

I am interested in this issue and would love to hear more details. Portability
between different Haskell implementations or portability of GHC to different
operating systems?

~~~
silentbicycle
I should preface this by noting that I haven't looked into the situation
recently, and the problem may have been fixed, but it really soured me on
Haskell. (At a glance, it looks the same, and discussions with a presenter at
a local barcamp implied no real change.) I stopped worrying about it because
I'm quite content with Lua for small personal projects, and OCaml and Erlang
seem to be more my style than Haskell for larger ones.

So, that said: I primarily use OpenBSD and FreeBSD, and bootstrapping recent
versions of GHC from source has been broken for a long time. OpenBSD's current
GHC is 6.6.1, and FreeBSD's is 6.8.x, but (last time I checked) was marked as
broken. While porting language runtimes to OpenBSD can be tricky due to e.g.
its randomized malloc, an open-source language that _doesn't even build from
source on FreeBSD_ probably doesn't place much of a priority on portability.
GHC 6.6.1's ghci segfaults on my openbsd/amd64 system, too.

Just after I got settled with XMonad, GHC updated without a clear plan for
source bootstrapping. I get the impression that a lot of people just use
Debian/Arch/etc., like dons did[1]. (I'm a (somewhat minor) OpenBSD porter, so
I probably care about this more than many people.)

[1]: <http://www.cse.unsw.edu.au/~dons/haskell_openbsd.html> \- He switched to
using Arch in ~2005.

Here's a Hackage bug ticket, closed after a year and a half with the note that
they're probably just not going to support building that way
anymore:(<http://hackage.haskell.org/trac/ghc/ticket/1346>). It's not hard to
find griping about the situation on the openbsd-ports list.

While GHC is just one compiler (and I've put some time into helping with
updating Common Lisp and Scheme ports in the past, due to similar issues),
Haskell programmers seem to assume a recent version of GHC and its extensions,
making "whatever GHC does" a de-facto standard. That rules it out for me
entirely, and I wonder if anybody else feels the same.

~~~
dons
I switched to Arch in 2007 because I needed multicore SMP runtime support.
OpenBSD was only running userland apps on 1 core at the time.

------
amix
It looks like the speed gains are rather small and optimizations complex to
debug even for small programs. And the "implicit parallelism" is really an
explicit one since you have to annotate/hint what could be run in parallel.

~~~
dons
> speed gains are rather small

How did you get that impression? Depending on the problem, there are programs
in that talk that scale linearly with the available cores.

Secondly, there are two forms of implicit parallelism presented:

* "semi implicit parallelism", via annotations. no locks, synchronization or communication required * "data parallelism", a subset of the language that can be auto-parallelized.

Or did I misunderstand you?

~~~
amix
Slide 34 where you find out that the improvement was only a little better.
03.hs is a fairly simple program and I would guess that one would run into a
lot of these problems developing "real programs".

I would prefer if the compiler / runtime system were smart enough to figure
out where parallelism could be applied - - and I would had guessed that this
would be a lot easier in Haskell since there are no side effects. Are there
anyone playing with the idea of JIT parallelism (i.e. apply parallelism while
the program is running)?

