Skip to content

CI: let a cold CUDA profile warm its ccache from a sibling profile - #83

Draft
danielhanchen wants to merge 1 commit into
masterfrom
ci/ccache-sibling-profile-fallback
Draft

CI: let a cold CUDA profile warm its ccache from a sibling profile#83
danielhanchen wants to merge 1 commit into
masterfrom
ci/ccache-sibling-profile-fallback

Conversation

@danielhanchen

Copy link
Copy Markdown
Member

Adds a second, broader restore-keys entry to the CUDA and CUDA-Windows ccache steps, so a profile with no cache of its own falls back to a sibling of the same CUDA line and OS instead of building cold.

restore-keys: |
  cuda-${{ matrix.cuda }}-windows-${{ matrix.profile }}
  cuda-${{ matrix.cuda }}-windows-

Why it should work

Configure passes exactly one per-profile flag, -DCMAKE_CUDA_ARCHITECTURES="$archs". That affects .cu compilation only, so every plain C++ translation unit -- the large majority of the 887 -- has a byte-identical command line across cuda12-legacy/older/newer/portable. A sibling cache should therefore hit on all of them.

Scope

It only engages when the primary key misses entirely, so it cannot regress the normal path: with a cache of its own, the profile still restores its own. The cases it helps are a new profile, and a profile whose last save was lost.

Honesty about the evidence

Unlike the changes in #81 and #82, this one is not measured. It is a reasoned inference from the cmake flags, not an experiment, which is why it is separate and draft.

For contrast, here is what measurement produced on the other hypotheses, run locally against 513 real translation units:

hypothesis result
fresh tar extraction breaks ccache direct mode disproven -- 513/513 direct hits with empty sloppiness, identical with include_file_mtime,include_file_ctime
source gap drives the miss rate mostly disproven -- gap 13 still gives 91.4% with a full cache
a clipped cache drives it confirmed -- capping the cache to 30% of what the build needs gives 14.2% hit rate and flips hits from direct to preprocessed (13 direct / 60 preprocessed), which is the signature seen in CI (3 direct / 52 preprocessed)

So the real cause of the 6.2% was the 500 MB cap, already fixed in 4a03725. This PR is a smaller, separate improvement to cold-start behaviour.

Test plan

  • Confirm a normal run still restores its own profile cache (log line should name the profile-specific key)
  • Confirm a profile with no cache of its own restores a sibling rather than starting cold
  • Compare that cold-start build time against the current fully-cold path

Both workflow files parse, and restore-keys resolves to exactly two entries per step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant