You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are likely parts of the risc-v emulation that is not being used. Clean this up and remove unused parts.
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.
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)
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
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.
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:
@benoitrazet @zutshi
The text was updated successfully, but these errors were encountered: