What a rebuild is worth
Worth reading first: A factorisation kept past its date · Changing the condition number on purpose · The problem that arrives again.
Two essays in this field have measured how fast an object ages. Neither of them has said what the ageing is worth, and it turns out that the ageing is the smaller half of the question.
Here is the whole of the other half. Reusing a preconditioner saves a rebuild and costs extra iterations. Whether that is a good trade depends on how many iterations one rebuild is worth, and that number is a property of the code rather than of the matrix: it is different for a dense Cholesky, an incomplete factorisation, a multigrid hierarchy and a fill-reducing ordering with a symbolic phase, and it can differ between them by two orders of magnitude on the same problem.
So the same sequence has several right answers, one per object, and none of them is discoverable from the sequence.
The currency
Every reuse decision is a ratio, so the honest thing to do is to make the ratio the axis rather than bury it in a flop model.
A sequence is costed here in iteration-equivalents: the total number of preconditioned conjugate gradient iterations, plus the number of rebuilds times a setup ratio. The ratio is what one rebuild costs in units of one iteration, and for the objects a real code holds it runs over a wide range:
- a dense Cholesky at n = 80 is n³/3 against 4n² a step, which is n/12 — 6.7 iterations;
- an incomplete factorisation of a sparse operator is a few matrix passes, so a handful;
- a multigrid hierarchy — coarsening, interpolation operators, coarse-grid assembly — is tens;
- an ordering with a symbolic phase, on a distributed machine where it also decides which processor holds what, can be hundreds.
The measurement is the same twenty-four-member sequence, walked at eight fixed rebuild periods and four growth rules, and then costed at each of six setup ratios. Nothing about the sequence changes between the columns. Only the exchange rate does.
Six answers
| a rebuild is worth | cheapest period | its cost | never rebuild | rebuild every member |
|---|---|---|---|---|
| 5 iterations | every member | 170 | 1,161 | 170 |
| 10 | every 2 | 259 | 1,166 | 290 |
| 20 | every 3 | 356 | 1,176 | 530 |
| 50 | every 6 | 542 | 1,206 | 1,250 |
| 100 | every 8 | 727 | 1,256 | 2,450 |
| 200 | every 12 | 1,008 | 1,356 | 4,850 |
The optimum walks steadily from one to twelve. At the cheap end, rebuilding at every member is correct and there is no interesting decision to make — which is worth knowing, because it means the dense Cholesky of the previous essays, at 6.7, sits in the regime where the answer is always to rebuild and the reuse question does not arise.
At the expensive end the decision is worth a factor of nearly five: 1,008 against 4,850 for rebuilding every time. And never rebuilding at all is between four and seven times worse than the optimum at every ratio in the table, which is the other thing the figure says — the ageing is real, and no setup cost in this range makes ignoring it correct.
The free rule, and where it stops
The previous essays each found a rule that reads something the iteration already computed and beats every constant. The obvious rule here is the same shape: rebuild when a solve takes more than γ times what the first solve after the last rebuild took. It needs no drift rate, no norm, no eigenvalues, and the quantity it reads is a count the loop already has.
At γ = 1.5 it rebuilds four times over the twenty-four members. Costed:
| setup worth | growth rule | best fixed period | which wins |
|---|---|---|---|
| 5 | 328 | 170 | fixed, by 93% |
| 10 | 348 | 259 | fixed, by 34% |
| 20 | 388 | 356 | fixed, by 9% |
| 50 | 508 | 542 | the rule, by 6% |
| 100 | 708 | 727 | the rule, by 3% |
| 200 | 1,108 | 1,008 | fixed, by 10% |
It wins in the middle and loses at both ends, and the reason is one line: it rebuilds four times whatever a rebuild costs. The number of rebuilds it chooses is a function of the ageing alone, because the ageing is all it can see. At a setup worth 5 the right answer is twenty-four rebuilds and it does four; at a setup worth 200 the right answer is two and it does four.
Why this is worth saying rather than fixing
The obvious repair is to tell the rule the setup ratio. That is correct and it is also the end of the interesting part, because a rule that has been told the setup ratio is a rule with a tuned constant in it, and this field has spent three essays on why a tuned constant is the thing to avoid.
What is worth carrying instead is the shape of the failure, because it is general.
A free measurement is free because something else is paying for it. The residual ratio in a Newton iteration is free because the iteration computes residuals; it happens to be the exact quantity the tolerance decision needs, and that is luck rather than design. The contraction ratio of a chord iteration is free for the same reason and is again exactly right, because the decision there is “is this factorisation still working” and the ratio is the answer.
The iteration count of a preconditioned solve is free too, and it is only half of what the decision needs. The other half — what a rebuild costs — is not a quantity any solve produces, is not visible in any residual, and does not appear anywhere in the iteration. No amount of watching the iteration more carefully will reveal it.
So the field’s reading, stated three essays ago, has a boundary and this is it: a rule that recomputes its decision from what the iteration is doing beats a constant when the decision is entirely about what the iteration is doing. Here it is half about the code, and the rule is half right.
Never rebuilding is the worst policy at every ratio
One column of the table deserves more attention than it usually gets, because it contradicts the way this decision is normally discussed.
The “never rebuild” column runs 1,161, 1,166, 1,176, 1,206, 1,256, 1,356 — barely moving, because a policy with one rebuild in it barely notices what a rebuild costs. And it is between four and seven times the optimum at every single ratio.
That is worth stating plainly because the usual framing of preconditioner reuse is how long it can be kept before something breaks, as though keeping it were the default and rebuilding were the expense. On this measurement the default is wrong. The sequence drifts, the iteration count climbs from 18 to 52, and a policy that never pays for a rebuild pays for it in iterations several times over — even when a rebuild is worth two hundred of them.
There is a regime where never rebuilding is correct, and the last section of this essay is about it. It is the regime where the sequence barely drifts, and the honest summary of the whole table is that both defaults are wrong most of the time and the decision is a measurement.
Two rules, two objects, two outcomes
It is worth putting this essay’s rule beside the one from the essay on a kept factorisation, because they are the same idea and only one of them works.
Both read a quantity the iteration produces for free. Both avoid a tuned constant. Both are scale-free. The chord rule wins at every drift rate measured; the growth rule wins at two setup ratios out of six.
The difference is not the quality of the rule, it is the shape of the failure it is guarding against. A stale factorisation stops working, and a rule that watches for it not working is watching the right thing: the cost of being wrong is unbounded on one side and small on the other, so the rule only has to detect the cliff. A stale preconditioner costs more, symmetrically, and detecting that it costs more is only half of a comparison whose other half is off-stage.
A rule can be free and right when the decision is one-sided. When both directions cost, the rule needs both prices, and a free measurement gives it one.
The sequence that needs no rule
There is one more case and it is worth drawing, because it is the regime most sequences are actually in and because the rule is wrong there too.
Slow the drift down by four orders of magnitude and the preconditioner never goes stale: one build serves all twenty-four members, never rebuilding is the cheapest fixed policy at every setup ratio, and every rebuild is pure waste.
The growth rule still rebuilds twice. Not because it detected ageing — there is none — but because the iteration count moves with the right-hand side. Two solves of the same matrix to the same tolerance take different numbers of steps depending on where b lands in the spectrum, and a rule watching that count cannot tell the variation from the ageing.
That is a third way to be fooled, and it is the one most likely to bite in practice, because the right-hand sides in a real sequence are not drawn from one distribution either.
Reading the table for a real code
The figure is a staircase over a synthetic ratio, and it is worth saying how somebody with an actual solver would use it, because the answer is not to read a period off the chart.
The ratio is measurable directly and cheaply: time one rebuild, time one preconditioned iteration, and divide. That is two measurements a profiler already has, and it is the only site-specific number the whole decision needs. Everything else on the figure — how fast the sequence drifts, how many members there are — is a property of the problem being solved rather than of the code, and the figure shows that the answer moves far more with the ratio than with either of those.
Two consequences follow that are worth stating separately from the measurement.
The right period is not portable between codes. The same sequence solved by two solvers with different setup costs has two different right answers, and a number carried across from one to the other is wrong by however far apart their ratios are — which the table puts at a factor of five in total cost at the extremes.
And it is not portable between machines. The ratio is a ratio of two timings, and the two scale differently: a setup that is largely symbolic and serial does not accelerate the way an iteration made of matrix–vector products does. A period tuned on one machine is a period tuned for that machine’s ratio, and this collection’s cost field has spent an entire run establishing that such numbers do not travel.
What is asserted
Four things, each with a case it must refuse.
That the optimum never falls as the setup gets more expensive — one, two, three, six, eight, twelve — and that it moves from rebuilding at every member to rebuilding once in twelve across the range measured.
That never rebuilding is several times worse than the optimum at every ratio, so the essay is not an argument for keeping things.
That the growth rule beats the best fixed period at 50 and 100 and loses at 5 and 200, which is the refusal: fed the claim that it wins everywhere, the assertion fails.
And that on a sequence with essentially no drift, the rule rebuilds anyway — which is asserted in the direction that says the rule is fooled rather than in the direction that says it agrees.
Shares its objects with
Essays that name at least two of the same things, and that neither author linked.
- A preconditioner that changes sign — both name condition number, conjugate gradients, preconditioning
- The part of a solver that may be rounded — both name conjugate gradients, preconditioning, stopping criterion
- The rate the condition number predicts — both name condition number, conjugate gradients, preconditioning
- The residual the method reports — both name condition number, conjugate gradients, stopping criterion
- Two dimensions, and the cluster that thins — both name condition number, conjugate gradients, preconditioning
- A correction cheaper than the problem — both name condition number, flop count
Named objects
A flat tag is an object no other essay names yet.
Cholesky factorisationCondition numberConjugate gradientsFlop countIncomplete factorisationMultigridPreconditioningStopping criterionWarm start