Implement LogupOps for SIMD backend

[andrewmilson]

This change is 

[andrewmilson]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add benchmarks for GKR lookups #673
• Implement LogupOps for SIMD backend #641 👈
• Implement GrandProductOps for SIMD backend #640
• Implement GkrOps for SIMD backend #630
• Implement MleOps for SIMD backend #629
• Add GKR implementation of Logup lookups #623
• Add GKR implementation of Grand Product lookups #620
• Implement GkrOps for CPU backend #621
• Add batch GKR prover and verifier #581
• Rename CPU* structs to Cpu* to conform to Rust's naming convention #617
• Remove AVX backend #616
• Convert wide_fibbonacci AVX backend example to SIMD backend #615
• Update CI to test Wasm simd128, avx2 and aarch64 neon #614
• Fix CirclePointIndex bug in debug mode for 32-bit archs #613
• Change opt-level in benchmarks script #612
• Add benchmarks for SIMD m31 #611
• Add benchmarks for SIMD merkle #610
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @andrewmilson and the rest of your teammates on Graphite

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.75000% with 5 lines in your changes missing coverage. Please review.

Project coverage is 93.10%. Comparing base (b2e7df0) to head (eda03f0).

Files	Patch %	Lines
crates/prover/src/core/backend/simd/lookups/gkr.rs	99.21%	0 Missing and 3 partials ⚠️
crates/prover/src/core/lookups/utils.rs	85.71%	2 Missing ⚠️

Additional details and impacted files

@@                                 Coverage Diff                                  @@
##           05-24-Implement_GrandProductOps_for_SIMD_backend     #641      +/-   ##
====================================================================================
+ Coverage                                             92.69%   93.10%   +0.40%     
====================================================================================
  Files                                                    77       77              
  Lines                                                 10487    10847     +360     
  Branches                                              10487    10847     +360     
====================================================================================
+ Hits                                                   9721    10099     +378     
+ Misses                                                  674      653      -21     
- Partials                                                 92       95       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[shaharsamocha7]

Reviewed 3 of 4 files at r1, all commit messages.
Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @andrewmilson)

---

crates/prover/src/core/backend/simd/lookups/gkr.rs line 211 at r1 (raw file):

}

// TODO: Code duplication of `next_logup_generic_layer`. Consider unifying these.

Don't you want to do that in this pr?

Code quote:

// TODO: Code duplication of `next_logup_generic_layer`. Consider unifying these.

---

crates/prover/src/core/lookups/utils.rs line 199 at r1 (raw file):

/// Projective fraction.
#[derive(Debug, Clone, Copy)]
pub struct Fraction<N, D> {

Why do you need it to be that generic?
Isn't it only for Field/ExtensionField elements?

Code quote:

Fraction<N, D> 

---

crates/prover/src/core/lookups/utils.rs line 272 at r1 (raw file):

            denominator: self.x * rhs.x,
        }
    }

Can you add a test for this?

Code quote:

    fn add(self, rhs: Self) -> Fraction<T, T> {
        // `1/a + 1/b = (a + b)/(a * b)`
        Fraction {
            numerator: self.x + rhs.x,
            denominator: self.x * rhs.x,
        }
    }

[andrewmilson]

Reviewable status: 2 of 4 files reviewed, 3 unresolved discussions (waiting on @shaharsamocha7)

---

crates/prover/src/core/backend/simd/lookups/gkr.rs line 211 at r1 (raw file):

Previously, shaharsamocha7 wrote…

Don't you want to do that in this pr?

I'd want to just don't think we have the traits in order to express this function as generic

---

crates/prover/src/core/lookups/utils.rs line 199 at r1 (raw file):

Previously, shaharsamocha7 wrote…

Why do you need it to be that generic?
Isn't it only for Field/ExtensionField elements?

We don't implement Field or ExtensionOf traits on packed field elements.
If we had abstract Field/Extension traits it would work