[Haskell-cafe] Re: parallel and distributed haskell?
On Dec 16, 8:21 pm, Scott A. Waterman tswater...@gmail.com wrote: Can anyone involved give a quick overview (or pointers to one)? It would be good to hear what directions people are taking, and why, and where it's going. Personally, I'd love to know the current thinking on a variety of subjects: * erlang-like port/actor implementations v. more implicit constructs You may also take a look at http://hackage.haskell.org/package/Holumbus-Distribution or http://holumbus.fh-wedel.de/trac/wiki/Distribution The researchers involved are especially refering to Erlang (and Oz) as an inspirational source for the distribution technology and mechanism used. Johann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: parallel and distributed haskell?
Please note: We have a version of GUM in which PVM has been replaced by direct network communication. However, this project has been idle since the appearance of GHC-6, and I have not been able to get a binary of the parallel version (which is based on GHC-5) to compile itself. Murray Gross Brooklyn College, City University of New York On Thu, 17 Dec 2009, Simon Marlow wrote: On 16/12/2009 19:21, Scott A. Waterman wrote: It looks like there was a recent hackathon focusing on implementing distributed haskell. http://hackage.haskell.org/trac/ghc/wiki/HackPar I feel there is quite a bit of latent interest in the subject here, but relatively little active development (compared to erlang, clojure, etc.) Can anyone involved give a quick overview (or pointers to one)? It would be good to hear what directions people are taking, and why, and where it's going. The main directions are: GUM, which was one of the first parallel implementations of Haskell many years ago [1]. The programming API is the same as GHC has: par/pseq and strategies (indeed this API was invented in the context of GUM, we just re-used it in GHC). GUM uses PVM message passing to implement a distributed heap, and can run on clusters of machines or a multicore, or a combination of the two. GUM has in the past been integrated with GHC, but has sufferred from a lack of development effort so has rotted in recent years. Efforts are now underway to get it working with GHC HEAD again. Eden [2] also uses PVM, but does not have a distributed heap. It's implementation is much simpler, and the API is rather more explicit than par/seq and strategies. Eden has been tracking GHC more closely than GUM, but it's still a research project and there's little effort available to make releases. Neither of these are really what you'd call Distributed Haskell, they are implementations of parallel variants of Haskell running on distributed hardware. There was a Distributed Haskell project, but it is not active at the moment [3]. Cheers, Simon [1] GUM: a portable parallel implementation of Haskell http://www.macs.hw.ac.uk/~dsg/gph/papers/abstracts/gum.html [2] Parallel functional programming in Eden Journal of Functional Programming (2005), 15 [3] http://www.macs.hw.ac.uk/~dsg/gdh/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: parallel and distributed haskell?
On 16/12/2009 19:21, Scott A. Waterman wrote: It looks like there was a recent hackathon focusing on implementing distributed haskell. http://hackage.haskell.org/trac/ghc/wiki/HackPar I feel there is quite a bit of latent interest in the subject here, but relatively little active development (compared to erlang, clojure, etc.) Can anyone involved give a quick overview (or pointers to one)? It would be good to hear what directions people are taking, and why, and where it's going. The main directions are: GUM, which was one of the first parallel implementations of Haskell many years ago [1]. The programming API is the same as GHC has: par/pseq and strategies (indeed this API was invented in the context of GUM, we just re-used it in GHC). GUM uses PVM message passing to implement a distributed heap, and can run on clusters of machines or a multicore, or a combination of the two. GUM has in the past been integrated with GHC, but has sufferred from a lack of development effort so has rotted in recent years. Efforts are now underway to get it working with GHC HEAD again. Eden [2] also uses PVM, but does not have a distributed heap. It's implementation is much simpler, and the API is rather more explicit than par/seq and strategies. Eden has been tracking GHC more closely than GUM, but it's still a research project and there's little effort available to make releases. Neither of these are really what you'd call Distributed Haskell, they are implementations of parallel variants of Haskell running on distributed hardware. There was a Distributed Haskell project, but it is not active at the moment [3]. Cheers, Simon [1] GUM: a portable parallel implementation of Haskell http://www.macs.hw.ac.uk/~dsg/gph/papers/abstracts/gum.html [2] Parallel functional programming in Eden Journal of Functional Programming (2005), 15 [3] http://www.macs.hw.ac.uk/~dsg/gdh/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: parallel and distributed haskell?
On Dec 16, 8:21 pm, Scott A. Waterman tswater...@gmail.com wrote: It looks like there was a recent hackathon focusing on implementing distributed haskell. http://hackage.haskell.org/trac/ghc/wiki/HackPar I feel there is quite a bit of latent interest in the subject here, but relatively little active development (compared to erlang, clojure, etc.) With cloud services on the rise, profound distribution support will be vital in the future. Fully ack. Can anyone involved give a quick overview (or pointers to one)? It would be good to hear what directions people are taking, and why, and where it's going. Personally, I'd love to know the current thinking on a variety of subjects: * erlang-like port/actor implementations v. more implicit constructs * serialization * node failure/error handling There has been some discussion lately on that topic.There are two limitations: - Exceptions can only be caught in impure code - The lack of an agreed model for stack traces, i.e. where and why an error / exception occured (I blur the distinction here) This is only about error/exception handling. I would assume that a node failure is sthg. which should be handled by a supervising process. * grid compatibility v. various ad-hoc cluster approaches. I assume you know http://www.haskell.org/haskellwiki/Applications_and_libraries/Concurrency_and_parallelism#Data_Parallel_Haskell There are libraries for actors and the the concurrency-library should support messages comparable to that of Erlang. Clearly, supporting applications (e.g. to monitor running processes) are missing. While e.g. Erlang supports only one interaction pattern between processes, it was natural to develop a solid framework and supporting tools around that concept. AFAIK Haskell is exploring numerous ways to handle that challenge (see the link above),that's wy there is no standard way to handle concurrency and only very limited tools support for monitoring. Actually, are there any? Anyone actively looking at this kind of question who would want to talk about it? Well, Christmas is approaching. I wrote some simple Erlang style distributed toy applications and found the message passing / actor approach dead simple and effective. Would be nice if this model would be fully supported by eg. GHC. So add me to the wish-list ;) Thanks, --ts ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
