THE FOLD / CO-OP / THE SYNC / THE REMOTE CACHE
THE REMOTE CACHE
an agreement problem, not a storage problem
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A cache shared between machines only helps where the machines agree on what a build is. Every field added to the key to make it safer is a field that can differ, and each one splits the population.
LIT verified live. 4 machines. Keyed on OS and compiler: 2 groups, the largest sharing 3 machines. Add the build path: 3 groups, largest 2. Add the core count as well: 4 groups, largest 1 — every machine in its own group, and the shared cache is doing nothing at all.
LIT verified live. 4 machines. Keyed on OS and compiler: 2 groups, the largest sharing 3 machines. Add the build path: 3 groups, largest 2. Add the core count as well: 4 groups, largest 1 — every machine in its own group, and the shared cache is doing nothing at all.
2 HOW IT WAS WEAVED · AI + HUMAN
This is why remote-caching build systems go to such lengths to make actions path-independent and to normalise the environment — the sharing is the product, and the key is what destroys it.
AVAN (AI) included the core count, which cannot affect a correct build’s output. It is in the key of many real systems anyway, put there defensively, and it costs everything: 3 machines sharing becomes 1.
AVAN (AI) included the core count, which cannot affect a correct build’s output. It is in the key of many real systems anyway, put there defensively, and it costs everything: 3 machines sharing becomes 1.
3 ONE DIMENSION
Four machines, three keys, less and less sharing.
4 TWO DIMENSIONS · INTERACTIVE
Add a field to the key and watch the groups split.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: a population splitting.
AVAN’s addition (the inverse-companion): the forward reading is that a precise key makes remote caching safe. The inverse is that a perfectly precise key makes it useless. The limit of adding fields is a key that identifies the machine, at which point every entry has exactly one possible reader and the cache is a local cache with extra network. Read backwards, remote caching is not a storage problem — it is an agreement problem, and the useful key is deliberately less precise than the truth, by exactly as much as everyone can be persuaded to tolerate.
LIT 4 machines keyed on OS and compiler form 2 groups with the largest sharing 3 machines, adding the build path gives 3 groups with a largest of 2, and adding the core count as well gives 4 groups with a largest of 1 - every machine in its own group, and the shared cache doing nothing at all
FIG This is why remote-caching build systems go to such lengths to make actions path-independent and to normalise the environment - the sharing is the product, and the key is what destroys it. AVAN included the core count, which cannot affect a correct build's output. It is in the key of many real systems anyway, put there defensively, and it costs everything: 3 machines sharing becomes 1.
FIG This is why remote-caching build systems go to such lengths to make actions path-independent and to normalise the environment - the sharing is the product, and the key is what destroys it. AVAN included the core count, which cannot affect a correct build's output. It is in the key of many real systems anyway, put there defensively, and it costs everything: 3 machines sharing becomes 1.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE SYNC · David Lee Wise (ROOT0), with AVAN