Futhark 0.2.0 released
We have just released the second version of the Futhark compiler, version 0.2.0 (as always, source tarballs are here). The linked page also contains a detailed changelog. Compared to the first version, no major compiler optimisations have been added. Instead, we have focused on various quality-of-life improvements, in anticipation of upcoming human trials in a course on Parallel Functional Programming at our department. I’d like to highlight and elaborate on some of these changes:
- Run-time errors due to failed assertions now include a stack trace
What it says on the tin. We implemented this in a rather hacky way, without having to keep around stack information at runtime, by relying on the fact that the Futhark compiler currently performs aggressive inlining of all functions. This allows us to compute “stack traces” at compile time, and simply annotate every possible error location. We will have to improve this in the future, but it works well enough for now.
- ``scatter`` expressions nested in ``map``s may now be parallelised (“segmented scatter”)
This is an exotic improvement that will become more important once we start performing more speculative parallelisation. For now, the main consequence is that the library implementation of radix sort can be mapped in parallel, which can be used to compute row medians.
- Size annotations may now refer to preceding parameters
We could previously define
let replicate 't (n: i32) (x: t): *[n]t = i32.replicate n x
But we could only describe the type (in e.g. module types) as:
val replicate: 't: i32 -> t -> *t
because function types could not contain parameter names. With this change, we can give the more detailed type of replicate:
val replicate: 't: (n: i32) -> t -> *[n]t
This makes the generated documentation <https://futhark-lang.org/docs/futlib/array.html>_ slightly more readable.
- Record syntax and semantics were improved and simplified
We wrote an entire blog post on this topic.
- ``f32.e`` is no longer pi
Remarkably, we defined e incorrectly for single-precision floats, but nobody noticed until now.