If you are interested in learning about the internals of the CompCert C compiler but would rather not read its source code, this post is for you.
The next edition of the New England Programming Language Seminar (NEPLS) will be held on Friday, October 7th at Northeastern University. Organizers are Gabriel Scherer and Max New. See you there!
Performance matters for software systems, but performance is not always easy to measure. At the PRL we recently had a scare with some unreliable measurements. Here is the story.
Racket is excellent for incrementally growing scripts into full-fledged programs. This post steps through the evolution of one small program and highlights the Racket tools that enable incremental advances.
In this post, we will experiment with some low-level operations with pointers, union types, and custom C types. The main takeaway will be the custom C types, which let you define abstractions that hide the details of the C representation when manipulating data in Racket.
Part 2 will continue with more Cairo examples. In this installment, I plan to go over some more advanced FFI hacking such as handling computed argument values, custom return arguments, and using C structs.
I’ve seen several people ask for a tutorial on Racket’s foreign function interface (FFI), which allows you to dynamically load C libraries for use in Racket code. While I think the documentation for the FFI is quite good, it is a lot of information to process and the overview examples may be tricky to run for a beginner.
With that in mind, this blog post will provide a step-by-step tutorial for Racket’s FFI that requires minimal setup. All that you will need to follow along is a copy of Racket and ideally a DrRacket window.
Are you interested in printed conference Proceedings? We have a good stack of them left away at Northeastern University (Boston, MA) and it seems that nobody wants them!
If you are a student, you should consider applying to become an ICFP 2016 student volunteer! The deadline for application is July 31st, 2016.
James Fisher has a blog post on a case where GHC’s runtime system imposed unpleasant latencies on their Haskell program:
The blog post proposes a very simple, synthetic benchmark that exhibits the issue — basically, latencies incurred by copy time — with latencies of 50ms that are considered excessive. I thought it would be amusing to reproduce the synthetic benchmark in OCaml and Racket, to see how other GCs handle this.
Without further ado, the main take-away are as follows: the OCaml GC has no issue with large objects in its old generation, as it uses a mark&sweep instead of copying collection, and exhibits less than 3ms worst-case pauses on this benchmark.
The Racket GC also does not copy the old generation, but its incremental GC is still in infancy (compared to the throughput-oriented settings which works well) so the results are less good. It currently suffer from a “ramp-up” effect that I will describe, that causes large pauses at the beginning of the benchmark (up to 120ms latency), but in its steady state the longest pause are around 22ms.
Please keep in mind that the original benchmark is designed to exercise a very specific workflow that exercises worst-case behavior for GHC’s garbage collector. This does not mean that GHC’s latencies are bad in general, or that the other tested languages have smaller latencies in general.
The implementations I use, with a Makefile encapsulating the logic for running and analyzing them, are available in a Gitlab repository: