Futhark 0.25.35 released
Futhark 0.25.35 has just been
released (or perhaps
escaped).
I used to make a post like this for most releases, but it has actually been over
two years and 30 releases since the previous
announcement. Is this because Futhark
has stopped changing? In a way it is: we also have not had a change to the
middle version number (25) in two and a half years, which implies that the
language has been stable for that long. This means that programs written two and
a half years ago should still work, and in practice the changes made in 0.25.1
did not make many (if any) programs invalid - they merely extended what you can
do. Skimming through the changelog, it
seems that 0.22.1 was the most recent version to make a truly user-visible
change (by removing some prelude functions that nobody
used). In 0.21.1, we made def a
reserved word, which certainly broke some reasonable code. In 0.20.1 we fiddled
with some edge cases of unary operators (and made some related changes to the
prelude), which I think is perhaps the last gasp of Futhark’s once instability.
It really has been a fairly stable language for quite a while now.
That does not mean nothing changes, of course. Since Futhark in its current form is a pretty good (if still imperfect) language for data parallel programming, we do a lot of investigation into parallel algorithms where Futhark is merely a tool. William Henrich Due, a PhD student here at DIKU, has recently done work on data parallel algorithms for hash maps and union-find structures (draft paper on the former), a lot of which ends up in the containers package for Futhark.
Futhark itself also improves, of course. Version 0.25.35 has seen substantial
improvements in its tooling, mainly due to code contributions from
VegOwOtenks. In particular, futhark profile now
produces far more useful information, such as heat maps of the program source
code, that shows where the run-time is spent. This has already proven useful
during human trials in our course on data-parallel
programming, where some students used
it to analyse the code they wrote as part of their final projects. The work is
built on top of the improvements to tracking source
locations made last year, although
there are still cases where it does not work so
well. VegOwOtenks has also
added additional features to Futhark’s language server (exposing the
formatter), and judging by the open pull requests,
will make several more. The language server was written by a
student in
the first place, and is perhaps the most prominent component of Futhark that is
primarily written by non-core hackers (although I certainly use it every day
through Eglot).
Another nice improvement is by Amirreza Hashemi, a student at
DTU, who improved the implementation of scan for the
multicore backend through an approach described in this
paper, which is largely written
by the contributors to Accelerate. This was
quite thorough work, that explored some of the edge cases about what should be
done when the operator or input preprocessing is complicated. I think some work
remains to be done here, but scans are in most cases quite a bit faster now,
which is always good.