feat(avm)!: smaller precomputed trace

[jeanmon]

This PR performs the following changes (kudo to @fcarreiro for suggesting this):

• precomputed.clk is non-zero only on the active portion of the precomputed subtrace
• Introduce a clk column in execution sub-trace (counter on active rows). For each execution dispatching lookup using precomputed.clk, we replace precomputed.clk by execution.clk.
• Rename precomputed.clk by precomputed.idx

Performance improvements

• PCS: goes from 3s to ~1.5s on 32 cores.
• For bulk this is a small improvement.
• But for token transfers it is a 25% improvement.

[jeanmon]

@fcarreiro Maybe this way of iterating is a bit dangerous. Maybe we do not have the guarantee that the iteration is following the indices of the span.

[fcarreiro]

I think you can use these functions

// this assumes non-empty, returns an iterator
auto it = std::max_element(nums.begin(), nums.end(), [](int a, int b) {
    return a < b; // Your custom comparator logic
});

// retrieves the index
size_t index = std::distance(nums.begin(), it);

Otherwise I would do a good old for loop. Spans have size(), and they are contiguous.

[fcarreiro]

I have some doubts about the PIL changes. I think that only lookups into precomputed or PIs should use idx. Shouldn't the rest use the execution clk? In particular think of memory. In simulation the clk manager (or whatever the name was) links it to execution.

[fcarreiro]

I think you can use these functions

// this assumes non-empty, returns an iterator
auto it = std::max_element(nums.begin(), nums.end(), [](int a, int b) {
    return a < b; // Your custom comparator logic
});

// retrieves the index
size_t index = std::distance(nums.begin(), it);

Otherwise I would do a good old for loop. Spans have size(), and they are contiguous.

[jeanmon]

I have some doubts about the PIL changes. I think that only lookups into precomputed or PIs should use idx. Shouldn't the rest use the execution clk? In particular think of memory. In simulation the clk manager (or whatever the name was) links it to execution.

@fcarreiro You are absolutely right. I think I overlooked the virtual trace of execution. I will review all of these changes more carefully.

[jeanmon]

@federicobarbacovi @iakovenkos Could you please have a look at the changes in the files: prover.cpp, verifier.cpp, recursive_verifier.cpp?

[jeanmon]

@iakovenkos Is this correct that we should not change the size of polynomial_batcher ?

[jeanmon]

@iakovenkos Is this what you expected?