Skip to content

Conversation

ordinarymath
Copy link
Contributor

A huge amount of time is spent calling SPEC_ALL when adding the results of case_rwlist to the rewrites or simpset. By caching this expensive operation is now only done whenever the TypeBase is updated.

A huge amount of time is spent calling SPEC_ALL when adding the results of
case_rwlist to the rewrites or simpset. By caching this expensive operation
is now only done whenever the TypeBase is updated.
@ordinarymath
Copy link
Contributor Author

This significantly speedups my benchmark of word_to_stackProof in CakeML and is pretty much the main calls of SPEC_ALL in that file.

@tanyongkiam
Copy link
Contributor

Could you be more precise about what "significantly speedup" means quantitatively?

@mn200
Copy link
Member

mn200 commented Sep 24, 2025

Seems very plausible; I'm not sure I realised that this is what EVERY_CASE_TAC was doing (because “no-one should ever use that tactic” :) ; maybe with this change it won't be so egregious. (Exact numbers would be good.)

tot TypeBasePure.distinct_of tyi,
tot TypeBasePure.one_one_of tyi]

fun decompose (th::res) =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is simple enough that it's not a huge deal, but I was wondering why not just call Cond_rewr.mk_cond_rewrs or similar?

fun case_rwlist () =
itlist (fn tyi => fn rws => case_rws tyi @ rws)
(TypeBase.elts()) [];
case (!cache) of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should use the TypeBase's listener API (register_update_fn) so that you can see the new types arrive and add them to your cache rather than having to rebuild it every time. The stateful simpset does the same. (The ability to actually change the tyinfo value before it gets incorporated is interesting; but I'm not sure it's used, and if we dropped it, we could make the TypeBase code just use Listener.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to listen for when a type is deleted?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we made this an actual listener, the listener would be on a change type that included addition and deletion of info values. I don’t think there are many deletions in non-interactive uses, and having out-dated stuff in a cache isn’t likely to be much of a problem.

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.

3 participants