Re: FW: [Haskell] parallel seq
Chad, I was thinking about the dynamic behavior of par, and there's something that's a little confusing to me. Am I right in understanding that (x `par` y) evaluates to y, and may or may not evaluate x along the way? The reason that par doesn't necessarily evaluate it's 1st argument is that typical parallel Haskell programs contain vast amounts of potential parallelism. So rather than create a relatively heavyweight thread and be forced to administer it, e.g. schedule it for every possible expression that could be evaluated in parallel, the expression is 'sparked', i.e. a lightweight action that simply notes that the expression *could* be evaluated in parallel. I think it would be easier to reason about if we knew that x would be evaluated, either by a newly-spawned thread or by the parent thread. Yes, although we usually reason by saying trhat the 'potential parallelism' in two expressions is the same, i.e. making the assumption that all sparked expressions become threads. If I'm understanding this correctly, this could be done by defining x `pSeq` y = x `par` y `seq` x `seq` y This seems plausible. All the best, Phil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scherrer, Chad Sent: 25 April 2006 21:35 To: haskell@haskell.org Subject: [Haskell] parallel seq I was thinking about the dynamic behavior of par, and there's something that's a little confusing to me. Am I right in understanding that (x `par` y) evaluates to y, and may or may not evaluate x along the way? I think it would be easier to reason about if we knew that x would be evaluated, either by a newly-spawned thread or by the parent thread. If I'm understanding this correctly, this could be done by defining x `pSeq` y = x `par` y `seq` x `seq` y (seq has higher precedence than par) When (x `pSeq` y) is evaluated, x may or may not be evaluated by a new thread. The parent thread continues along evaluating y. Then the parent makes sure x was evaluated before finally returning y. I've not seen this approach used before -- Is there something I'm missing that makes using pSeq as above just silly? Thanks! Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory Time flies like an arrow; fruit flies like a banana. -- Groucho Marx ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Gph] [Fwd: Re: [Haskell] Implicit parallel functional programming]
Satnam, Does anyone know of any other work on implicitly parallelizing functional programs for fine grain parallel execution? The skeletons community implicitly replace higher-order functions with parallel implementations: http://homepages.inf.ed.ac.uk/mic/Skeletons/ There's an excellent survey of parallel FP in Research Directions in Parallel Functional Programming, Hammond K. and Michaelson G. (Eds) Springer Verlag ISBN 1-85233-092-9 (2000). http://www-fp.dcs.st-and.ac.uk/pfpbook/ there is interesting work with pH at MIT. Is anyone working on pH at the moment? Phil Original Message Subject: Re: [Haskell] Implicit parallel functional programming From:[EMAIL PROTECTED] Date:Wed, January 19, 2005 4:36 am To: Satnam Singh [EMAIL PROTECTED] Cc: Haskell@haskell.org -- On Tue, 18 Jan 2005, Satnam Singh wrote: I'm trying to find out about existing work on implicit parallel functional programming. I see that the Glasgow Haskell compiler has a parallel mode which can be used with PVM and there is interesting work with pH at MIT. Does anyone know of any other work on implicitly parallelizing functional programs for fine grain parallel execution? The emergence of multi-core processors makes me think that we should look at implicit parallel functional programming in a new light. At Brooklyn College, we are working on a version of Parallel Haskell that does not require PVM. Instead, we use Internet protocols and the Mosix patches to Linux. Murray Gross Brooklyn College, CUNY Metis Project ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Gph mailing list [EMAIL PROTECTED] http://www.macs.hw.ac.uk/mailman/listinfo.cgi/gph -- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Deadline for JFP Special Issue on Parallel FP Postponed
The submission deadline for the JFP special issue on High-Performance Parallel Programming has been postponed to 31st October 2003, see http://www.macs.hw.ac.uk/~trinder/jfpCFP.htm Phil -- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFP: JFP Special Issue on Parallel Functional Programming
Journal of Functional Programming Special Issue on Functional Approaches to High-Performance Parallel Programming Guest editor: Phil Trinder Submission deadine: 26th September 2003 Web Page: http://www.cee.hw.ac.uk/~trinder/jfpCFP.htm High-performance parallel programs are hard to write. For a long time it has been recognised that ideas and approaches drawn from functional programming may be particularly applicable in this area because * Concurrent stateless computations are much easier to coordinate. * High-level coordination reduces programming effort. * Declarative notations are amenable to reasoning, i.e. to transformation, derivation and analysis. After a long gestation, this potential is now finally being realised in practice. Declarative techniques are being used to construct significant parallel and high-throughput systems, e.g. real-time image analysis and high-end telephone exchanges. Many production systems use conventional imperative technologies in a declarative way, e.g. coordinating legacy Fortran code. Furthermore, the recent emergence of computational Grids pose new challenges that the functional paradigm is well-placed to address: grids offer enormous amounts of computing power, but require sophisticated and dynamic management that is hard to provide in a low-level paradigm. A special issue of the Journal of Functional Programming will be devoted to functional approaches to high-performance parallel programming. Full-length, archival-quality submissions are solicited on topics including but not limited to the following. * Skeletons and higher-order parallel program construction * Parallel Program development methodologies, including derivation and optimisation. * Parallel program modelling, including static analyses to predict properties (e.g. cost models) and dynamic analyses to profile execution properties. * Parallel functional languages, including design, semantics, implementation and performance. * High-performance functional and skeleton applications. * Adaption of high-performance functional technologies for emerging architectures such as the Grid. Papers covering a fusion of functional and more conventional technologies are encouraged, in addition to papers on purely functional technologies. Submissions should be sent to the guest editor Phil Trinder ([EMAIL PROTECTED]), with a copy to Jenny Parker ([EMAIL PROTECTED]). Submitted articles should be sent in PDF or Postscript format, preferably gzipped. In addition please send as plain text: title, abstract, and contact information. The submission deadline is 26th September 2003, and for other submission details, please consult an issue of the Journal of Functional Programming or see the Journal's web pages. -- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Q: GHC, Parallel libraries
Jan, Simon's correct: the latest publicly-available version of Glasgow parallel Haskell is 4.06. We have a development version based on 5.02 that we're using locally and hope to merge it back into the main GHC repository soon - approximately a month from now. Alway happy to chat: When do you need it, and what parallel platform will you use? We get good results on x86 Linux Beowulf clusters, and Sun SMPs. Phil On 15 Oct 2002 11:46:25 +0200 Jan Kybic [EMAIL PROTECTED] wrote: Hello, I would like to parallelize my program in Haskell but I have difficulties getting started. I would therefore appreciate any help or pointers. I am using ghc-5.04 on i386 Linux. I installed from a binary bundle on the ghc website. I thought I would just compile with --parallel and I would get acess to the 'par' primitive. But no, it seems that the parallel libraries are missing on my system. If I understood correctly, they are files with _mp in their name, right? I looked on the web for a precompiled binary version of those libraries, in vain. I found the GUM web page but it seems to be much outdated, based on the ghc-4.06. Is there any more recent version available? Then, I tried to get the ghc-5.04.1 source distribution and compile it from source. I found the building guide on the ghc site but it talks only about fptools in general and does not mention the ghc specificities. The build (./configure --prefix=$HOME ; make) fails. First of all it could not find 'readline', which I solved by some config.mk hacking, now it fails with: Main.hs: can't locate import `Exception' apparently because the binary bundle directory hierarchy is different from what the Makefile expects. I also tried to build only the libraries. It first failed with not being able to find the ghc-pkg-inplace, after changing this to the installed version it fails with Reason: No such file or directory File: ../../ghc/driver/package.conf Any help appreciated. Thanks, Jan -- - Jan Kybic [EMAIL PROTECTED] Odyssee, INRIA, Sophia-Antipolis, France or [EMAIL PROTECTED],tel. work +33 492 38 7589, fax 7845 http://kybic.host.sk/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GPH: Re: GpH Mosix
Robert, Thanks for this. Phil On Wed, 11 Sep 2002 15:20:03 +0100 (BST) Robert F. Pointon [EMAIL PROTECTED] wrote: On Wed, 28 Aug 2002 [EMAIL PROTECTED] wrote: On Wed, Aug 28, 2002 at 10:46:34AM +0100, Phil Trinder wrote: Paul, The GdH implementation is currently used here, and is basically in beta-release form. If you would use it we could wrap up a and X86/Linux version for you. That will be very sweet! I'd love to play with this thing ;-) Please post the link when it is ready. A binary snapshot of GdH has been available since February, see the bottom of the GdH page: http://www.cee.hw.ac.uk/~dsg/gdh Note: best to install and test GpH first to verify that you have the required libraries... see ~dsg/gph cheers, ___ ][_) | +44 (0)131 451 3328 ]| \obert Pointon | http://www.cee.hw.ac.uk/~rpointon --+-- Dept of Computing Electrical Eng. Heriot-Watt University Riccarton Edinburgh, EH14 4AS ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GpH Mosix
Paul, The GdH implementation is currently used here, and is basically in beta-release form. If you would use it we could wrap up a and X86/Linux version for you. The GUM implementation of GpH and GdH uses very simple communication (mainly point to point, with a single barrier synchronisation, and the communication is restricted to just 3 C modules. As a result it can be readily ported to new communications libraries, e.g. MPI and CMMP (bespoke CM5 library) versions exist. Then what will Mosix provide when you can have a PVM cluster without Mosix running the same thing? Don't know a lot about Mosix, but if the PVM calls in the 3 GUM communications modules can be replaced with Mosix shared-memory routines that would give a low effort port of GUM to a Mosix cluster. I'd expect Mosix communication to be *much* faster than PVM: it's so generic that it absorbs a lot of time, e.g. probing for a message takes 2000 machine cycles. For small numers of processors a higher-performance implementation could be constructed by adapting the runtime system to effectively use the shared memory, but IIRC Simon Marlowe found there were problems with memory contention with more processors. Phil On Tue, 20 Aug 2002 21:17:28 +0800 [EMAIL PROTECTED] wrote: Speaking of GpH, I wonder how is GdH coming along? It seems that the installation instruction on http://www.cee.hw.ac.uk/~dsg/gdh/ is still incomplete... As far as I know, Mosix has nothing to do with PVM, so am I right to say that GpH still needs PVM even you use it on a Mosix cluster? Then what will Mosix provide when you can have a PVM cluster without Mosix running the same thing? Regards, .paul. On Tue, Aug 20, 2002 at 12:09:28PM +0100, Phil Trinder wrote: Murray, There are several parallel Haskell implementations: a survey of them has just appeared in Journal of Func. Prog Vols 45 (July Sept 2002). Implementations are available for o Eden http://www.mathematik.uni-marburg.de/inf/eden/ o GpH http://www.cee.hw.ac.uk/~dsg/gph/ My group works on Glasgow parallel Haskell (GpH) which extends Haskell 98 with a parallel composition combinator. As Simon said the main implemntation, GUM, buys portability using the relatively slow PVM communications library. This doesn't matter so much on distributed memory machines, and we've recently achieved some quite respectable results SunServer shared-memory machines. Simon Marlowe developed an alternative SMP implementation of GpH a couple of years ago that may be more suitable for a Mosix platform, but I'm not sure of the status of that implementation now. Phil On Mon, 19 Aug 2002 18:04:44 +0100 Simon Peyton-Jones [EMAIL PROTECTED] wrote: Hi Murray I'm catching up with my email backlog, but I didn't see a reply to your message, so I thought I'd reply. The parallel-Haskell crew are at http://www.cee.hw.ac.uk/~dsg/gph/ There's a mailing list that I'm ccing. GHC can be built to run on a shared-memory multiprocessor, but we have not built and tested that for some time. Untrue - both Eden and GpH are currently used on SunServer SMPs. GPH is aimed more at distributed-memory machines, and has quite a bit more code layered on top of GHC. Details on the GPH page above. Let me know if I can help. It'd be great to get some more parallel-Haskell stuff going. Simon | A group of us at Brooklyn College (City University of New | York) are in the latter stages of setting up a Mosix cluster | that we would like to use for research on, among other | things, parallel execution of Haskell code and run-time | optimization of both automatic and programmed parallelization. | | I would greatly appreciate hearing from anyone who can | provide advice on | an appropriate bibliography on the language implementation and past | work in this area (other than the code in the Haskell compilers and | libraries, of course), approaches, ongoing work, etc. | | Also, I would be most interested in hearing from anyone | interested in joining our effort (no problems with remote | access to the cluster by way of SSH), or making arrangements | for cooperation in research in this area, although, of | course, access to our equipment will be subject to approval | from higher authorities (however, note that I really don't | expect difficulty here, since our administration has already | shown considerable interest in supporting the project). | | Replies to the list will be read, but those who wish may mail | me directly at [EMAIL PROTECTED] | | Thanks in advance for any replies. | | Murray Gross | Adj. Lecturer, Brooklyn College, | City University of New York | | | | ___ | Haskell mailing list | [EMAIL PROTECTED] http://www.haskell.org
Re: A: Evaluation order, ghc versus hugs, lazy vs. strict
Dear All, Hal's comments on the use of Evaluation Strategies for controlling strictness are substantially right, and they are used this way in Eden, a parallel Haskell. In Glasgow parallel Haskell(GpH) we use them to control parallel evaluation as well. The key reference is Algorithm + Strategy = Parallelism, Journal of Functional Programming, 8(1):23--60, January 1998. http://www.cee.hw.ac.uk/~dsg/gph/papers/ Highlights are as follows. There are three basic strategies: r0, rwhnf, rnf :: Strategy a r0 - does no evaluation, rwhnf - reduces it's argument to Weak Head Normal Form (WHNF). Hal defines this as stratWHNF), and rnf - reduces it's argument to normal form (i.e. containing no redexes). It's defined in a class similar to the Eval class Strategies can be composed, e.g. seqList applies a strategy to every element of a list: seqList :: Strategy a - Strategy [a] seqList s [] = () seqList s (x:xs) = s x 'seq' (seqList s xs) so seqList r0 :: Stratgy [a]- evaluates just the spine of a list seqList rwnf :: Strategy [a] - evaluates every element to WHNF seqList (seqList r0) :: Strategy [[a]] - evaluates just spines of every sublist in a list of lists Analogous parallel strategies, like parList, also exist. The Strategies.lhs module is distributed with GHC (since version 0.29), so simply 'import Strategies' if you want to play. HTH Phil On Fri, 23 Aug 2002 05:10:05 -0700 (PDT) Hal Daume III [EMAIL PROTECTED] wrote: I think there's more to strategies than this. They are not necessarily related to parallel programming and can be used for tuning (in the seq sense) sequential (perhaps non-parallel would be a better word) programs. The type of strategies is: type Strategy a = a - () for example, a strategy which reduces its argument to weak head normal form could be given by: stratWHNF x = x `seq` () We define a funciton 'using' which uses strategies to do a computation: v `using` s = s x `seq` x These are used in parallel programming something like: fib 0 = 1 fib 1 = 1 fib n = a + b `using` strategy where a = fib (n-1) b = fib (n-2) strategy result = a `par` b `par` result This clearly separates the computation a+b from the way it is evaluated a in parallel to b in parallel to the result (i.e., a+b). But this can of course be used for sequential programming, too, simply by using seq instead of par in the above example. This enables you to write clean code (your functions stay the same, except they are appended with `using` strategy), but you can control more precisely when things get reduced. - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On 23 Aug 2002, Ketil Z. Malde wrote: Jan Kybic [EMAIL PROTECTED] writes: What are GUM and Strategies? Could you provide any links? http://www.cee.hw.ac.uk/~dsg/gph/docs/Gentle-GPH/sec-gph.html GUM is an implementation of GPH (a parallel Haskell) that runs on top of PVM. Strategies are about making sure parallel threads actually do the work they're intended to before returning control to the main thread; in other words, ensuring sufficient strictness. Or something like that. Grain of salt as applicable, I'm not using any of this yet. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GpH/GdH Parallel Distributed Haskell Research
Prompted by Simon PJ, here's a bulletin on GpH/GdH parallel and distributed Haskell research at Heriot-Watt and St Andrews Universities. Kevin Hammond has recently had an EPSRC project funded to use GpH as parallel coordination layer for large GAP (symbolic algebra) computations. We're also part of an EU framework VI Network bid on parallel symbolic computation. Jan Nystrom will join us at Heriot-Watt in November from Upsala as the RA on a new EPSRC/Motorola Research Labs project investigating Erlang GdH for distributed telecoms applications. We're maintaining collaboration with the Eden (another parallel Haskell) groups at Marburg in Germany and Madrid, funded by Britsh Council ARC and Accion Integradas respectively. Hans Wolfgang Loidl has just returned to Germany after completing his 3-year Post-Doc. He's been working on improving the architecture independence of GpH, and participates part time. There are 5 research students working on GpH and GdH: - Robert Pointon (Finishing PhD) has designed implemented GdH and is now evaluating it. - Alvaro Rebon (Finishing PhD) is implementing the granularity anaylsis proposed in Hans Wolfgang Loidl's thesis as a free standing tool. - Andre Du Bois (Entering 2nd year PhD) is designing and planning to construct a mobile Haskell by extending GdH. - Abyd Al Zain (Starting PhD) is designing and planning to construct a GRID implementation for GpH on networks of HPCs. The key problems are to extend GpH's existing dynamic adaption mechanisms to the hierarchical, heterogeneous and shared architecture. - Mustafa Aswad (Completing MPhil) is investigating developing GpH programs for multiple architectures, based on a GpH gene-sequence alignment program. More details including a raft of publications is available from http://www.cee.hw.ac.uk/~dsg/gph/ http://www.cee.hw.ac.uk/~dsg/gdh/ http://haskell.cs.yale.edu/communities/ Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GPH: RE: Concurrency and Haskell
Murray, There are several parallel Haskell implementations: a survey of them has just appeared in Journal of Func. Prog Vols 45 (July Sept 2002). Implementations are available for o Eden http://www.mathematik.uni-marburg.de/inf/eden/ o GpH http://www.cee.hw.ac.uk/~dsg/gph/ My group works on Glasgow parallel Haskell (GpH) which extends Haskell 98 with a parallel composition combinator. As Simon said the main implemntation, GUM, buys portability using the relatively slow PVM communications library. This doesn't matter so much on distributed memory machines, and we've recently achieved some quite respectable results SunServer shared-memory machines. Simon Marlowe developed an alternative SMP implementation of GpH a couple of years ago that may be more suitable for a Mosix platform, but I'm not sure of the status of that implementation now. Phil On Mon, 19 Aug 2002 18:04:44 +0100 Simon Peyton-Jones [EMAIL PROTECTED] wrote: Hi Murray I'm catching up with my email backlog, but I didn't see a reply to your message, so I thought I'd reply. The parallel-Haskell crew are at http://www.cee.hw.ac.uk/~dsg/gph/ There's a mailing list that I'm ccing. GHC can be built to run on a shared-memory multiprocessor, but we have not built and tested that for some time. Untrue - both Eden and GpH are currently used on SunServer SMPs. GPH is aimed more at distributed-memory machines, and has quite a bit more code layered on top of GHC. Details on the GPH page above. Let me know if I can help. It'd be great to get some more parallel-Haskell stuff going. Simon | A group of us at Brooklyn College (City University of New | York) are in the latter stages of setting up a Mosix cluster | that we would like to use for research on, among other | things, parallel execution of Haskell code and run-time | optimization of both automatic and programmed parallelization. | | I would greatly appreciate hearing from anyone who can | provide advice on | an appropriate bibliography on the language implementation and past | work in this area (other than the code in the Haskell compilers and | libraries, of course), approaches, ongoing work, etc. | | Also, I would be most interested in hearing from anyone | interested in joining our effort (no problems with remote | access to the cluster by way of SSH), or making arrangements | for cooperation in research in this area, although, of | course, access to our equipment will be subject to approval | from higher authorities (however, note that I really don't | expect difficulty here, since our administration has already | shown considerable interest in supporting the project). | | Replies to the list will be read, but those who wish may mail | me directly at [EMAIL PROTECTED] | | Thanks in advance for any replies. | | Murray Gross | Adj. Lecturer, Brooklyn College, | City University of New York | | | | ___ | Haskell mailing list | [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell | -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell/Erlang Research Position
Research Associate in Haskell/Erlang for Distributed Telecommunications £17,278-£26,229 p.a. Applications are invited for a three year Research Associate position at Heriot-Watt University to work with Dr Phil Trinder on an EPSRC funded project entitled High-Level Techniques for Distributed Telecommunications Software. The project is a collaboration with Motorola UK Research Labs and aims to evaluate high-level distributed programming techniques for constructing realistic telecommunications software. Applications are welcomed from candidates with a doctorate or a very good first degree in Computing or cognate discipline; a successful candidate without a PhD will have the opportunity of registering for one. Applicants should have good written and verbal communication skills and be able to demonstrate a strong programming ability: experience with distribution and the Haskell or Erlang programming languages is desirable. Likewise a research background, and familiarity with the telecommunications sector are desirable. For application details please contact the Personnel Office, Heriot-Watt University, Edinburgh, EH14 4AS, tel/fax: 0131 451 3475 (24 hours) quoting Ref 66/02/J. The closing date is Friday 19th April 2002. Informal enquires can be directed to Phil Trinder tel: +44 131 451 3435, or e-mail: [EMAIL PROTECTED] More details of the project and further particulars for the position can be found at: http://www.cee.hw.ac.uk/~dsg/telecoms/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haskell/Erlang Research Position
Research Associate in Haskell/Erlang for Distributed Telecommunications £17,278-£26,229 p.a. Applications are invited for a three year Research Associate position at Heriot-Watt University to work with Dr Phil Trinder on an EPSRC funded project entitled High-Level Techniques for Distributed Telecommunications Software. The project is a collaboration with Motorola UK Research Labs and aims to evaluate high-level distributed programming techniques for constructing realistic telecommunications software. Applications are welcomed from candidates with a doctorate or a very good first degree in Computing or cognate discipline; a successful candidate without a PhD will have the opportunity of registering for one. Applicants should have good written and verbal communication skills and be able to demonstrate a strong programming ability: experience with distribution and the Haskell or Erlang programming languages is desirable. Likewise a research background, and familiarity with the telecommunications sector are desirable. For application details please contact the Personnel Office, Heriot-Watt University, Edinburgh, EH14 4AS, tel/fax: 0131 451 3475 (24 hours) quoting Ref 66/02/J. The closing date is Friday 19th April 2002. Informal enquires can be directed to Phil Trinder tel: +44 131 451 3435, or e-mail: [EMAIL PROTECTED] More details of the project and further particulars for the position can be found at: http://www.cee.hw.ac.uk/~dsg/telecoms/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: question about concurrency implementation
Dean, Alastair Reid wrote: Just to be sure we agree on terminology: some people like to distinguish between parallelism and concurrency. Parallelism is a way of going faster but doesn't change your programming model. Implemented correctly, a parallel implementation yields the same results as a sequential implementation - it just runs faster. (This is ignoring the effects of interaction with the outside world, of course - since that can also affect determinism.) Parallel Haskell adds par and friends (operations which have no effect on the semantics of your program). Concurrency changes your programming model. A concurrent program is allowed to give different results and interesting interactions (including race conditions) between threads. A concurrent program may run on a single processor. Concurrent Haskell adds forkIO, killThread, MVars, etc (operations which affect not just the semantics of your program but also the way the semantics are defined). We distinguish between parallel, concurrent and distributed depending on the number of processors and whether threads are *stateful*, i.e. access stateful objects like Mvars or Files, or *stateless*. That is: Sequential, e.g. Haskell 98: 1 PE, 1 Stateful thread, 0 stateless threads Concurrent, e.g. Concurrent Haskell: 1 PE, N Stateful thread, 0 stateless threads Parallel, e.g. GpH: N PEs, 1 Stateful thread, N stateless threads Distributed, e.g. GdH: N PEs, N Stateful thread, N stateless threads In fact these languages form an inclusion hierarchy, e.g. GdH is a superset of both GpH and Concurrent Haskell: GdH / \ GpH Conc. Haskell \ / Haskell 98 Dean Herington wrote: I've asked these questions in order to convince myself that multiple threads can (and will) cooperate in lazily evaluating a value they share, without need for any special programming. In particular, I plan to have multiple threads share values whose computations involve uses of `unsafePerformIO` (the safety of which my application's usage pattern guarantees). The key issue is whether the 'values' are stateful (e.g. Mvars or Files) or stateless (e.g. a shared Haskell variable). Sharing stateless objects between parallel, concurrent, or distributed threads preserves sequential semantics, but sharing stateful objects can introduce non-determinism, unless you have additional properties. Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: RE: question about concurrency implementation
Dean, If the costs are the same, does that rely on there being no true concurrency in the current implementations? It depends what you mean by true concurrency: from the point of view of the Haskell programmer, GHC's implementation of concurrency is almost preemptive, because we can context-switch at any allocation. Most computation does some allocation, but it's possible to write functions that don't (although these tend to be on the trivial side - an optimised nfib won't allocate, for example). We could artificially cause all computation to do some allocation to avoid this problem, but we haven't found it necessary so far. But I suspect by true concurrency you're referring at the kind of concurrent processes that can be executed on multiple CPUs simultaneously. We did investigate doing this a while back, and found that the locking required on thunks was very expensive (slowed down the program by at least 2x on the bog-standard SMP machine we had here). However there are some clever techniques that can be used to reduce the cost - giving each process its own private allocation area and only degrading to full locking for access to the shared portion of the heap is one such technique we experimented with briefly but I don't have any concrete benchmarks I'm afraid. Also you really need a multithreaded garbage collector, which is a lot of work. We've developed a Haskell extension that exhibit's true concurrency on multiple CPUs, it's called Glasgow distributed Haskell (GdH). It's primarily designed for distribution (i.e. multiple stateful threads on multiple processors), but can be used to build parallel programs too. For more info see http://www.cee.hw.ac.uk/~dsg/gdh/ Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GPH: RE: Setting up ghc for GPH and GranSim
Mathew, Simon's quite right, the GranSim simulator for Glasgow parallel Haskell (GpH) is only available with certain GHC versions, and it's most readily available for version 0.29. Information about the platforms supported, together with GHC source and binary downloads, is available from the GHC website: http://www.haskell.org/ghc/ under 'Download', 'Older releases', '0.29'. The easiest way to get GranSim is to download an appropriate binary distribution, but be aware that GHC version 0.29 supports Haskell 1.2 which has most familiar Haskell constructs, but lacks a few: most significantly Monadic IO. At present people issues mean that we don't plan a newer release of GranSim. Although GranSim is a little old, shiny new GpH programs (i.e. Haskell 1.4) can be run on parallel (or sequential) platforms using GHC 4.06, as documented at http://www.cee.hw.ac.uk/~dsg/gph/ Phil On Fri, 28 Dec 2001 03:00:07 -0800 Simon Peyton-Jones [EMAIL PROTECTED] wrote: You can't use any old GHC for GpH, I'm afraid. (GpH modifies GHC internally.) Best thing to do is to go to the GpH website and get your GHC from there. http://www.cee.hw.ac.uk/~dsg/gph/ There's a GpH mailing list, which I'm ccing. Perhaps they are planning a new release? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: 21 December 2001 17:52 | To: [EMAIL PROTECTED] | Subject: Setting up ghc for GPH and GranSim | | | Hi all, | | I'm new to both this list and Haskell, so apologies if these | questions have been answered before or seem obvious. I've | trawled the website and my suspicion is that I'm using a 'too | new' version of the compiler that doesn't support GranSim. Anyway: | | I'm trying to set up a ghc. I want to compile GPH programs | and run them on GranSim. | | With my current setup (details at the bottom of the mail) I | get the following error when I try to compile a GPH program: | [mjb67@mjb67 mjb67]$ ghc -gransim -fvia-c -fglasgow-exts | --make parfib.hs | ghc-5.02.1: can't find module `Prelude' | | Does anyone have any idea what I might be doing wrong? The | error is reported even when the program is normal Haskell, | whenever I use the -gransim or -parallel options to the | compiler. I presume this is some sort of library issue? | | My compiler was set up in the following way: | | I installed the binary RPMs: | http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.i386. rpm http://www.haskell.org/happy/dist/1.11/happy-1.11-1.i386.rpm I downloaded the source RPM from: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.src.rpm I unpacked the source. I then typed (in the source root directory) ./configure --enable-gransim make make install Thanks in advance, Matthew ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq / strictness and laziness
Both parallel and sequential computation must be carefully controlled to produce good parallel and distributed Haskell programs. Several languages including Glasgow parallel Haskell and Eden use *evaluation strategies*: overloaded polymorphic functions to describe the amount of evaluation. type Done = () type Strategy a = a - Done There are three basic strategies: - r0 performs no evaluation on its argument, - rwhnf reduces its argument to weak head normal form, - rnf reduces its argument to (head) normal form: i.e. deepseq. System support for rnf/deepseq would be A Good Thing. r0, rwhnf :: Strategy a r0 x = () rwhnf x = x `seq` () class NFData a where class Eval a = NFData a where rnf :: Strategy a Example instances of NFData are given below, a useful set are predefined in the module below: instance (NFData a, NFData b) = NFData (a,b) where rnf (x,y) = rnf x `seq` rnf y instance NFData a = NFData [a] where rnf [] = () rnf (x:xs) = rnf x `seq` rnf xs Strategies are simply functions that can be abstracted and composed lilke any others, e.g. SeqList applies a strategy to each element of a list sequentially. seqList :: Strategy a - Strategy [a] seqList strat [] = () seqList strat (x:xs) = strat x `seq` (seqList strat xs) So 'SeqList r0' evaluates just the spine of the list, and 'seqList (seqList rwhnf)' evaluates the elements of a list of lists to weak head normal form. You can apply a strategy to an expression using :: a - Strategy a - a using x s = s x `seq` x So to force newcounts in your program you want to change the last line to be something like: countAFile oldcounts filename = do compiledFile - readAndCompile filename let newcounts = countAssociations compiledFile oldcounts return newcounts 'using' rnf There's a copy of the Strategies module attached. More info in Algorithm + Strategy = Parallelism, P.W. Trinder, K. Hammond, H-W. Loidl, S.L. Peyton Jones In Journal of Functional Programming 8(1):23--60, January 1998. URL: http://www.cee.hw.ac.uk/~dsg/gph/papers/ps/strategies.ps.gz Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder Strategies.lhs Description: Binary data
SFP Call for Participation
CALL FOR PARTICIPATION 3rd Scottish Functional Programming Workshop University of Stirling Aug 22nd-24th, 2001 You are invited to participate in the 3rd Scottish Functional Programming Workshop. The draft programme is below, and both registration form and additional information are available at: http://www.cee.hw.ac.uk/~greg/sfp3/ SFP'3 Draft Programme = Parallelism --- A Comparative Study of Skeleton-based Parallel Programming Environments Allowing Arbitrary Nesting Remi Coudarcher, Jocelyn Serot, Jean-Pierre Derutin Universite Blaise Pascal - Clermont II, France BSP in a Lazy Functional Context Quentin Miller Universite d'Orleans, France Parallel Functional Genetic Programming Graeme McHale and Greg Michaelson Heriot-Watt University, Scotland Introduction of Pipelining into Gaussian Elimination Joy Goodman Glasgow University, Scotland The Efficiency of Parallel Graph Reduction on a Loosely-coupled Multiprocessor Hans Wolfgang Loidl An SPMD environment machine for functional BSP programs Armelle Merlin, Gaetan Hains Universite d'Orleans, France Implementing and Measuring GdH Skeletons Phil Trinder Heriot-Watt University, Scotland Distribution Distributed Programming with Dynamic Reply Channels Rita Loogen, Steffen Priebe Philips-Universitat Marburg, Germany Distributed Applications in GdH Robert Pointon Heriot-Watt University, Scotland Applications Haskell: Language for Business Systems Dominic Steinitz, British Airways Chris Reade, Dan Russell, Phil Molyneux, Barry Avery Kingston Business School, England Functional programming languages for verification tools: experiences with ML and Haskell Martin Leucker, Thomas Noll, Perdita Stevens, Michael Weber RWTCH Aachen, Germany/University of Edinburgh, Scotland Infinite Pretty Printing in eXene Allen Stoughton Kansas State University, USA Derivation and Transformation - Extending Higher-Order Deforestation: Transforming Programs to Eliminate Even More Trees Geoff Hamilton, Dublin City University, Ireland Deriving Non-heirarchical Process Topologies Ricardo Pena, Fernando Rubio, Clara Segura Universidad Complutense de Madrid, Spain Language Design and Implementation -- Some Experiences Connecting Functional Languages and Java Andre Rauber Du Bois, Antonio Carlos da Rocha Costa Universidade Federal do Rio Grande do Sul/ Universidade Catolica de Pelotas, Brazil Paging Behaviour of List-based Memory in a Distributed Virtual Memory System for Pure Functional Languages Marco T. Morazan and Douglas R. Troeger City University of New York, USA Types - How to Fix Type Errors Automatically Bruce J. McAdam University of Edinburgh, Scotland Function Types and Complete type Inference Manfred Widera, Christoph Bierle Fern Universitat Hagen, Germany Human-like Explanations of Polymorphic Types Yang Jun, Greg Michaelson, Phil Trinder Heriot-Watt University, Scotland Theory -- The dual of grafting is decoration Tarmo Uustalu, Varmo Vene Universidade do Minho, Portugal University of Tartu, Estonia Towards a Denotational semantics for Eden Mercedes Hidalgo-Herrero, Yolanda Ortega-Mallen Universidad Complutense de Madrid, Spain ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell PhD Scholarship
Folks, Are you planning to do a PhD and interested in parallel or distributed versions of Haskell? There's a PhD scholarship available at Heriot-Watt University, Edinburgh, Scotland. To win the scholarship you'll need to have, or get, a first-class degree and have excellent references. The group at Heriot-Watt have implemented and used parallel versions of Haskell and ML, and a distributed Haskell. We're part of a vibrant functional programming community in the central belt of Scotland. More information on who we are and what we do is available at http://www.cee.hw.ac.uk/~trinder/projects.html http://www.cee.hw.ac.uk/~trinder/ http://www.cee.hw.ac.uk/~dsg/ If you're interested in applying for the scholarship please contact me. Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Versions of GHC Supporting GHC
Ben, GpH is available with GHC versions 0.29, 2.10, and 3.02, all of which are downloadable from the GHC site. The runtime system was completely revised for version 4, and we're just completing the adaption of GUM for version 4. Should be available within weeks. Additional information about GpH is available from the web site, and mailing list: http://www.cee.hw.ac.uk/~dsg/gph/ [EMAIL PROTECTED] Apologies for slow response - I've been away. Enjoy! Phil -Original Message- From: Ben [mailto:[EMAIL PROTECTED]] Sent: 26 May 2000 19:51 To: [EMAIL PROTECTED] Subject: Glasgow Parallel Haskell Recently GPH was installed on my Universities beowulf cluster. PVM3 is installed (as well as Lam MPI). Ghc appears to be correctly installed; it compiles non-parallel programs fine. However when I try to compile (for example) the fibonacci function given in the documentation it fails. --- End --- -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
PhD Scholarships Available
The Department of Computing and Electrical Engineering at Heriot-Watt University, in Edinburgh, Scotland has a number of EPSRC PhD Studentships available for UK and EU nationals to undertake research in Functional Programming. The department has a very active group working on parallel functional programming, type theory and rewriting. Candidates should hold or expect to hold a good honours degree or the equivalent. Further information about research interests is available from http://www.cee.hw.ac.uk/Research/dependable_index.html or for further details and application forms contact: Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder --- End Forwarded Message --- -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
Re: FW: ghc -parallel ...
Dirk,
Glasgow parallel Haskell (GpH) doesn't work with GHC 4.04,
but will real soon: (in 4.06 I believe). More info on GpH,
including the mailing list can be found on
http://www.cee.hw.ac.uk/~dsg/gph/
Phil
-Original Message-
From: Dirk Nowotka TUCS [mailto:[EMAIL PROTECTED]]
Sent: None
To: [EMAIL PROTECTED]
Subject: ghc -parallel ...
Hi,
I've been trying to compile a toy example with GHC's parallel option.
The `impossible' happened ...
How do I get the parallel machinery working?
Best,
Dirk
Here is the verbose compiler report:
(the program code follows after that)
droog:~/Hacks/haskell/Equations/src/test ghc -parallel
-i/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent
:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/std -v
parFact.hs
The Glorious Glasgow Haskell Compilation System, version 4.04, patchlevel 1
Effective command line: -parallel
-i/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent
:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/std -v
ghc: unrecognised option: -fstack-check
Ineffective C pre-processor:
echo '{-# LINE 1 "parFact.hs" -}' /tmp/ghc21755.cpp cat
parFact.hs /tmp/ghc21755.cpp
real0.0
user0.0
sys 0.0
ghc:compile:Output file parFact.o doesn't exist
ghc:compile:Interface file parFact.hi doesn't exist
ghc:recompile:Input file parFact.hs newer than parFact.o
Haskell compiler:
/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/hsc
/tmp/ghc21755.cpp -fparallel -fignore-interface-pragmas
-fomit-interface-pragmas -fsimplify [ -finline-phase2
-fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns
-fwarn-missing-methods -fwarn-duplicate-exports -fhi-version=404 -static
-himap=/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concu
rrent%.hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/st
d%.hi:.%.hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/
concurrent%.mp_hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/im
ports/concurrent%.mp_hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4
.04/imports/std%.mp_hi-v -hifile=/tmp/ghc21755.hi -C=/tmp/ghc21755.hc
-F=/tmp/ghc21755_stb.c -FH=/tmp/ghc21755_stb.h +RTS -H600 -K100
Glasgow Haskell Compiler, version 4.04, for Haskell 98, compiled by GHC
version 4.04
panic! (the `impossible' happened):
closureCodeBody:arg_regs
Please report it as a compiler bug to [EMAIL PROTECTED]
real2.5
user2.3
sys 0.1
deleting... /tmp/ghc21755.cpp /tmp/ghc21755.hi /tmp/ghc21755.hc
/tmp/ghc21755_stb.c /tmp/ghc21755_stb.h
rm -f /tmp/ghc21755*
parFact.hs:
module Main(main) where
import IO
import Parallel
pfc :: Int - Int - Int - Int
pfc x y c
| y - x c = f1 `par` (f2 `seq` (f1+f2))
| x == y= x
| otherwise = pf x m + pf (m+1) y
where
m = (x+y) `div` 2
f1 = pfc x m c
f2 = pfc (m+1) y c
pf :: Int - Int - Int
pf x y
| x y = pf x m + pf (m+1) y
| otherwise = x
where
m = (x+y) `div` 2
parfact x c = pfc 1 x c
mk_num :: String - Int
mk_num s = (fst . head) (reads s :: [(Int,String)])
main = do putStr "argument 1: "
arg1 - getLine
putStr "argument 2: "
arg2 - getLine
putStrLn (show (parfact (mk_num arg1) (mk_num arg2)))
------
Phil Trinder
Department of Computing and Electrical Engineering
Heriot Watt University
Riccarton
Edinburgh, EH14 4AS
E-mail: [EMAIL PROTECTED]
Teleph: +44 (0)131 451 3435
Depart: +44 (0)131 451 3328
Fasmly: +44 (0)131 451 3327
Intrnt: www:http://www.cee.hw.ac.uk/~trinder
Re: Parallel Haskell on GHC-4.04
Shimoda, Help with Glasgow parallel Haskell is available from: http://www.cee.hw.ac.uk/~dsg/gph/ and on [EMAIL PROTECTED] a friendly mailing list. Phil On Fri, 10 Dec 1999 12:31:28 +0900 (JST) Shimdoa Hirotada [EMAIL PROTECTED] wrote: Hello. Thank you for your reply. In the meantime, you can run parallel programs using GHC 0.29 (binaries for a few architectures available from GHC's web site: http://www.haskell.org/ghc) or GHC 3.02 (binaries are rumoured to be available, but I'm not sure where). I installed GHC-0.29 in Solaris and succeeded to compile the example program. Next, I try GHC-3.02. Thanks. $BAzED(B $B9-Ci(B [EMAIL PROTECTED] [EMAIL PROTECTED] -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
Haskell Research Position
Distributed Haskell Research Position - Are you interested in discovering the costs and benefits of functional languages for distributed programming? In particular in comparing them with conventional languages like Java? We have EPSRC funding to investigate a distributed version of Haskell, based on the Glasgow Haskell Compiler (GHC). The skills you will need are: o Functional Programming Experience, preferably using Haskell. o A good honours degree in Computing, together with some research experience. o Distributed programming, preferably using Java. The post is at the Computing and Electrical Engineering Department (http://www.cee.hw.ac.uk/) of Heriot-Watt University Edinburgh (http://www.hw.ac.uk/). It is available immediately, for approximately 18 months, and the salary will be between £15735 and £20107. For application details please contact the Personnel Office, Heriot-Watt University, Edinburgh EH14 4AS tel/fax: 0131 451 3475 (24 hours) quoting Ref 98/99/G. Further particulars can be obtained directly from me. Closing date 18th June 1999. Phil Trinder -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
Re: Parallel Haskell
Ernesto, There's also a parallel implementation of Haskell based on the Glasgow Haskell Compiler (GHC): Web page: http://www.dcs.gla.ac.uk/fp/software/gph/ Mailing List: [EMAIL PROTECTED] Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
Glasgow Parallel Haskell
Folks, There's a new mailing list about the implementation and use of Glasgow Parallel Haskell (GpH). GpH is included with most releases of the Glasgow Haskell Compiler since ghc 0.29. More information on GpH is available at http://www.dcs.gla.ac.uk/~hwloidl/fp-www/software/gransim/GranSim-GUM-papers.html To subscribe to the list send a message to [EMAIL PROTECTED] with the following text in the message body: subscribe gph When you want to leave the list use: unsubscribe gph Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
Glasgow Parallel Haskell
Folks, There's a new mailing list about the implementation and use of Glasgow Parallel Haskell (GpH). GpH is included with most releases of the Glasgow Haskell Compiler since ghc 0.29. More information on GpH is available at http://www.dcs.gla.ac.uk/~hwloidl/fp-www/software/gransim/GranSim-GUM-papers.html To subscribe to the list send a message to [EMAIL PROTECTED] with the following text in the message body: subscribe gph When you want to leave the list use: unsubscribe gph Phil -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: www:http://www.cee.hw.ac.uk/~trinder
