Skip to content
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

Process identities in order (if possible) #2323

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

georgwiese
Copy link
Collaborator

@georgwiese georgwiese commented Jan 10, 2025

Needed for the automatic pre-compile experiments @leonardoalt is running.

Changes the order in which runtime witgen for block machines processes identities.

The previous algorithm processed a given row like this:

progress = True
while progress:
  progress = False
  for identity in identities:
    progress |= process(identity)
  progress |= process(prover_queries)
  progress |= process(outer_query)

With this PR, we do this:

while round():
  pass

def round():
  if process(outer_query):
    return True
  if process(prover_queries):
    return True
  for identity in identities:
    if process(identity):
      return True
  return False

What this gets us is that an identity is only executed if no previous identity identity has made progress. The order of identities is the order in which it appears in the PIL (I think!). This allows us to control the order in which stateful machine calls, like memory accesses, are executed.

I guess this can make the solving of the first block significantly (afterwards, the sequence cache should remove any identities that did not lead to progress). As an upper bound, witgen for test_data/std/keccakf16_memory_test.asm takes 347s now (instead of 309 on main) :)

@georgwiese georgwiese force-pushed the process-identities-in-order branch from 24895e4 to d793c30 Compare January 10, 2025 03:09
@georgwiese georgwiese changed the title Process identities in order Process identities in order (if possible) Jan 10, 2025
@georgwiese
Copy link
Collaborator Author

There is one failing test. I just checked that it can be fixed by executing the outer query last (as was previously the case) instead of first.

This is probably some edge case we don't need to worry about in the RISC-V context. In the pre-compile case, we don't want to run the outer query after the memory accesses, because processing it is needed to receive inputs.

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.

1 participant