Multicore Programming in Haskell Now | Hacker News Reader

Multicore Programming in Haskell Now

donsbot.wordpress.com

58 pointsdons24 comments

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?

There's quite a few on Hackage. http://hackage.haskell.org/packages/archive/pkg-list.html#ca...

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

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

Cabal has a command-line tool for downloading and installing packages (http://hackage.haskell.org/trac/hackage/wiki/CabalInstall). A package for it should exist for it on your platform, maybe called "cabal-install". Once you've got it, running "sudo cabal install salvia" should do the trick.

(Failing that, you can wade through dependency hell and install salvia, and its dependencies, yourself. All Cabal packages have a Setup.hs or Setup.lhs file that controls building it. Run "runhaskell Setup.hs build" then "runhaskell Setup.hs install" (or similar) in each source tree.)

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.

Also, can anyone point me in the direction of how to do Erlang style distributed messaging? Is there a standard solution for inter-machine RPC in Haskell implementations?

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

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/

There's also Jane Street Core http://ocaml.janestcapital.com/?q=node/13

What's also weird is that OCaml doesn't even have a big following in France, the French are well-known for championing their own ideas in the face of whatever Les Rosbifs are doing.

I get the impression that it may have been more popular several years ago - OCaml, Caml Light, and predecessors have been around for a rather long time, and have been used in education. It has a long, parallel history to SML.

I'm not sure about the above because I can't read French, but I remember reading it somewhere relatively 'official'. (Perhaps in the translated O'Reilly book?) Either way, having half the stuff written about your language only available in French is probably not a strong life sign.

"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?

In the early years of Haskell there were a number of implementations experimenting with different things, and eventually the surviving ones converged on a standard -- Haskell 98.

Since then (especially in the last 5 years), the GHC community has been regularly releasing all sorts of shiny new toys -- obviously introducing features unsupported by other implementations, but also frequently breaking compatibility with their own previous implementations. OS portability has not been much of an issue.

Haskell Prime is an effort underway by the GHC guys to not only define a new set of standard libraries, but to make Python3000-style purposefully incompatible changes to the core language. This is hoped to become a new standard, Haskell 2010.

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.

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.

I, for one, adore the "avoid success at all costs" attitude

The trappings of success for programming languages are pain and suffering, having your community inundated with incurious idiots, losing the ability to do anything new and cool because you have to maintain stability for the horde.

Witness Alan Kay's experience with Smalltalk -- he was forced to fork himself and start over every time he succeeded in getting users.

It's a great stance for a language that focusing primarily on research and innovation, but it does put a damper on getting things done sometimes. Some stability and concessions to practicality go a long way.

I think that having a clean break at major revisions (e.g. Python 3, Lua 4.0 to Lua 5.0) and cleaning up cruft is probably a reasonable approach, as long as it's handled carefully and half the community doesn't stay with the old version. (It was easier with Lua because it's so small, and usually embedded in something else.)

Fundamentally, I think it is the cathedral (INRIA) vs the bazaar (Haskell.org open source) leading to long term efficiencies for the Haskell community.

Also, the OCaml community seems more fragmented, so its harder to organize group efforts. Haskell hackathons are happening every 4 months or so, in the US and Europe (we've had 9 in 3 years). I don't know that the OCaml open source community has held any similar kind of event.

OCaml is a well designed, well implemented language.

Unfortunately, it sits at an unstable point in language design space. If you like it because it's practical, there are other languages (C++ and Java) that are even more practical. If you like it because it's functional, there are other languages (Haskell, Erlang) that are even more functional. If you like it for being ML with objects, then you would probably like F# even better. And so forth.

The result is that there just aren't that many people who like Ocaml more than another language.

I think this idea of "unstable points in the design space" is quite insightful. Hmm. Have to think about this some more.

I was working on a project in Fortran. I recommended OCaml, saying that it had all the same capabilities as Fortran (high performance, portability, compiling to native code, support for similar programming style) but also had additional features that would make me more productive. OCaml's position in language design space was perfect for a project in which a functional programmer would be doing most of the work, but a client felt more comfortable with something Fortran-like, in case he ever had to maintain it himself.

If I were making the decision completely on my own, I would prefer Haskell, but in-between languages like OCaml can make good compromise options. I also learned OCaml before Haskell, and consider it to have been a good stepping stone.

OCaml works well as a multiparadigm language. While it has some implementation quirks* , I like that its design doesn't force a pure functional approach. There's a quote in the French O'Reilly book, something like "Write your code in the style that is most natural, and give it a functional interface.". It seems like a good summary of the direction the language design points. (I just think there's a smaller, cleaner language buried inside OCaml...) Being "in between" can sometimes be a major strength.

* In particular, adding typeclasses would nicely resolve several minor annoyances with the languags.

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.

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

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

Reply on news.ycombinator.com