The inconsistency
| command |
--cc |
launchbound prune |
required |
launchbound model |
required |
launchbound tune |
[default: 8.6] |
$ launchbound prune reduce-flip
error: the following required arguments were not provided:
--cc <CC>
$ launchbound tune reduce-flip --backend model
reduce-flip — ESTIMATED tuning (analytical model, cc 8.6); ...
Why the default is on the wrong command
prune --cc's own help says:
Target compute capability for RC004 shared-memory context (docs/SAFETY.md): 8.6 for A10G, 7.5 for T4. A verdict at one --cc does not transfer to another.
If a verdict does not transfer between capabilities, then the capability is part of the answer — and tune is the command that produces an answer you act on. prune and model are inspection; tune is the one whose output you paste into a build.
So the tool currently insists you choose the device for the two commands where getting it wrong costs you a re-run, and picks one for you on the command where getting it wrong costs you a kernel tuned for someone else's GPU. A T4 user who runs launchbound tune and reads the result has an A10G answer, and the only place it says so is cc 8.6 in the middle of the header line.
RC004 is a shared-memory capacity check. A configuration admitted at 8.6 (164 KB/SM) can exceed the limit at 7.5 (64 KB/SM) — that is exactly the class of silent wrong answer the default enables.
Fix
Make tune --cc required too, matching prune and model. Three commands, one rule, and the rule is the one the safety documentation already states.
If a default is wanted for ergonomics, it should at minimum be announced rather than embedded mid-line — but requiring it is simpler and consistent, and the flag is one token.
--backend metal is a separate case: it has no gate at all (stated on every surface, correctly) and does not use --cc. Requiring --cc only for cuda and model would be defensible; requiring it always is simpler to explain.
Done when
--cc behaves the same way on all three commands, or the difference is documented in each one's help with the reason.
The inconsistency
--cclaunchbound prunelaunchbound modellaunchbound tune[default: 8.6]Why the default is on the wrong command
prune --cc's own help says:If a verdict does not transfer between capabilities, then the capability is part of the answer — and
tuneis the command that produces an answer you act on.pruneandmodelare inspection;tuneis the one whose output you paste into a build.So the tool currently insists you choose the device for the two commands where getting it wrong costs you a re-run, and picks one for you on the command where getting it wrong costs you a kernel tuned for someone else's GPU. A T4 user who runs
launchbound tuneand reads the result has an A10G answer, and the only place it says so iscc 8.6in the middle of the header line.RC004 is a shared-memory capacity check. A configuration admitted at 8.6 (164 KB/SM) can exceed the limit at 7.5 (64 KB/SM) — that is exactly the class of silent wrong answer the default enables.
Fix
Make
tune --ccrequired too, matchingpruneandmodel. Three commands, one rule, and the rule is the one the safety documentation already states.If a default is wanted for ergonomics, it should at minimum be announced rather than embedded mid-line — but requiring it is simpler and consistent, and the flag is one token.
--backend metalis a separate case: it has no gate at all (stated on every surface, correctly) and does not use--cc. Requiring--cconly forcudaandmodelwould be defensible; requiring it always is simpler to explain.Done when
--ccbehaves the same way on all three commands, or the difference is documented in each one's help with the reason.