Implement MleOps for SIMD backend

[andrewmilson]

This change is 

[andrewmilson]

• Add eval order and interpolate to SecureEvaluation #794
• Add MLE eval constraints #742
• Add eq evals constraints #741
• 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

[shaharsamocha7]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @andrewmilson)

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 121 at r2 (raw file):

/// Computes all `eq(0, assignment_i) * lhs_eval_i + eq(1, assignment_i) * rhs_eval_i`.
// TODO: Consider unifying fold_packed_mle_* functions once we have something like

Please put your name in the todo's. can be fixed later

Code quote:

TODO: 

[spapinistarkware]

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

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 23 at r2 (raw file):

        let midpoint = mle.len() / 2;

        // Use CPU backend to to prevent dealing with instances smaller than `PackedSecureField`.

Suggestion:

// Use CPU backend to to avoid dealing with instances smaller than `PackedSecureField`.

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 44 at r2 (raw file):

}

impl MleOps<SecureField> for SimdBackend {

Looks like exactly the same code. Can you unite by negin generic on F and EF, and requiring some ops?
Such as F: Mul<SecureField, Output=EF>
I head a similar issue at crates/prover/src/constraint_framework/mod.rs. Currently have a todo to use a better trait, so you can copy that TODO here as well, in addition.

Code quote:

impl MleOps<SecureField> for SimdBackend {

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 78 at r2 (raw file):

}

impl MultivariatePolyOracle for Mle<SimdBackend, SecureField> {

Do we actually need this?
It seems a bit wierd, since you're trying to represent this Mle as a multilinear polynomial of it self. Why would we ever require this?
Seems to me that when we get a query to the first layer, the Mle, we can just answer the query directly using the reduction.

[spapinistarkware]

Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @andrewmilson)

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 123 at r2 (raw file):

// TODO: Consider unifying fold_packed_mle_* functions once we have something like
// AbstractField/AbstractExtensionField traits implemented on packed types.
fn fold_packed_mle_secure_evals(

Same as above, this can be generic on F and EF

[spapinistarkware]

Reviewed 1 of 3 files at r1, 1 of 1 files at r2.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @andrewmilson)

[andrewmilson]

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

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 23 at r2 (raw file):

        let midpoint = mle.len() / 2;

        // Use CPU backend to to prevent dealing with instances smaller than `PackedSecureField`.

Done.

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 44 at r2 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

Looks like exactly the same code. Can you unite by negin generic on F and EF, and requiring some ops?
Such as F: Mul<SecureField, Output=EF>
I head a similar issue at crates/prover/src/constraint_framework/mod.rs. Currently have a todo to use a better trait, so you can copy that TODO here as well, in addition.

This implementation modifies in place but the other makes an allocation which makes it hard to unify.

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 78 at r2 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

Do we actually need this?
It seems a bit wierd, since you're trying to represent this Mle as a multilinear polynomial of it self. Why would we ever require this?
Seems to me that when we get a query to the first layer, the Mle, we can just answer the query directly using the reduction.

Done. Removed

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 121 at r2 (raw file):

Previously, shaharsamocha7 wrote…

Please put your name in the todo's. can be fixed later

Done.

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 123 at r2 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

Same as above, this can be generic on F and EF

Done.

[spapinistarkware]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @andrewmilson)

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 23 at r2 (raw file):

Previously, andrewmilson (Andrew Milson) wrote…

Done.

Remove extra 'to'

[andrewmilson]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @spapinistarkware)

---

crates/prover/src/core/backend/simd/lookups/mle.rs line 23 at r2 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

Remove extra 'to'

Done.