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

Cleanup, optimize, and snapshot witness generation #631

Open
jprider63 opened this issue Apr 2, 2025 · 1 comment
Open

Cleanup, optimize, and snapshot witness generation #631

jprider63 opened this issue Apr 2, 2025 · 1 comment

Comments

@jprider63
Copy link
Contributor

  1. There are likely parts of the risc-v emulation that is not being used. Clean this up and remove unused parts.
  2. Run benchmarks, flamegraphs, etc for risc-v emulation and optimize any low hanging fruit here. Potentially follow the Succinct's RISC-V Emulator Challenge to see if there are any ideas we can use here.
  3. Implement snapshotting of trace generation. During the first run, snapshot the CPU state and memory every N steps. Then add the ability to rerun the emulation from a snapshot, producing a stream of the trace. (this task should likely be in a separate PR)

@benoitrazet @zutshi

@moodlezoup
Copy link
Collaborator

Adding some color here:

  1. There are likely parts of the risc-v emulation that is not being used. Clean this up and remove unused parts.

In particular, I think a lot of the stuff in tracer/src/emulator/device/ is unused, as none of those devices exist in the context of a zkVM guest program

  1. Run benchmarks, flamegraphs, etc for risc-v emulation and optimize any low hanging fruit here. Potentially follow the Succinct's RISC-V Emulator Challenge to see if there are any ideas we can use here.

Similar to what we do in jolt-core, I'd suggest instrumenting the code with tracing decorators and spans, writing some benchmarks (including some longer execution traces, i.e. >2^24 steps), and analyzing the resulting flamegraphs in Perfetto.

  1. Implement snapshotting of trace generation. During the first run, snapshot the CPU state and memory every N steps. Then add the ability to rerun the emulation from a snapshot, producing a stream of the trace. (this task should likely be in a separate PR)

I envision modifying the trace function to have the following signature:

pub fn trace(
    elf: &PathBuf,
    inputs: &[u8],
    input_size: u64,
    output_size: u64,
    checkpoint_interval: Option<usize>
) -> (Vec<RVTraceRow>, JoltDevice, Option<Vec<TraceCheckpoints>>)

and introducing a new function that looks roughly like this:

pub fn trace_from_checkpoint(checkpoint: TraceCheckpoints) -> impl Iterator<Item = RVTraceRow>

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

No branches or pull requests

2 participants