Profile suite

[gabrielbosio]

Adds a script that runs heap and timing profiling over the following programs:

• fib_iterative
• modexp
• keccak
• matrix_multiply
• bitwise_ops

Adapts programs so that we can compile them with different inputs, allowing profiling the same program with different sizes and see how the program scales.

Base branch is the one from #475 but it also cherry-picks #495 for a complete profiling toolkit.

Adds CI benchmark command for all the programs, not only fib_iterative.

[github-actions]

Codex Code Review

1. High (Security): path traversal enables destructive rm -rf outside /tmp

   • In both scripts, --program is user-controlled and concatenated into TMP_DIR, then recursively deleted:
   • scripts/bench_heap_profile.sh:32, scripts/bench_heap_profile.sh:50, scripts/bench_heap_profile.sh:62
   • scripts/bench_timing_profile.sh:32, scripts/bench_timing_profile.sh:50, scripts/bench_timing_profile.sh:62
   • Example: --program ../../home makes TMP_DIR=/tmp/bench_*_profile/../../home, so rm -rf "$TMP_DIR" can target /home.
   • Fix: strictly validate PROGRAM against an allowlist (fib_iterative|keccak|modular_exp|bitwise_ops|matrix_multiply) before using it in paths.

2. Low (Potential bug): unchecked compile-time numeric parsing can silently produce wrong values

   • The new const parsers assume every byte is a digit and do (b[i] - b'0') without validation:
   • executor/programs/bench/bitwise_ops/src/main.rs:4
   • executor/programs/bench/keccak/src/main.rs:5
   • executor/programs/bench/matrix_multiply/src/main.rs:4
   • executor/programs/bench/modular_exp/src/main.rs:4
   • Non-digit input can be misparsed (e.g. "1M" becomes 39) or fail unexpectedly for some chars/overflows.
   • Fix: validate b[i].is_ascii_digit() (or explicit range check) and fail clearly.

No other concrete security/bug/performance issues stood out in the PR diff.

[claude]

Medium – Silent wrong value on non-digit input

b[i] - b'0' doesn't validate the byte is actually '0'..='9'. Since b'k' (107) > b'0' (48) there's no wrap/panic — the subtraction just yields 59 and the wrong iteration count is used silently.

For example, ITERATIONS=1k computes 1*10 + 59 = 69 iterations instead of failing loudly.

This is a const fn evaluated at compile time, so a panic here becomes a compile error with a clear message:

Suggested change

	r = r * 10 + (b[i] - b'0') as usize;
	assert!(b[i] >= b'0' && b[i] <= b'9');
	r = r * 10 + (b[i] - b'0') as usize;

Same issue exists in keccak/src/main.rs, matrix_multiply/src/main.rs, and modular_exp/src/main.rs.

[claude]

Low – Stack overflow for large SIZE

All three matrices are stack-allocated: SIZE × SIZE × 4 bytes × 3 = SIZE² × 12 bytes. Default SIZE=81 → ~79 KB which is fine, but SIZE=200 → ~480 KB and SIZE=500 → ~3 MB will likely stack-overflow.

Consider a note in the script / usage comment that SIZE values above ~150 risk stack overflow, or cap the default range in profile_suite.sh (current max is 80, which is safe).

[claude]

Review: Profile Suite

Overview: Adds a profiling toolkit — heap + timing profiles across multiple bench programs (fib_iterative, modular_exp, keccak, matrix_multiply, bitwise_ops). Bench programs are migrated from no_std + manual entry point to lambda-vm-syscalls and made configurable via env vars at compile time. The scripts are clean and follow consistent patterns.

---

Issues

Medium — const fn parse() silently produces wrong values on invalid input (inline)
Non-digit characters (e.g. ITERATIONS=1k) don't panic or error — they silently compute a wrong iteration count because unsigned subtraction doesn't underflow for chars above '0'. Since this is const, an assert!(b[i] >= b'0' && b[i] <= b'9') becomes a compile-time error with a clear message. Same issue in all four bench main.rs files.

Low — Stack overflow risk in matrix_multiply (inline)
Three SIZE×SIZE arrays on the stack. Current default and profiling range (max SIZE=80) is fine, but the risk is invisible to someone who runs build_bench_sizes.sh matrix_multiply SIZE 200.

Low — const fn parse() duplicated 4× across bench programs
The function is identical in every bench program. Since each bench lives in its own Cargo workspace, sharing via a crate path isn't straightforward, but a comment like // keep in sync with sibling bench programs would help avoid silent divergence.

---

Minor observations

• suffix_to_steps now passes unknown suffixes through as-is (e.g. "5000") rather than erroring. This is intentional and documented in the comment, but the downstream awk growth-rate section reports "per 1M steps" even when "steps" are actually iteration counts — numbers are correct but the label can be confusing.
• Script style is consistent and set -euo pipefail is used throughout. The $HEAP && ... pattern is safe because the left operand of && doesn't trigger set -e on failure.