u/n00bombin r/haskell • Recommends
MuniHac 2018: Keynote: A low-latency garbage collector for GHC
0:00 / 0:00
#ghc#garbagecollection#low-latency
MuniHac 2018: Keynote: A low-latency garbage collector for GHC
TNG Technology Consulting GmbH
5K subscribers • 17 videos on Hallway
- Recommended by 1 person: 1 in engineering communities.
- Presented by Ben Gamari
Advanced. Deep dive for people who know the field.
3.8K views7 years ago1 recommendation
Systems programmingProgramming languagesCompilers and interpretersMemory managementPerformance and optimization
Ben Gamari provides an overview of the concurrent, non-moving garbage collector designed to reduce latency in the Glasgow Haskell Compiler.
Speaker: Ben Gamari Title: A low-latency garbage collector for GHC Abstract: As real-time and distributed systems become common-place, latencies associated with memory management begin to limit the usability of garbage collected languages. In particular, the Glasgow Haskell Compiler has long relied on a throughput-oriented copying garbage collector; while this collector provides good memory locality for user programs, minimal fragmentation, and efficient collection, it imposes large latencies when collecting large heaps. Recent language implementations (e.g. Go, Mono, various Java implementations) have moved away from have avoided the problem of garbage collection latency through use of concurrent collection on a non-moving heap. In this talk Ben will provide a high-level overview of a concurrent, non-moving garbage collector implemented for the Glasgow Haskell Compiler. This collector offers significantly improved pause times without the need for code recompilation and with minimal impact on program runtime. He will discuss the trade-offs implicit in the design, the challenges posed by collecting Haskell in particular, and present some preliminary performance measurements from a prototype implementation. Recorded at MuniHac 2018 / munihac.github.io by Maximilian Huber / TNG Technology Consulting GmbHWhy it's here
1 person recommends thisWhat people say. Highly recommended for its detailed explanation of GHC's concurrent, non-moving garbage collector design.
u/the-cootin r/haskell • Mentions
On “Shout-out to the giants”
There's also Well-Typed who are pushing ghc forward. Check the work on ghc's GC by Ben Gamari link to this video And let's not forget that SPJ works for Microsoft Research. There are also lots of CS university departments advancing the studies of lambda calculus (broadly speaking) - that's even better than any large corpo.
u/hardwaresoftonin r/haskell • Mentions
On “Why can't haskell have a completely concurrent GC?”
This video is a bit older but a good entrance into the space for Haskell:
MuniHac 2018: Keynote: A low-latency garbage collector for GHC
u/eacameronin r/haskell • Mentions
On “New hope for adopting FP even faster”
Speaking of GC, what is the status of the low-latency GC? [video
u/nh2_in r/haskell • Mentions
On “Shorter GC pauses coming to GHC”
Ben's talk explains it: link to this video
u/nh2_in r/haskell • Mentions
On “Is AMD threadripper 2 performance better than Intel in reagard to scaling?”
…ache locality will likely be bad and your CPU will wait on memory most of the time (this talk shows quite nicely some of these aspects).
There are many resources that talk about many of those issues. Some examples:
* Bad scaling of GHC itself: https://trofi.github.io/posts/193-scaling-ghc-make.html and #9221
* GHC's upcoming new concurrent GC: link to this video
* https://mazzo.li/posts/haskell-parallelizing.html
Of course you can plan to design hardware that works around these software bugs, but it'll likely be much more effective to just work directly on the bugs.
Modern CPUs can easily process 10-40 GB per second; if your application doesn't display that performance, there's likely something g…
u/raducu427in r/haskell • Mentions
On “New hope for adopting FP even faster”
You can find out more in this video [video