Parallel concurrent ML

Reppy, John; Russo, Claudio; Xiao, Yingqi

doi:10.1145/1596550.1596588

Cited by 32 publications

(20 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Continuation based concurrency libraries have been well studied [23,25] and serve as the basis of several parallel and concurrent programming language implementations [21,22,27]. Among these, ConcurrentML [21] implementations on SML/NJ and MLton, and MultiMLton [27] do not expose the ability to describe alternative ULS's.…”

Section: Related Workmentioning

confidence: 99%

“…Among these, ConcurrentML [21] implementations on SML/NJ and MLton, and MultiMLton [27] do not expose the ability to describe alternative ULS's. Fluet et al [5] propose a scheduling framework for a strict parallel functional language on Manticore [22]. However, unlike our system, the schedulers are described in an external language of the compiler's internal representation, and not the source language.…”

Section: Related Workmentioning

confidence: 99%

“…While Manticore [22], and MultiMLton [27] utilise lowlevel compare-and-swap operation as the core synchronisation primitive, Li et al's concurrency substrate [14] for GHC was the first to utilise transactional memory for multiprocessor synchronisation for in the context of ULS's. Our work borrows the idea of using STM for synchronisation.…”

Section: Related Workmentioning

confidence: 99%

“…Examples include virtual machines for popular object-oriented languages such as Oracle's Java HotSpot VM [12], IBM's Java VM [13], Microsoft's Common Language Runtime (CLR) [19], as well as functional language runtimes such as Manticore [22], MultiMLton [27] and the Glasgow Haskell Compiler (GHC) [8].…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Composable scheduler activations for Haskell

et al. 2016

View full text Add to dashboard Cite

The runtime for a modern, concurrent, garbage collected language like Java or Haskell is like an operating system: sophisticated, complex, performant, but alas very hard to change. If more of the runtime system were in the high level language, it would be far more modular and malleable. In this paper, we describe a novel concurrency substrate design for the Glasgow Haskell Compiler (GHC) that allows multicore schedulers for concurrent and parallel Haskell programs to be safely and modularly described as libraries in Haskell. The approach relies on abstracting the interface to the user-implemented schedulers through scheduler activations, together with the use of Software Transactional Memory (STM) to promote safety in a multicore context.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Composable scheduler activations for Haskell

et al. 2016

View full text Add to dashboard Cite

show abstract

“…It allows to specify parallelism on several levels in a large-scale applications, typically using explicit synchronisation and coordination on the top level [45] and combining it with implicit, automatically managed, fine-grained threads on lower levels [17].…”

Section: Related Workmentioning

confidence: 99%

Parallel Haskell implementations of the N‐body problem

Totoo

Loidl

2013

Concurrency and Computation

View full text Add to dashboard Cite

SUMMARYThis paper provides an assessment of high-level parallel programming models for multi-core programming by implementing two versions of the n-body problem. We compare three different parallel programming models based on parallel Haskell, differing in the ways how potential parallelism is identified and managed. We assess the performance of each implementation, discuss the sequential and parallel tuning steps leading to the final versions, and draw general conclusions on the suitability of high-level parallel programming models for multi-core programming. We achieve speed-ups of up to 7.2 for the all-pairs algorithm and up to 6.5 for the Barnes-Hut algorithm on an 8-core machine.

show abstract

A survey of real‐time capabilities in functional languages and compilers

Murphy

Shivkumar

Pritchard

et al. 2018

Concurrency and Computation

View full text Add to dashboard Cite

Functional programming languages play an important role in the development of correct software systems. As embedded devices become pervasive and perform critical tasks in our lives, their reliability becomes paramount. This presents a natural opportunity to explore the application of functional programming languages to systems that demand highly predictable behavior.In this paper, we explore existing functional programming language compilers and their applicability to real-time embedded systems. We do this by defining important characteristics needed by a real-time programming language and survey how well existing languages meet these characteristics. We conduct empirical analysis of language runtimes in order to assess the impact of dynamic memory management on predictability and performance. Lastly, we review different programming models for expressing real-time considerations in applications. INTRODUCTIONReal-time software is an integral part in many complex software/hardware systems that require timing guarantees in addition to traditional functional correctness guarantees. Such systems vary in nature, spanning multiple domains including industrial control, robotics, automotive, avionics, and medical devices, among others. These systems all provide services whose utility is dictated by the timeliness in which they respond to external (eg, sensor readings) and internal (eg, software events and interrupts) stimuli. Writing the software for these systems is a difficult undertaking because ensuring the system is correct requires providing predictability guarantees. This is exacerbated by the fact that most software for real-time systems is written in "low level" imperative languages.Functional languages are known for their ability to be reasoned about with respect to correctness, often with automated tools. 1-3 Given that real-time systems are frequently deployed in safety-critical and mission-critical situations, the ability to write software with a high degree of confidence in its correctness and predictability is important. Functional languages are well suited for the former task (correctness), but are not developed for the latter (predictability). Indeed, general purpose, functional programming languages are not used for developing real-time systems and there are no investigations to ensure their predictability. There are, however, many domain-specific functional languages that provide predictability for niche domains. The state of mainstream functional programming languages with respect to their ability to express and provide predictability is something we would like to investigate in this survey.One reason that functional languages are not considered for writing real-time software is because they are managed languages and automatic memory management has classically been considered unpredictable. While many may consider this a reason to reject functional programming as a target language for real-time systems development, we can instead look to managed object-oriented systems for inspiration. Indeed, the ques...

show abstract

Parallel concurrent ML

Cited by 32 publications

References 15 publications

Composable scheduler activations for Haskell

Composable scheduler activations for Haskell

Parallel Haskell implementations of the N‐body problem

A survey of real‐time capabilities in functional languages and compilers

Contact Info

Product

Resources

About