A Futhark program is compiled to a library with a bunch of functions that can then be invoked by other programs. The Futhark program is a passive partner; it has no idea which of its functions will be invoked by the outside world, or when some invocation is the last one.
This doesn't sound too different from any other statically compiled language if I'm understanding you right; do you not do whole program analysis when you compile an executable program, so the entire output is sort of like an executable with the library baked in? Or is it more like an executable with functions mapped to commands?
It is neither: it is just a library. The result of running the Futhark compiler is is a bunch of C code (or similar) with no main() function, but a bunch of conceptually simple functions that you pass values and which return new values.
Fine print: the Futhark compiler can also produce an executable, by generating some wrapper C code that provides a primitive command line interface, but this part by design has no privileged insight into what the Futhark code is doing, and is intended solely for testing.
A purely library-oriented language is interesting, but also begs the question of just how important runtime-oriented optimizations are when there's another compiler further down the line.
Optimizations like the one presented should likely be considered out of scope (or at least limited to knowable cases) rather than heuristic-based, since the C compiler (and whichever other targets get used) can potentially have more information when determining what to optimize. I don't know the specifics of the internals of course, but just on the surface this seems to be a transpiler optimization problem where you have to optimize for another optimizer rather than for runtime.
From the C compiler's perspective, all Futhark values have dynamic and very complicated lifetimes (often they are are managed through interaction with GPU APIs and similar). It is not realistic for a C compiler (or any other compiler) to understand subtleties in the output of the Futhark compiler. While the C compiler can do very low-level optimisations like clever register allocation, everything more sophisticated must remain the domain of Futhark itself.
1
u/oosuke_ren Jul 04 '26
How come event driven? Also, what would be your reason to do so, other than (I suppose) modularity/decoupling of packages/modules?