Recently, I posted on X and LinkedIn that I am always looking for excellent people to join my group. I received a lot of enquiries, some of which led to internship hires (yay!). But mostly, I seemed to offer similar advice. I thought I’d write a post that summarise my responses.
Off-CPU analysis is where the program behavior when it is not running is
recorded and analysed. See Brendan Gregg’s eBPF based off-CPU
analysis. While on-CPU
performance monitoring tools such as perf give you an idea of where the
program is actively spending its time, they won’t tell you where the program
is spending time blocked waiting for an action. Off-CPU analysis reveals
information about where the program is spending time passively.
A number of folks who regularly use OCaml were surprised to learn that you can reasonably debug OCaml programs using gdb. The aim of the post is to show the first steps in using gdb on OCaml programs.
Last semester at IIT Madras, I taught a revamped core course CS3100 Paradigms of Programming, which introduces 3rd-year students to functional and logic programming paradigms. While the course had been traditionally offered in Lisp and Prolog, I introduced OCaml instead of Lisp. All of the lectures were delivered through interactive Jupyter notebooks. The assignments were also distributed as Jupyter notebooks and evaluated through autograder facility in Jupyter. There has since been several requests to replicate this setup elsewhere. Hence, I thought I should write about the set up and experience of teaching through Jupyter notebooks.
Multiple Research Software Engineer positions are available in the Department of Computer Science and Engineering at the Indian Institute of Technology, Madras to develop Multicore OCaml and enable Tezos ecosystem to benefit from Multicore OCaml.
Multicore OCaml comes with a concurrent garbage collector, where the garbage collector and the mutator threads run concurrently. Debugging concurrent GC bugs has been the most frustrating / satisfying (when fixed) part of Multicore OCaml development. rr, a record and replay tool has made debugging concurrent GC bugs a sustainable exercise. In this short post, I’ll describe why.
I am chairing the PC for ML family workshop this year. The PC is happy to invite submissions for the workshop to be held during the ICFP conference week on Thursday 22nd August 2019.
ML family workshop invites submissions touching on the programming languages traditionally seen as part of the “ML family”. However, we are also keen to receive submissions from other related language groups. If you have questions about the suitability of your work for the workshop, please feel free to write an email.
It has been 3 months since I joined IIT Madras and it has been good fun so far. Along with the members of the RISE group, we’ve initiated a project to build secure applications on top of secure extensions of the open-source Shakti RISC-V processor ecosystem. Unsurprisingly, my language of choice to build the applications is OCaml. Given the availability of rich ecosystem of libraries under the MirageOS library operating system for building unikernels, we hope to minimise the amount of unsafe C code that the hardware has to contend with and protect exploits against. As a first step, we have managed to get OCaml programs to run on directly on top of the Shakti processor running in simulation under QEMU and Spike ISA simulators without an intervening operating system.
Over the past few weeks, at OCaml Labs, we’ve deployed continuous benchmarking infrastructure for Multicore OCaml. Live results are available at http://ocamllabs.io/multicore. Continuous benchmarking has already enabled us to make informed decisions about the impact of our changes, and should come in handy over the next few months where we polish off and tune the multicore runtime.
Andrej Bauer and I are editing a special issue of JFP on the theory and practice of algebraic effects and handlers. The CfP is below.