Program Load vs. Program Install

I don’t think they ever explicitly ruled out caching or pre-converting the binaries. And the module load library sounds like a generic conversion tool wrapped by an easy to use load module, not some inflexible black box.

This is squarely an OS problem. The OS itself will have to make tradeoffs between startup time, install time, disk usage, portability, and cache complexity with regards to member-conversion. And it will use the mill conversion tool as it chooses between them.

From a “just get something working” developer’s standpoint, wrapping the conversion tool by a load module is the easiest way to plug the mill into an existing OS without rewriting or authoring new major subsystems.

So, just chill and be patient. 🙂

I see a couple of really interesting points raised here.

First, install-time vs load-time translation.

In the first talk on Instruction Encoding Ivan says that they do the translation at install time (at the 1 hour mark; Youtube’s transcript search feature helped me track it down; hope all the videos get transcripts eventually). He describes it in terms of the IBM mainframes too, as mentioned above.

(Added: and here is a second reference, in the second talk on The Belt)

They do have a lib to make the translation available at run-time too, e.g. for JIT, so I guess OS integration can pick and choose when to do it and if to persist it.

Secondly, using profiling data to retranslate the binary.

The Mill does actually take a small step on a similar path to this. In the talk on Prediction, its described how the branch predictor loads predictions from previous runs, and updates those predictions.

Presumably as the tooling improves, all the already-translated bitstreams can be retranslated with better optimisations via auto-upgrade built into your favourite OS/distro.

This isn’t all the way to annotating apps to gather profiling and then recompiling, but you could imagine this being an option in the overall toolchain. Its just a software thing, seems quite doable.

I hope I’ve tracked down the most relevant quotes; I have no more to go on than just what has been said in the published talks.

You guys got it right. The tool that produces binary is called the Specializer. It takes in serialized compiler internal representation and produces load modules or in-memory function bodies. The basic tool is an API, plus some wrappers to apply in different circumstances.

We expect that the normal case will Specialize at install time. However, the load module can cache several different specializations. If you (for example) upgrade your CPU chip to a different Mill family member then when you first run the program the loader will discover that there’s no specialization for the current host in the load module, and will do a load-time specialization on the fly; it’s much like load-time dynamic linking. The new specialization will then (assuming suitable permissions) will be cached back into the load module, so the next time the program is run the loader finds the desired specialization.

It is also possible to Specialize for an explicit target rather than for the current host. This is used to e.g. create a ROM for a different machine.

In general we do not expect to re-Specialize automatically based on the accumulated branch prediction information or other profile info; that would be an explicit manual step, or be under control of a higher-level framework such as an IDE. It’s not clear that respecializing would buy that much; code selection has already been done by the time that the Specializer gets at it, and operation scheduling (with a few exceptions, such as latency distribution in cascaded loads) does not appear to benefit much from profiles. However, the Specializer is also responsible for the layout of code in memory, so a profile could lead to improved cache behavior.