Explicit Message Passing for Concurrent Clean

Serrarens, Pascal R.; Plasmeijer, M.J.

doi:10.1007/3-540-48515-5_15

Cited by 4 publications

(2 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Due to this inherent need for liberty which does not fit well in the functional model and its general aim of soundness and abstraction, not many parallel functional languages support arbitrary connections between units of computation at all. The concepts for Clean presented in [22] go in this direction and make use of Clean's uniqueness concept to purify some points. In the same way, languages like Facile [7] or Concurrent ML [20] support communication facilities on a lower-level of abstraction than the dynamic channel concept of Eden.…”

Section: Related Workmentioning

confidence: 99%

The Impact of Dynamic Channels on Functional Topology Skeletons

Berthold

Loogen

2008

Parallel Process. Lett.

View full text Add to dashboard Cite

Parallel functional programs with implicit communication often generate purely hierarchical communication topologies during execution: communication only happens between parent and child processes. Messages between siblings must be passed via the parent. This causes inefficiencies that can be avoided by enabling direct communication between arbitrary processes. The Eden parallel functional language provides dynamic channels to implement arbitrary communication topologies. This paper analyses the impact of dynamic channels on Eden's topology skeletons, i.e. skeletons which define process topologies such as rings, toroids, or hypercubes. We compare topology skeletons with and without dynamic channels with respect to the number of messages. Our case studies confirm that dynamic channels usually decrease the number of messages by up to 50% and can reduce runtime by up to 50%. Detailed analysis of Eden TV (trace viewer) execution profiles reveals the reasons for these substantial runtime gains.

show abstract

Section: Related Workmentioning

confidence: 99%

The Impact of Dynamic Channels on Functional Topology Skeletons

Berthold

Loogen

2008

Parallel Process. Lett.

View full text Add to dashboard Cite

show abstract

“…Other approaches provide programmers with more or less explicit means for process or thread management, synchronization, and communication, e.g. (Cooper & Morrisett, 1990;Reppy, 1991;Bailey & Newey, 1993;Jones et al, 1996;Breitinger et al, 1997;Kelly & Taylor, 1999;Serrarens, 1999). However, to the same extent as they provide control over parallel execution, these approaches also introduce the pitfalls of traditional parallel programming, e.g.…”

Section: Introductionmentioning

confidence: 99%

Shared memory multiprocessor support for functional array processing in SAC

Grelck¹

2005

J. Funct. Prog.

View full text Add to dashboard Cite

Classical application domains of parallel computing are dominated by processing large arrays of numerical data. Whereas most functional languages focus on lists and trees rather than on arrays, SAC is tailor-made in design and in implementation for efficient high-level array processing. Advanced compiler optimizations yield performance levels that are often competitive with low-level imperative implementations. Based on SAC, we develop compilation techniques and runtime system support for the compiler-directed parallel execution of high-level functional array processing code on shared memory architectures. Competitive sequential performance gives us the opportunity to exploit the conceptual advantages of the functional paradigm for achieving real performance gains with respect to existing imperative implementations, not only in comparison with uniprocessor runtimes. While the design of SAC facilitates parallelization, the particular challenge of high sequential performance is that realization of satisfying speedups through parallelization becomes substantially more difficult. We present an initial compilation scheme and multi-threaded execution model, which we step-wise refine to reduce organizational overhead and to improve parallel performance. We close with a detailed analysis of the impact of certain design decisions on runtime performance, based on a series of experiments.

show abstract