Revive profiler, add docs, cleanups #518
Conversation
Benchmark for Linux-cuda a723e45Click to hide benchmark
Benchmark for Linux-default a723e45Click to hide benchmark
Benchmark for macOS-default a723e45Click to hide benchmark
Benchmark for macOS-metal a723e45Click to hide benchmark
|
| @@ -40,6 +40,13 @@ struct Args { | |||
| /// Add environment vairables in the form of NAME=value. | |||
| #[clap(long, action = clap::ArgAction::Append)] | |||
| env: Vec<String>, | |||
|
|
|||
| /// Write "pprof" protobuf output of the guest's run to this file. | |||
There was a problem hiding this comment.
It might be nice to show a end-to-end example set of commands in a r0vm crate level README ( and/or landing page for crates.io) of how to use profiling / other features of r0vm so its a little more accessible to users.
| pub use self::receipt::{SegmentReceipt, SessionReceipt}; | ||
| #[cfg(feature = "prove")] | ||
| pub use self::{ | ||
| exec::io::{Syscall, SyscallContext}, |
There was a problem hiding this comment.
yay! Would it make sense to write a MultiTest for using a custom syscall? I would be interested in writing it if we need something like that to test the user facing API.
There was a problem hiding this comment.
MultiTest doesn't really test the external API, it really just tests the host/guest interaction.
There was a problem hiding this comment.
I'm also not super keen on exposing the Syscall interface directly, I think there are usually better ways to extend the host/guest (like using I/O). If we can drop this re-export I'd prefer to.
There was a problem hiding this comment.
I am also happy with that.
No description provided.