Prepare to call jit from block machine. #2098
Conversation
| Self { data, row_offset } | ||
| } | ||
|
|
||
| pub fn get(&self, row: i32, col: u32) -> T { |
There was a problem hiding this comment.
Not sure if the 32 bit values here provide a performance advantage. Any opinions?
| @@ -13,7 +13,7 @@ use crate::witgen::rows::Row; | |||
| /// Sequence of rows of field elements, stored in a compact form. | |||
| /// Optimized for contiguous column IDs, but works with any combination. | |||
| #[derive(Clone)] | |||
| struct CompactData<T: FieldElement> { | |||
| pub struct CompactData<T: FieldElement> { | |||
There was a problem hiding this comment.
| pub struct CompactData<T: FieldElement> { | |
| pub struct CompactData<T> { |
|
|
||
| pub fn set(&mut self, row: usize, col: u64, value: T) { | ||
| let idx = self.index(row, col); | ||
| assert!(!self.known_cells[idx] || self.data[idx] == value); |
There was a problem hiding this comment.
Does this mean that we sometimes set the same value twice?
There was a problem hiding this comment.
Or that there's a default value?
There was a problem hiding this comment.
It's OK to set the value twice if it's the same value. We can maybe make this more strict later, though.
The "default" value is "not known", internally it will be represented by zero.
| /// A mutable reference into CompactData that is meant to be used | ||
| /// only for a certain block of rows, starting from row index zero. | ||
| /// It allows negative row indices as well. | ||
| pub struct CompactDataRef<'a, T: FieldElement> { |
There was a problem hiding this comment.
| pub struct CompactDataRef<'a, T: FieldElement> { | |
| pub struct CompactDataRef<'a, T> { |
?
| @@ -70,6 +71,9 @@ pub struct BlockMachine<'a, T: FieldElement> { | |||
| /// Cache that states the order in which to evaluate identities | |||
| /// to make progress most quickly. | |||
| processing_sequence_cache: ProcessingSequenceCache, | |||
| /// The JIT processor for this machine, i.e. the component that tries to generate | |||
| /// witgen code based on which elements of the connection are known. | |||
| jit_processer: JitProcessor<'a, T>, | |||
There was a problem hiding this comment.
| jit_processer: JitProcessor<'a, T>, | |
| jit_processor: JitProcessor<'a, T>, |
?
| ) -> Vec<LookupCell<'c, T>> { | ||
| self.left | ||
| .iter() | ||
| .zip(input_output_data.iter_mut()) |
There was a problem hiding this comment.
Would zip_eq hurt performance?
| @@ -215,6 +273,41 @@ impl<T: FieldElement> FinalizableData<T> { | |||
| } | |||
| } | |||
|
|
|||
| /// Returns an iterator over the values known in that row together with the PolyIDs. | |||
| pub fn known_values_in_row(&self, row: usize) -> Box<dyn Iterator<Item = (PolyID, T)> + '_> { | |||
There was a problem hiding this comment.
I'm just wondering if we need the dynamic output, can self.location_of_row(row) be anything in practice?
This PR performs preliminary preparations in the block machine so that it will be able to JIT-compile and evaluate lookups into this machine given a certain combination of "known inputs".