guide: consider/explain exp push --run-cache (Sharing Exps)

[iesahin]

As some of the items in #2618 seems to need more tests and the completion of rearrangement in #2654, I'll be updating the requirements for the document here.

This issue is a cascading issue on top of #2367

Todo

• Test --run-cache for dvc exp push to see its effects
• Update index.md with links to "sharing experiments"

[jorgeorpinel]

Test --run-cache for dvc exp push

I'd ask the core team first to understand the intention of exp push --run-cache cc @pmrowla

[pmrowla]

It does the same thing as dvc push --run-cache. So the end result of an exp push --run-cache is that the git ref is pushed to your git remote and both dvc cache for the exp + run cache for the exp stages are pushed to your dvc remote.

In a collaborative environment, if users are sharing experiments, they may want to run the experiments themselves (whether it's with or without modifications). In these cases, it is still beneficial to have pushed/pulled run cache so that stages which someone else has already reproduced do not need to be re-run.

[iesahin]

It is similar to what I understood. Run cache keeps the intermediate stage outputs so that other dvc exp runs don't rerun them. Normally these intermediate outputs are not pushed, just the final outputs, but with --run-cache in dvc exp push, these are pushed as well. Right?

[pmrowla]

Run cache associates input state (a defined stage itself + its dependencies) with an output state (outputs) for a given stage. If DVC has the run-cache information available, and see's that the user is trying to run a stage where the current input state is in the cache, it will just skip the execution and dvc checkout the output state

Run cache is not really related to intermediate stage outputs

https://dvc.org/doc/user-guide/experiment-management#automatic-log-of-stage-runs-run-cache
https://dvc.org/doc/user-guide/project-structure/internal-files#run-cache

[iesahin]

Run cache associates input state (a defined stage itself + its dependencies) with an output state (outputs) for a given stage.

Run cache is not really related to intermediate stage outputs

:)

My emphasis is not on "intermediate", but the run cache keeps the stage state and updates the workspace without running if the same inputs + dependencies are given.

[pmrowla]

My point was in response to:

Normally these intermediate outputs are not pushed, just the final outputs, but with --run-cache in dvc exp push, these are pushed as well. Right?

Run cache does not include any outputs/data from your workspace. You can look at the structure of the run cache yourself (.dvc/cache/runs), but it's essentially just a mapping of the metadata you would see in dvc.lock files, where an input dvc.lock maps to an output dvc.lock. What gets pushed with dvc push --run-cache is that collection of lock files.

[jorgeorpinel]

So would you put this info in the Exp Sharing guide @iesahin ? Or somewhere else. What's the summary or key thing to document here? Thanks

[iesahin]

I think we may to tell this both in Running and Sharing, describing different aspects, but I still could not test this.

[jorgeorpinel]

K well maybe add a checkbox in #2768 instead and close this 🙂 Up to you