I'd put a lot of work into getting ready for my IFL talk. By the time I actually gave it, I felt lucky to remember any of the points I wanted to make.
Everyone says it went well. My memory of it is mostly exhaustion and brain fog, which is a rather frustrating return on all that preparation.
I was at IFL 2026, the Symposium on Implementation and Application of Functional Languages, from 28 to 30 October, at Aspenäs Herrgård in Lerum, a small place near Gothenburg. I took the Replay Lattice there to talk about floating-point reproducibility, and managed to bring a spectacularly badly timed cold along too.
In the run-up I'd been stressed and overworking myself, trying to get ready. There always seemed to be more preparation to do, and I wanted to be able to explain the work properly. Then, on the morning of the first day, I had the worst single-day cold onset I can remember.
By midday I had to retire to bed. I slept for something like eighteen hours, with my talk waiting for me first thing the next morning.
I would have appreciated a little more notice.
First thing the next morning
My talk was on 29 October, at the start of the second day. I'd wanted to arrive prepared, and now I had to deliver that preparation through a head full of fog. Knowing I'd worked on the material didn't make remembering it feel any easier.
I did give the talk, and the feedback from people afterwards was kind. I'm glad they thought it went well, because from inside my own head I was mainly aware of how worn out I felt. Those two accounts of the same presentation are going to have to coexist.
The talk grew out of the problem in Why changing the worker count changes the answer. I want to give a distributed job more resources without that decision choosing a new numerical result for me. The Replay Lattice lets a program express which floating-point results need to stay reproducible, so the compiler can follow that requirement through the calculation.
The slides are here, and the paper has its own page.
The evenings I missed
Everyone I met was really nice, which made being ill particularly annoying. I wanted more time to socialise with people, to keep a conversation going rather than disappearing back to bed. Instead, I spent a ridiculous amount of the conference asleep and missed all the dinners.
I regret that. Going somewhere full of people interested in the same sorts of problems, then being too sick to spend much time with them, feels like very poor use of the journey.
There are things I'd like to hear that aren't in a slide deck. What someone is stuck on, what they're excited about, which bit of their work has become more trouble than they expected.... Getting to know the people doing the work is part of why I wanted to go.
And, in a fine demonstration of Sod's law, I started recovering as soon as the conference ended. Apparently my cold had also consulted the programme, and had very strong opinions about which parts I should miss.
Two ideas to bring home
I came away with two useful ideas from the talks and discussions, well, one was a direction I'd already been resisting for months. The other was a suggestion for something new to build.
For the past few months I've been fighting with how much control I can keep over floating-point determinism while sending Floatyboat's generated code through a C compiler. Floatyboat is my array language and compiler, so whatever promise I make in the language has to survive the code generation underneath it.
The C compiler makes another set of choices after mine, which is uncomfortable when the order of floating-point operations is part of the promise I'm making. I'd rather choose the instructions that implement those operations myself.
I can keep tightening flags, inspecting generated code, pinning the toolchain and.... yes, this is starting to sound like another compiler project. I'd been trying to avoid the conclusion that I might need to generate machine code myself, but the conference helped me take that direction seriously.
I'm exploring it through Plan 10, an instruction-level backend where the operations have explicit rules about their result bits. The experiment is about choosing those instructions directly, rather than handing the arithmetic to a C optimiser. Floatyboat still has its C backend, and the remaining hardware and library behaviour needs attention of its own.
The other idea came from someone suggesting a script that could help explain why two computers give different floating-point answers. I like that suggestion, because having a disagreement is much less useful than knowing where to start looking for it.
I've started building that as fpcheck. It runs probes on each machine and saves a manifest, a record of the relevant settings and measured results. Comparing those records can show differences in processors, maths libraries, rounding settings or worker counts alongside computations whose result bits actually differ.
That distinction helps me decide what to investigate. A setting can suggest a reason for different answers, while a probe can show that a particular computation really did differ. To establish the cause I'd change the suspected setting and check again. Agreement on the probes only covers the computations they ran.
The Replay Lattice's schedule promise holds a build fixed. Comparing two computers reaches into the environment around that build too, so fpcheck gives me somewhere practical to investigate the questions outside that promise. I'm pleased that a suggestion made around the talk has already given me something to work on.
Next time
I can't wait to do it again. I'd like to spend more of the next conference talking to people and rather less of it sleeping, and I'd especially like to make it to dinner.
Next time, if my seasonal cold could arrange to arrive a few weeks before I leave, that would be much more convenient.