Nested Algorithmic Skeletons From Higher Order Functions

Michaelson, Greg; Scaife, Norman; Bristow, Paul; King, Peter J. B.

doi:10.1080/01495730108935271

Cited by 30 publications

(40 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Incorporating explicit concurrency abstractions within high-level languages has a long history [22,23,18,9,36], as does deriving parallelism from unannotated programs either through compiler analysis [31] or through explicit annotations and pragmas [39]. Our ideas differ from these efforts insofar as we are concerned with providing abstractions that simplify the complexity of locking and synchronization.…”

Section: Related Workmentioning

confidence: 87%

Transactional Monitors for Concurrent Objects

Welc

Jagannathan

Hosking

2004

ECOOP 2004 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Transactional monitors are proposed as an alternative to monitors based on mutual-exclusion synchronization for object-oriented programming languages. Transactional monitors have execution semantics similar to mutualexclusion monitors but implement monitors as lightweight transactions that can be executed concurrently (or in parallel on multiprocessors). They alleviate many of the constraints that inhibit construction of transparently scalable and robust applications. We undertake a detailed study of alternative implementation schemes for transactional monitors. These different schemes are tailored to different concurrent access patterns, and permit a given application to use potentially different implementations in different contexts. We also examine the performance and scalability of these alternative approaches in the context of the Jikes Research Virtual Machine, a state-of-the-art Java implementation. We show that transactional monitors are competitive with mutualexclusion synchronization and can outperform lock-based approaches up to five times on a wide range of workloads.

show abstract

Section: Related Workmentioning

confidence: 87%

Transactional Monitors for Concurrent Objects

Welc

Jagannathan

Hosking

2004

ECOOP 2004 – Object-Oriented Programming

View full text Add to dashboard Cite

show abstract

“…The disadvantages are that an automatic coordination management complicates the operational semantics, makes the performance of programs opaque, is hard to implement, and is frequently less effective than hand-crafted coordination. In these languages, the low-level coordination may be managed solely by the compiler as in PMLS [12], solely by the RTE as in GPH [13], or by both as in Eden [14]. Whichever mechanism is chosen, the implementation of sophisticated automatic coordination management is arduous, and there have been many more designs for semiexplicit and implicit parallel languages than well-engineered implementations.…”

Section: High-level Parallel Coordinationmentioning

confidence: 99%

“…In languages with semiexplicit parallelism like GPH or Eden, the programmer specifies only a few key coordination aspects, for example, what threads to create, and the language implementation automatically manages the remaining coordination aspects. In an implicitly parallel language like High-Performance Fortran [11] or PMLS [12], the programmer does not specify coordination aspects, as the parallelism is implicit in the language semantics.…”

Section: High-level Parallel Coordinationmentioning

confidence: 99%

Evaluating a High-Level Parallel Language (GpH) for Computational GRIDs

Zain¹,

Trinder²,

Michaelson

et al. 2008

IEEE Trans. Parallel Distrib. Syst.

View full text Add to dashboard Cite

Abstract-Computational GRIDs potentially offer low-cost, readily available, and large-scale high-performance platforms. For the parallel execution of programs, however, computational GRIDs pose serious challenges: they are heterogeneous and have hierarchical and often shared interconnects, with high and variable latencies between clusters. This paper investigates whether a programming language with high-level parallel coordination and a Distributed Shared Memory (DSM) model can deliver good and scalable performance on a range of computational GRID configurations. The high-level language Glasgow parallel Haskell (GpH) abstracts over the architectural complexities of the computational GRID, and we have developed GRID-GUM2, a sophisticated grid-specific implementation of GpH, to produce the first high-level DSM parallel language implementation for computational GRIDs. We report a systematic performance evaluation of GRID-GUM2 on combinations of high/low and homogeneous/heterogeneous computational GRIDs. We measure the performance of a small set of kernel parallel programs representing a variety of application areas, two parallel paradigms, and ranges of communication degree and parallel irregularity. We investigate GRI D-GUM2's performance scalability on medium-scale heterogeneous and high-latency computational GRIDs and analyze the performance with respect to the program characteristics of communication frequency and degree of irregular parallelism.

show abstract

“…The automatic selection of appropriate skeletons during compile-time using new Haskell meta-programming constructs is discussed in [5]. The recent journal paper [8] shows that Eden achieves good performance in comparison with Glasgow parallel Haskell (GpH) [4] and Parallel ML with Skeletons (PMLS) [10].…”

Section: Eden's Main Featuresmentioning

confidence: 99%

“…P 3 L [1], provide a fixed set of skeletons, sometimes combined with sophisticated program analysis, as e.g. in PMLS [10]. The skeleton implementation is usually out of reach for the programmer, whereas in Eden, programming a skeleton requires nothing but ordinary parallel functional programming.…”

Section: Param #N Threadmentioning

confidence: 99%

High-Level Process Control in Eden

Berthold

Klusik

Loogen

et al. 2003

Euro-Par 2003 Parallel Processing

View full text Add to dashboard Cite

Abstract. High-level control of parallel process behaviour simplifies the development of parallel software substantially by freeing the programmer from low-level process management and coordination details. The latter are handled by a sophisticated runtime system which controls program execution. In this paper we look behind the scenes and show how the enormous gap between high-level parallel language constructs and their low-level implementation has been bridged in the implementation of the parallel functional language Eden. The main idea has been to implement the process control in a functional language and to restrict the extensions of the low-level runtime system to a few selected primitive operations.

show abstract

Nested Algorithmic Skeletons From Higher Order Functions

Cited by 30 publications

References 9 publications

Transactional Monitors for Concurrent Objects

Transactional Monitors for Concurrent Objects

Evaluating a High-Level Parallel Language (GpH) for Computational GRIDs

High-Level Process Control in Eden

Contact Info

Product

Resources

About