For this post, I want to point out the most significant changes, and then spend a bit of time talking about my surprisingly good experiences using Futhark to solve problems from the. This release has no big feature additions or significant new optimisations, but instead contains smaller quality-of-life improvements and a great deal of bug-fixes. This is not because we have stopped working on major improvements - quite the contrary. Indeed, the primary purpose of this release is to make conservative improvements available before we start merging the more significant changes we are working on two new code generation backends and a rework of how parallel reductions are compiled. Sounds quite sequential, but can be solved efficiently with a parallel scan. As the problems continued to increase in complexity, I ended up writing these automatons quite frequently advent of code a brute-force solution. For this problem, however, I eventually ended up switching to simply checking, for each coordinate, the distance to all points. This is a highly sequential tree algorithm, which Futhark is totally unsuited for. I did end up making it work, though, using strictly sequential Futhark. While this problem can undoubtedly be solved in Futhark, it would require a level of manual stack management that I really cannot stomach. The problem is amenable to a parallel brute force solution although it takes 1. While dynamic programming techniques are often quite sequential, I managed to rewrite it to be based on prefix-summing first the rows and then the columns of a matrix. This was a wonderful problem and I am quite proud of my advent of code. It is mostly interesting because it exposed two compiler bugs and an interpreter bug. I implemented it as a 2D cellular automaton updating the entire world for every iteration, even though only a tiny fraction of cells those near the head of falling water will actually change. Brawns scale better than brains, sometimes. To avoid irregular arrays, I ended up padding to some assumes maximums. I did at one point give up and try to write it in Haskell instead, but eventually I went back to Futhark because I found it more fun. If I participate in Advent of Code next year, I will definitely prepare a generic breadth-first search in advance. In conclusion, I am surprised that Futhark actually managed to advent of code for me. Advent of code had expected that after a few simple problems, the remaining would require too many facilities that Futhark does not provide, but that did not happen. The limiting factor was generally my own intellect, not the language. It was nice to exercise parts of Futhark that normally do not see much use, in particular since that also allowed me to flush out a number of compiler bugs fortunately, they were all in the front-end and caused type errors or compiler crashes - debugging code generator bugs is a sure way to lose the Christmas spirit. I can definitely recommend inventing your own programming language and then solve Advent of Code problems with it.
