feat: add as_slice builtin function, add execution test

[michaeljklein]

Description

Problem*

Expected to resolve slowdown in #4504

Summary*

Adds builtin function for as_slice, allowing it to be much more efficient (O(1) instead of O(n))

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[vezenovm]

Looks good! We just need to update the ACIR gen code.

[jfecher]

LGTM once @vezenovm's comments are addressed. Hopefully once the CI finishes we'll see a good speedup

[github-actions]

Changes to circuit sizes

Generated at commit: 61893544ce135e0ab23ffe63f9db9a312f202d56, compared to commit: 414194cdbeb65096c25152084d25ab79d80d2f3e

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
double_verify_proof_recursive	+839 ❌	+41950.00%	+2,810 ❌	+0.56%
double_verify_proof	+839 ❌	+41950.00%	+2,810 ❌	+0.56%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
double_verify_proof_recursive	841 (+839)	+41950.00%	503,777 (+2,810)	+0.56%
double_verify_proof	841 (+839)	+41950.00%	503,777 (+2,810)	+0.56%

[vezenovm]

double_verify_proof +839 ❌ +41950.00% +2,810 ❌ +0.56%
double_verify_proof_recursive +839 ❌ +41950.00% +2,810 ❌ +0.56%

@jfecher So it looks like in the case of converting inputs from main using dynamic arrays we actually we do add opcodes that we weren't before. This is surprising still though as we wouldn't be fetching an array constant when performing SlicePushBack for the non-builtin as_slice method previously. So I would expect the previous version to have significantly more dynamic array copies than this version.

[jfecher]

@vezenovm since the difference in constraint counts isn't too extreme, perhaps it is still worth it if the runtime is faster?

[jfecher]

@vezenovm doesn't seem this PR is worth it from @michaeljklein's performance tests. They've been about the same with or without this change so I'm leaning towards it being unneeded complexity.

[vezenovm]

@vezenovm doesn't seem this PR is worth it from @michaeljklein's performance tests. They've been about the same with or without this change so I'm leaning towards it being unneeded complexity.

@michaeljklein said he had ~3x improvement for 1k size arrays which is pretty good, but yeah only for larger arrays.

[jfecher]

@vezenovm sorry, that message was before I spoke with @michaeljklein and saw some new performance tests that aren't present in master. It seems the existing tests we had in test_programs just weren't affected too much. I've tested it locally as well and as_slice is noticeably faster with larger arrays with this change. So I think we can merge this after a review.

[michaeljklein]

cargo build && cargo run execute timing results:

on master:

[array_to_slice_literal]
cargo run execute  1.52s user 0.27s system 127% cpu 1.407 total

[array_to_slice_dynamic]
cargo run execute  1.51s user 0.26s system 131% cpu 1.344 total

[array_to_slice_literal_long]
cargo run execute  4.99s user 0.29s system 107% cpu 4.896 total

[array_to_slice_dynamic_long]
cargo run execute  5.41s user 0.29s system 107% cpu 5.301 total

this branch:

[array_to_slice_literal]
cargo run execute  1.51s user 0.26s system 126% cpu 1.396 total

[array_to_slice_dynamic]
cargo run execute  1.51s user 0.24s system 130% cpu 1.342 total

[array_to_slice_literal_long]
cargo run execute  1.53s user 0.26s system 129% cpu 1.376 total

[array_to_slice_dynamic_long]
cargo run execute  1.58s user 0.24s system 130% cpu 1.405 total

the test programs took the following format, where the *_long tests had an array literal of length 1024:

fn main(x: Field, y: pub Field) {
    // for _dynamic
    let mut xs: [Field; 2] = [0, 2];
    xs[x] = y;
    
    // for _literal
    let xs: [Field; 2] = [1, 2];

    // all cases
    let ys = xs.as_slice();
    assert(ys[0] == 1);
}

[jfecher]

LGTM