-
Notifications
You must be signed in to change notification settings - Fork 19
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
chore: split out simp_mem to Arm/Memory/Common [1/?] #230
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bollu
force-pushed
the
simp-mem-mem-omega
branch
from
October 10, 2024 19:27
107c406
to
d79f376
Compare
shigoel
approved these changes
Oct 28, 2024
bollu
added a commit
that referenced
this pull request
Oct 29, 2024
…ga [2/?] This helps control how aggressive simp_mem is. I was hoping that we would see a major performance difference. We do see some evidence for improvement in the `Experiments/MemoryAliasing.lean` (the numbers are extremely consistent across runs: ``` lake build Proofs.Experiments.MemoryAliasing 2.86s user 0.34s system 92% cpu 3.466 total lake build Proofs.Experiments.MemoryAliasing 2.76s user 0.33s system 92% cpu 3.332 total ``` --- However, on the much larger `Memcpy.lean`, these types of considerations seem to just not matter: ``` lake build Proofs.Experiments.Memcpy.MemCpyVCG 31.79s user 0.81s system 99% cpu 32.878 total lake build Proofs.Experiments.Memcpy.MemCpyVCG 32.79s user 0.80s system 99% cpu 33.870 total ``` This is a tad disappointing, but such is life. Onward to the next refactor. This is stacked on top of #230
bollu
added a commit
that referenced
this pull request
Oct 29, 2024
…ga [2/?] This helps control how aggressive simp_mem is. I was hoping that we would see a major performance difference. We do see some evidence for improvement in the `Experiments/MemoryAliasing.lean` (the numbers are extremely consistent across runs: ``` lake build Proofs.Experiments.MemoryAliasing 2.86s user 0.34s system 92% cpu 3.466 total lake build Proofs.Experiments.MemoryAliasing 2.76s user 0.33s system 92% cpu 3.332 total ``` --- However, on the much larger `Memcpy.lean`, these types of considerations seem to just not matter: ``` lake build Proofs.Experiments.Memcpy.MemCpyVCG 31.79s user 0.81s system 99% cpu 32.878 total lake build Proofs.Experiments.Memcpy.MemCpyVCG 32.79s user 0.80s system 99% cpu 33.870 total ``` This is a tad disappointing, but such is life. Onward to the next refactor. This is stacked on top of #230
shigoel
pushed a commit
that referenced
this pull request
Oct 29, 2024
…ga [2/?] (#231) This helps control how aggressive `simp_mem` is, since `simp_mem` now no longer closes memory goals, but rather expects the user to manually invoke `mem_omega` when necessary. Another impact of this change is that we split `mem_omega` into two tactics: `mem_omega` that does not expose `pairwiseSeparate` goals, and `mem_omega!`, which does. This also helps control the performance of `mem_omega`, and hopefully, this ensures that the user is careful before exposing a full `O(n^2)` set of constraints to the user. --- I was hoping that we would see a major performance difference. We do see some evidence for improvement in the `Experiments/MemoryAliasing.lean` (the numbers are extremely consistent across runs: ``` ### Old timings lake build Proofs.Experiments.MemoryAliasing 2.86s user 0.34s system 92% cpu 3.466 total ### New timings lake build Proofs.Experiments.MemoryAliasing 2.76s user 0.33s system 92% cpu 3.332 total ``` --- However, on the much larger `Memcpy.lean`, these types of considerations seem to just not matter: ``` ### Old timings lake build Proofs.Experiments.Memcpy.MemCpyVCG 31.79s user 0.81s system 99% cpu 32.878 total ### New timings lake build Proofs.Experiments.Memcpy.MemCpyVCG 32.79s user 0.80s system 99% cpu 33.870 total ``` This is a tad disappointing, but such is life. Onward to the next refactor. This is stacked on top of #230
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
This will be used in the next paper to build
mem_omega
, which will be a finishing tactic that will use the full power ofomega
.simp_mem
will be restricted in power to only perform rewriting, allowing us to better controlomega
.Testing:
conformance succeeds
License:
By submitting this pull request, I confirm that my contribution is
made under the terms of the Apache 2.0 license.