Parallel and Distributed Haskells

Trinder, Phil; Loidl, Hans-Wolfgang; Pointon, Robert F.

doi:10.1017/s0956796802004343

Cited by 49 publications

(24 citation statements)

References 81 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We focus mostly on those with a functional flavour. For surveys, see [28,41]. Broadly speaking, we can divide them into those that use some form of explicit message passing, and those that have more implicit mechanisms for distribution and communication.…”

Section: Related Workmentioning

confidence: 99%

Towards native higher-order remote procedure calls

Fredriksson

Ghica

Wheen

2014

Proceedings of the 26nd 2014 International Symposium on Implementation and Application of Functional Languages

View full text Add to dashboard Cite

We present a new abstract machine, called DCESH, which models the execution of higher-order programs running in distributed architectures. DCESH implements a native general remote higherorder function call across node boundaries. It is a modernised version of SECD enriched with specialised communication features required for implementing the remote procedure call mechanism. The key correctness result is that the termination behaviour of the remote procedure call is indistinguishable (bisimilar) to that of a local call. The correctness proofs and the requisite definitions for DCESH and other related abstract machines are formalised using Agda. We also formalise a generic transactional mechanism for transparently handling failure in DCESHs.We use the DCESH as a target architecture for compiling a conventional call-by-value functional language ("Floskel") which can be annotated with node information. Conventional benchmarks show that the single-node performance of Floskel is comparable to that of OCaml, a semantically similar language, and that distribution overheads are not excessive. Native RPC and transparent distributionThe remote procedure call (RPC) [7] is a widely used mechanism for higher-level inter-process communication. An RPC is what its name suggests: a call to a procedure located on a remote node. The idea is that an RPC looks and acts like an ordinary procedure call, and performs the necessary message passing under the hood. However, the RPC mechanism tends to be bolted on top of a pre-existing language, as a library for example, rather than be seamlessly integrated into it. This leads to significant syntactic differences between calling a local library function and a remote function. Even if these syntactic differences can be smoothed using stubs that wrap remote calls into local calls [6] important differences still persist, of which the most important is that arguments must be of ground types.Generalising RPC to all types and incorporating it seamlessly in the language has been considered but dismissed on grounds of potential inefficiencies [40]. However, considering that a number of technologies that trade efficiency for convenience have been rejected on similar grounds (from machine independent languages to functional programming, garbage collection or automated program verification -to name only a few), we decided it is time to revisit Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. IFL '14, October 1-3, 2014, Boston, MA, USA. Copyright c 20yy ACM 978-1-nnnn-nnnn-n/yy/...

show abstract

Section: Related Workmentioning

confidence: 99%

Towards native higher-order remote procedure calls

Fredriksson

Ghica

Wheen

2014

Proceedings of the 26nd 2014 International Symposium on Implementation and Application of Functional Languages

View full text Add to dashboard Cite

show abstract

“…These two languages show major differences in their coordination concept and, in consequence, in their implementation, while on the other hand, they both capture the main idea of evaluating independent subexpressions in parallel. Another common point is that, in contrast to other parallel Haskells [2], both GpH and Eden are designed as general-purpose coordination languages. Neither of them is dedicated to a certain paradigm such as task-or data-parallelism or pure skeleton-based programming, though the respective coordination schemes can be expressed by both.…”

Section: General-purpose Parallelism In Haskellmentioning

confidence: 99%

“…Other dialects are more explicit in their handling of parallelism and allow what we call general-purpose parallelism, able to capture schemes of parallelism which are not data-oriented. Whereas machine-specific optimisation is easier with specialised structures and operations, these more general approaches present a considerable advantage in language design: It is generally accepted [1,2] that functional languages allow a clean distinction between a computation (or "base") language and independent coordination constructs for parallelism control. The more special-purpose data structures enter the language, the more vague this important distinction will become.…”

Section: Introductionmentioning

confidence: 99%

Towards a Generalised Runtime Environment for Parallel Haskells

Berthold

2004

Computational Science - ICCS 2004

View full text Add to dashboard Cite

Abstract. Implementations of parallel dialects (or: coordination languages) on a functional base (or: computation) language always have to extend complex runtime environments by the even more complex parallelism to maintain a high level of abstraction. Starting from two parallel dialects of the purely functional language Haskell and their implementations, we generalise the characteristics of Haskell-based parallel language implementations, abstracting over low-level details. This generalisation is the basis for a shared runtime environment which can support different coordination concepts and alleviate the implementation of new constructs by a well-defined API and a layered structure.

show abstract

“…Typically, declarative implementations of skeletons are based on functional languages (like Eden [9], GpH [16], or PMLS [11]) that naturally represent skeletons as higher-order functions. These languages also allow to prove skeletons correctness [13].…”

mentioning

confidence: 99%

Distributed Applications Implemented in Maude with Parameterized Skeletons

Riesco

Verdejo

2007

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Algorithmic skeletons are a well-known approach for implementing parallel and distributed applications. Declarative versions typically use higher-order functions in functional languages. We show here a different approach based on object-oriented parameterized modules in Maude, that receive the operations needed to solve a concrete problem as a parameter. Architectures are conceived separately from the skeletons that are executed on top of them. The object-oriented methodology followed facilitates nesting of skeletons and the combination of architectures. Maude analysis tools allow to check at different abstraction levels properties of the applications built by instantiating a skeleton.

show abstract

Parallel and Distributed Haskells

Cited by 49 publications

References 81 publications

Towards native higher-order remote procedure calls

Towards native higher-order remote procedure calls

Towards a Generalised Runtime Environment for Parallel Haskells

Distributed Applications Implemented in Maude with Parameterized Skeletons

Contact Info

Product

Resources

About