Open JasonGross opened 1 year ago
I've suggested dropping Java targets before. I am adamant that we should keep GarageDoor. We might consider dropping Curves, or splitting it out to a separate Coq CI job.
Overall, this question would be much easier to answer if I was able to query "how much time does the following make invocation take" without rebuilding.
The CI job that is timing out is the one that builds only .v files. There is a separate one for making sure the extracted OCaml code compiles which builds standalone-ocaml lite-generated-files
.
Overall, this question would be much easier to answer if I was able to query "how much time does the following make invocation take" without rebuilding.
You can get the timing data from the bottom of all-except-generated
on any successful CI run, for example starting on this line. If you do something like git ls-files "*.v" | xargs touch
and then do make --dry-run $target
, combined with grep COQC
or similar, you should be able to get a list of the .v files built. You can then grep the timing table for those particular targets and add them up.
Here is the timing table from the most recent successful Coq CI run of fiat-crypto. Note that we're just 3 minutes under the 3h timeout there.
or splitting it out to a separate Coq CI job.
I don't think the Coq devs will be happy with this solution. The 3h timeout is set by the devs, and see, e.g., https://github.com/coq/coq/pull/16968#issuecomment-1344308607
Curves/*
are probably redundant as test cases, perhaps the thing to do is to keep one use of par:abstract and EdwardsMontgomery
which is the most interesting one
- can ExtractionOCaml not be a part of this target?
I would like to keep this, because not many developments test Extraction. (And plausibly we should ask the Coq devs to speed up extraction?). We might be able to build the extraction files in parallel though.
- is to keep one use of par:abstract
Pierre Marie recently had to disable par
altogether on the Fiat Crypto CI because it was too memory hungry. So we're only testing par in serial mode, and maybe it's better to just move a dumb test into Coq's test-suite if there isn't already one
The other points sound good, can we make some relevant targets?
I think we should stop pretending these targets make any sense and just have a coq-ci
target (and ideally get rid of all other halfway targets with the possible exception of curves).
Build time visualization: https://andres.systems/tmp/time.html
Script:
I think for the testing of Coq, it is a good idea to include a small slice of each major category.
Do you think Fancy code is valuable enough as a fiat-crypto test even to justify maintaining and building it just for that purpose?
We've been timing out a bunch on Coq's CI recently, and I imagine #368 makes things a bit worse (though not much worse). Perhaps we should offer some target that does not build everything for Coq's CI to use? Thoughts? (@andres-erbsen ?)