chore: Optimise grand product computation round based on active ranges

[maramihali]

Skip computation of numerator and denominator of z_perm at indexes that are not part of the active ranges, and refine the threshold in commit_structured for z_perm. New benchmarks:
Now: 5.6 s difference

CLIENT_IVC_BENCH_STRUCTURE(2^19)
ClientIVCBench/Full/6      26442 ms        24116 ms   
execute_grand_product_computation_round(t)    1474     5.37%
compute_grand_product(t)                       483     1.56%
COMMIT::z_perm(t)                1054    32.06%
ProtogalaxyProver_::run_oink_prover_on_each_incomplete_key(t)    3346    24.12%

EXAMPLE_20(2^20)
ClientIVCBench/Full/6      32045 ms        28802 ms   
execute_grand_product_computation_round(t)    1997     6.11%
compute_grand_product(t)                       654     1.78%
COMMIT::z_perm(t)                1426    36.43%
ProtogalaxyProver_::run_oink_prover_on_each_incomplete_key(t)    3998    23.81%

Master: 6.5 s difference

CLIENT_IVC_BENCH_STRUCTURE(2^19)

ClientIVCBench/Full/6      27351 ms        25477 ms 
execute_grand_product_computation_round(t)    2204     5.37%
compute_grand_product(t)           1113     2.71%
COMMIT::z_perm(t)                1084    32.87%
ProtogalaxyProver_::run_oink_prover_on_each_incomplete_key(t)    4030    27.55%

EXAMPLE_20(2^20)

ClientIVCBench/Full/6      33852 ms        30893 ms   
execute_grand_product_computation_round(t)    3719     8.83%
compute_grand_product(t)           2177     5.17%
COMMIT::z_perm(t)                1531    37.01%
ProtogalaxyProver_::run_oink_prover_on_each_incomplete_key(t)    5526    30.28%

We still see a difference between committing to z_perm between an ambient trace of 2^19 and 2^20, caused by the fact that the active ranges complement are larger (i.e. the ranges in the trace blocks where z_perm is constant) because the blocks themselves are larges. We still make sure that we avoid computing and committing to z_perm after the final active wire index.

[ledwards2225]

Looks good - left some suggestions for things to consider but I'll leave it up to you to decide what's worth doing.

[ledwards2225]

I suppose by avoiding unnecessary calls to get_row you've cut down most of the additional cost but there's more we could potentially do right? IIUC with this update we still go on to compute z_perm everywhere even in the "constant" ranges which could be avoided. Maybe that's a negligible cost compared to what you've handled here. One thought: maybe its not this easy but could we simply update the parallel_for loop that appears multiple times in this method to operate only over the active ranges? We shouldn't really even need to compute any intermediate values in the inactive regions. We would just populate the constant regions with the appropriate constant value at the end. Anyway, I'll leave it to you to decide what to do if anything.

[maramihali]

yes, thanks for the comment, will have a go at it in a subsequent PR