New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache the relevance flag in rel contexts in an efficient way. #11152
Conversation
Also, @SkySkimmer next time you use lists for an access-based data structure, you'll be publicly whipped against the Wall of Complexity™. |
Maybe worth resurrecting the question of how to add regression tests for complexity? |
Here is a less invasive version that relies on a somewhat hidden invariant of the reduction machine: every rel variable known in the context of the fconstr creation is static, and only those introduced after are handled in an untyped way. Thus we simply reuse the environment to check irrelevance of I wouldn't mind somebody double-checking my DeBruijn mangling though, we've been bitten enough times never to be overly cautious... |
(If people are fine with this variant I'll squash before merging.) |
I am running a bench, just in case: https://ci.inria.fr/coq/view/benchmarking/job/benchmark-part-of-the-branch/806/. |
@ppedrot can this invariant and the dependence be documented? I'm assuming this is what justifies using the empty range in some places, but that's a total guess on my part and I can imagine someone coming in and thinking it's suspicious and not realizing it's okay because of this invariant. (Or breaking this invariant and being confused.) I think dropping the text you already wrote in a comment in a relevant place would already be much better than nothing. |
This invariant is not specific to the irrelevance marks. I think we can document it somehow, even though I have no idea about the actual invariants of the conversion machine. We do seem to be preserving that global rels are compiled to (To give a terrifying example, conversion does not preserve the fact that the two terms being compared have a common supertype. This is close from preventing me to sleep at night.) |
Rels that exist inside the environment at the time of the closure creation are fetched in the global environment, while we only use the local list of relevance for FRels. All the infrastructure was implicitly relying on this kind of behaviour before the introduction of SProp. Fixes coq#11150: pattern is 10x slower in Coq 8.10.0
Bench said
|
The bench seems to show the impact of the PR is noise. @JasonGross where is the code that got slower? Is there a opam package to test? |
No opam package. I could probably bring https://github.com/mit-plv/reification-by-parametricity up to date and add it to the CI and opam; it's a bunch of performance benchmarks. As far as I know there is no significant use of this code in the wild, at present. The two bug reports have small examples though. |
(FTR, I consider this ready.) |
…ficient way. Reviewed-by: SkySkimmer
… efficient way.
… efficient way.
Fixes #11150: pattern is 10x slower in Coq 8.10.0
No test because performance tests suck in our infrastructure, but see @JasonGross's proposal.
Fixes #6502