Expand generic field usage #272
Conversation
| // no-op base case | ||
| } | ||
|
|
||
| // TODO: This generates butterfly functions up to $n = 32, but will panic if $n |
There was a problem hiding this comment.
I am generating butterfly functions up to $n = 32, but for some fields (e.g. baby bear) these aren't all legal and some will panic. Would it be better to return Options and handle bad calls?
| } | ||
|
|
||
| #[cfg(feature = "host")] | ||
| mod host { | ||
| use super::*; | ||
| use crate::adapter::{PolyExt, PolyExtContext}; | ||
|
|
||
| pub struct CpuVerifyHal<'a, S: Sha, C: PolyExt> { | ||
| // TODO: Not certain how best to handle the unused Field that's needed to |
There was a problem hiding this comment.
The CpuVerifyHal needs to know which Field elements it will be working with, but it doesn't actually directly use the field -- is this the right design for providing that information?
There was a problem hiding this comment.
I think you can use PhantomData for this purpose.
https://doc.rust-lang.org/std/marker/struct.PhantomData.html
Something was wrong with the perf after FRI field genericization, so reverting for now
|
The updates in FRI broke performance, so I have reverted them for now; I'm looking into reapplying them without taking a perf hit. |
This is accessible with the --prof-out option of r0vm, or by using risc0_zkvm::host::profiler::Profiler. It produces output in a format suitable for use with google's pprof, but does not yet supply full stack traces.
This reverts commit b7e13a2.
|
Thank you to @shkoo for using his new perf tool to track down the performance loss in FRI! |
Move forward replacing hardcoded baby bear with generic field (that for now is generally still baby bear). At this point the non-genericized code is largely limited to the automatically generated circuit code and the adapter code that interfaces with it.
I have design questions / uncertainties on a few details, which I'll call attention to with inline comments.