Runtime support for multicore Haskell

Marlow, Simon; Jones, Simon Peyton; Singh, Satnam

doi:10.1145/1596550.1596563

Cited by 75 publications

(25 citation statements)

References 25 publications

(14 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In this section, we briefly review the operation of the threaded RTS and the GHC IO manager, which are presented in more detail in [10,11,15], respectively.…”

Section: Background: Ghc Threaded Rtsmentioning

confidence: 99%

“…Unfortunately, this design introduces a problem that threatens to negate its benefits: a dispatcher thread often makes blocking OS calls, and therefore relinquishes its HEC and causes a context switch to another native thread which begins executing the HEC's work [11]. Using one dispatcher per HEC increases the frequency with which this expensive operation occurs.…”

Section: Per-core Dispatchersmentioning

confidence: 99%

See 1 more Smart Citation

Mio

Voellmy

Wang

Hudak

et al. 2013

Proceedings of the 2013 ACM SIGPLAN Symposium on Haskell

View full text Add to dashboard Cite

Haskell threads provide a key, lightweight concurrency abstraction to simplify the programming of important network applications such as web servers and software-defined network (SDN) controllers. The flagship Glasgow Haskell Compiler (GHC) introduces a run-time system (RTS) to achieve a high-performance multicore implementation of Haskell threads, by introducing effective components such as a multicore scheduler, a parallel garbage collector, an IO manager, and efficient multicore memory allocation. Evaluations of the GHC RTS, however, show that it does not scale well on multicore processors, leading to poor performance of many network applications that try to use lightweight Haskell threads. In this paper, we show that the GHC IO manager, which is a crucial component of the GHC RTS, is the scaling bottleneck. Through a series of experiments, we identify key data structure, scheduling, and dispatching bottlenecks of the GHC IO manager. We then design a new multicore IO manager named Mio that eliminates all these bottlenecks. Our evaluations show that the new Mio manager improves realistic web server throughput by 6.5x and reduces expected web server response time by 5.7x. We also show that with Mio, McNettle (an SDN controller written in Haskell) can scale effectively to 40+ cores, reach a throughput of over 20 million new requests per second on a single machine, and hence become the fastest of all existing SDN controllers.

show abstract

“…In this section, we briefly review the operation of the threaded RTS and the GHC IO manager, which are presented in more detail in [10,11,15], respectively.…”

Section: Background: Ghc Threaded Rtsmentioning

confidence: 99%

Section: Per-core Dispatchersmentioning

confidence: 99%

Mio

Voellmy

Wang

Hudak

et al. 2013

Proceedings of the 2013 ACM SIGPLAN Symposium on Haskell

View full text Add to dashboard Cite

show abstract

“…This restriction makes it possible to deal with classical problems associated with parallel programming, such as deadlock or race conditions, in a transparent manner for the programmer. Libraries of this kind are Repa [16], DPH 5 [9,21], Accelerate [8], Monad-Par [20] and Sparks [18,19]. Following we highlight the main features of each of these libraries.…”

Section: Parallelism In Haskellmentioning

confidence: 99%

Towards a functional run-time for dense NLA domain

Blanco

Perdomo

Ezzatti

et al. 2013

Proceedings of the 2nd ACM SIGPLAN Workshop on Functional High-Performance Computing

View full text Add to dashboard Cite

We investigate the use of functional programming to develop a numerical linear algebra run-time; i.e. a framework where the solvers can be adapted easily to different contexts and task parallelism can be attained (semi-) automatically. We follow a bottom up strategy, where the first step is the design and implementation of a framework layer, composed by a functional version of BLAS (Basic Linear Algebra Subprograms) routines. The framework allows the manipulation of arbitrary representations for matrices and vectors and it is also possible to write and combine multiple implementations of BLAS operations based on different algorithms and parallelism strategies. Using this framework, we implement a functional version of Cholesky factorization, which serves as a proof of concept to evaluate the flexibility and performance of our approach.

show abstract

“…OCaml, MLton, and old version of Haskell use a hybrid of copying GC with mark-compact GC [7,31]. SML/NJ [29], Chez Scheme [14], and the latest Glasgow Haskell Compiler [23] use generational copying GC. In all these systems, the Cheney's copying collector is used for minor GC and object-moving is inevitable, which makes inter-operation with other languages cumbersome and error-prone.…”

Section: Related Workmentioning

confidence: 99%

An efficient non-moving garbage collector for functional languages

Ueno¹,

Ohori²,

Otomo³

2011

Proceedings of the 16th ACM SIGPLAN International Conference on Functional Programming

View full text Add to dashboard Cite

Motivated by developing a memory management system that allows functional languages to seamlessly inter-operate with C, we propose an efficient non-moving garbage collection algorithm based on bitmap marking and report its implementation and performance evaluation.In our method, the heap consists of sub-heaps {Hi | c ≤ i ≤ B} of exponentially increasing allocation sizes (Hi for 2 i bytes) and a special sub-heap for exceptionally large objects. Actual space for each sub-heap is dynamically allocated and reclaimed from a pool of fixed size allocation segments. In each allocation segment, the algorithm maintains a bitmap representing the set of live objects. Allocation is done by searching for the next free bit in the bitmap. By adding meta-level bitmaps that summarize the contents of bitmaps hierarchically and maintaining the current bit position in the bitmap hierarchy, the next free bit can be found in a small constant time for most cases, and in log 32 (segmentSize) time in the worst case on a 32-bit architecture. The collection is done by clearing the bitmaps and tracing live objects. The algorithm can be extended to generational GC by maintaining multiple bitmaps for the same heap space. The proposed method does not require compaction and objects are not moved at all. This property is significant for a functional language to inter-operate with C, and it should also be beneficial in supporting multiple native threads.The proposed method has been implemented in a full-scale Standard ML compiler. Our benchmark tests show that our nonmoving collector performs as efficiently as a generational copying collector designed for functional languages.

show abstract

Runtime support for multicore Haskell

Cited by 75 publications

References 25 publications

Mio

Mio

Towards a functional run-time for dense NLA domain

An efficient non-moving garbage collector for functional languages

Contact Info

Product

Resources

About