Troels Henriksens academic homepage
I am employed as tenure-track assistant professor at DIKU where I am part of the PLTC section. My research concerns parallel functional programming, high performance computing, and compiler construction.
I am currently teaching the following courses:
My personal homepage is sigkill.dk (or troelshenriksen.dk). I can be contacted at athas@sigkill.dk or athas@di.ku.dk.
My Google Scholar profile probably lists all of my academic publications.
My office is on Earth, Denmark, Copenhagen, Universitetsparken
5 (the HCØ Institute), room 772-01-0-S14. The last step is the
most tricky one. My office is located on the ground floor in
the "B" building (the one closest to the white DIKU building).
Follow the map below. You may find your way barred by a closed
door. If you are a student, your card may be able to grant you
access. Otherwise, ring the bell or call me.
I am willing to supervise BSc and MSc projects that are related to my own research, or on topics that happen to catch my fancy. The projects tend to be heavy on implementation and somewhat technically difficult, but most of my former students claim to have enjoyed it.
When filling out projects contracts and such, use the following information:
UCPH has an interesting procedure where I have to pretend to
sign your contract by copying an image of my signature into
your PDF file. As an optimisation, here is an image of my
signature so you can do it yourself:
If you wish to see me operate a fountain pen in person, you
can also come by my office with a printout of your contract.
The following is a (mostly historical) archive of various project proposals. The recent ones may still be current. If you are a student, and looking for a project, you can check these out to get an idea of the kinds of projects I supervise.
As examples of prior work,
see this
collection of Futhark-related student projects. Not all of
these were supervised by me.
AD
is a program transformation for computing
derivatives of arbitrary programs. It is
particularly useful for optimising cost functions
using gradient-based approaches, and is foundational
to modern machine learning. AD research is currently
a hot topic with many varying approaches. One
is Enzyme, an
implementation of AD on the low-level intermediate
representation used by
LLVM LLVM, one of the
most popular compiler infrastructures. The idea is
that if you have a compiler that can generate LLVM
(which is the case for most languages), then Enzyme
can differentiate the resulting code.
Futhark also
supports AD, as described
in AD
for an Array Language with Nested Parallelism. In
contrast to Enzyme, Futhark's AD transformation
operates on high level code, and in particular is able
to generate code whose parallel structure differs from
the original (so-called "primal") code. However, since
Futhark can also generate LLVM code, it is also
possible to use Enzyme to differentiate Futhark
programs.
Our hypothesis is that it is advantageous to perform
AD at a higher level, precisely so that we are not
bound by the structure of parallelism of the original
program. This project is about empirically
investigating to which extent this hypothesis is true.
The work will involve taking existing Futhark AD
benchmarks
(such
as these), compare their performance when using
Enzyme and Futhark's built-in AD, and investigate in
detail the reason for any performance differences.
The main programming challenge is the use of Enzyme,
in particular applying it to the GPU code generated by
Futhark. Explaining the performance differences will
also involve knowledge of high performance
programming, although the project is somewhat flexible
in how far one goes in this direction.
Assuming the project is completed to a reasonable
level, it can form the basis of a scientific
publication, as there is little existing work on
comparing AD on high level and low level languages.
The Problem
Based Benchmark Suite is a collection of benchmark
programs written in parallel C++. I am interested in
porting them to Futhark such that they can be added to
the existing
collection of benchmarks. Some of the benchmarks are
relatively trivial; others are more difficult. It might
be a good idea for a project to combine a trivial
benchmark with a more complex one.
The list
of benchmarks is here. The ones listed as Basic
Building Blocks are all pretty straightforward, but
not large enough to serve as a project on their own.
Look at the others and pick whatever looks interesting.
Particularly interesting are the ones related to
computational geometry:
This project involves becoming familiar with data
parallel programming and learning how to rephrase
(typically) task parallel algorithms in the data
parallel setting, usually also by flattening control
flow and data.
The Futhark
compiler currently supports regular nested data
parallelism, which is a form of parallelism where the
size of inner parallel dimensions are invariant to the
outer dimensions. Even though we are working on
supporting arbitrary irregular nested data parallelism,
this will never be as efficient as regular nesting.
Unfortunately, whether application parallelism is
regular or irregular is an implicit property, and it can
be hard for programmers to know when it occurs. This
project is about writing a static analysis tool that
takes as input a Futhark program and analyses it for
potential instances of irregular nested data
parallelism. This is a fun project if you enjoy working
with ASTs and devising algorithms.
AD
is a program transformation for computing derivatives
of arbitrary
programs. GradBench
is a project that investigates the performance of AD
tools for various languages. This project is about
implementing one or more of the GradBench benchmarks
in a new language or AD tool. For example, I am quite
curious about the effectiveness
of these
AD tools for Haskell, but you can pick whatever
language you wish, as long as it has some library or
tool that supports AD. The concrete work done in the
project is implementing the specified benchmark
problems, applying AD as best you can, then
benchmarking the resulting programs.
The Futhark
compiler uses a traditional parser architecture, based on
the Happy
parser generator that stops at the first error and is
unable to produce a parse tree in case a syntax error
occurs. This means the compiler and related tools, such as
the Language Server and formatter, is unable to provide
any information when the program has a syntax error. This
is not ideal, as it is common for programs to have
intermittent syntax errors while working on them.
Happy recently grew support
for error
recovery, which has already been used to
modify GHC.
This project is about adding a similar form of error
tolerance to the Futhark parser, and as time permits,
investigating how to modify programs such as the type
checker and formatter to handle incorrect programs.
Although the Futhark compiler is written in Haskell, it is
not expected that this project requires particularly fancy
Haskell programming. It is a good project for students
interested in parser theory and practice.
Current list of project proposals
Beyond the list below, see also
the list
of student-viable projects on the Futhark issue tracker.
These are all projects about contributing directly to a real
open source project. Not all of them are large enough to serve
as, for example, a master's thesis on their own. Others are
perhaps too challenging for a bachelor's thesis unless you are
a particularly skilled programmer.
This section contains suggestions for where to go next if you liked a course that I have been involved with; particularly which other related courses would be worth taking, or who to contact to do a related BSc or MSc project. Use the Course Search to look up further details.
While I use a lot of the HPPS material in my own research, most of my projects also involve significant amounts of material related to functional programming, programming language theory, or compiler construction. For projects centered in the HPPS material, David Gray Marchant is a more suitable supervisor.
Many researchers at DIKU are willing to supervise projects related to functional programming or more generally the theory of programming. If you find monads or type systems particularly interesting, consider contacting Andrzej Filinski. Ken Friis Larsen is interested in most unusual uses of Haskell
For electronic communication, use email. I prefer athas@sigkill.dk for various reasons. Rationale: This saves me from having to search a multitude of communication mediums whenever I need to figure out the context of our conversation. As a special case, feel free to contact me on IRC, because IRC is a pleasant medium.
If your project involves modifying a program maintained in a Git repository (such as Futhark), use a feature branch for your project and issue a pull request against the main repository. Rationale: Using a distinct branch names makes it much easier for me to help you by checking out your code as a local branch, and issuing a pull request enables use of GitHub's tools for code review.
Feel free to write me emails with questions whenever you have any. I will respond as I am able.
When you desire feedback on your report, tell me specifically which part you want me to read, especially when I have previously given you feedback.
Read Writing for Computer Science. Most of my advice would just be less precise parts of what I remember from that book. I also recommend reading How to Write a Great Research Paper, although it is primarily concerned with research papers.
There are no formal requirements for length or formatting, but do exercise common sense. See this list of student projects for examples. A BSc thesis is often about 25 pages, and a MSc thesis about 50 pages, but the variance is large. Shorter is better.
Do not include your source code (if any) as an appendix to your report. You can attach it to your handin if you wish (please no tarbombs), but referencing some public location, such as GitHub or Codeberg, is also perfectly acceptable.
If you wish, you can use this LaTeX template. Note that there are obsolete versions circulating (full of encoding errors), but the one linked above should work.
A bachelors project defense is about 20 minutes of presentation, followed by 20 minutes of the censor and I asking questions. A master's thesis is about 25 minutes of presentation and 25 minutes of questions. For a joint defense, each student beyond the first adds about 5 minutes.
Make sure to check in advance that your electronic equipment works. It is your reponsibility to bring whatever dongles you need.
Use black text on a white background for your slides. The lighting conditions are usually not good enough for white-on-black to be legible.
There is no requirement for any specific presentation tool. Use something you are comfortable with. Most students use Beamer. Very cool students use Patat or write their own presentation software.
If you wish to use Beamer, note that it defaults to an aspect
ratio of 4:3, which is obsolete even on UCPH's projectors.
Use \documentclass[aspectratio=169]{beamer} to
enable a modern 16:9 aspect ratio. There is a UCPH beamer
template circulating. Do not use it! It is extremely
ugly. Also, remember to disable the navigation buttons that
Beamer inexplicably places on
slides: \usenavigationsymbolstemplate{}
Have your code (if applicable) and report at hand to show on the projector, in case we want to point to specific parts in our questions.
Feel free to invite friends, family, lovers, enemies, colleagues, or anyone else you wish to your defense, but let me know well in advance so I can book a room with sufficient capacity.
The purpose of the defense is to evaluate your dissemination skills. The presentation part is slightly artificial, as both censor and I will have read your report in advance, so you do not have to exhaustively describe the background, context, or every technical detail. My advice is to superficially cover every main aspect of your work, then pick a single technical detail that you discuss in depth.
We may ask questions about any part of your work, not just your presentation.
It is permissible to present new work at the defense. This can be anything from additional experimental data, to solving a problem that was unsolved at the report deadline.
For guidance on how to give a good presentation, see How to Give a Great Research Talk.