Workload

Walk Frankenstein's text (~441 KiB, ~7,700 lines) byte-by-byte to find newline boundaries. For each line, call the runner's bundled SHA-256 primitive once. XOR-fold every 32-byte digest into a running accumulator. Emit the accumulator as 64 lowercase hex characters.

Symmetry rules

• One SHA-256 call per line (~7,700 native FFI dispatches per inner iteration). Whole-buffer hashing (sha256.Sum256(corpus) / hashlib.sha256(corpus).hexdigest()) is banned because it would do the work in a single native call, hiding the per-call signal.
• Line scan and XOR fold run in interpreted code on every runner. No strings.Split, no str.splitlines.
• Hand-rolled hex emission (no encoding/hex, no binascii.hexlify) so the trailing format step also runs in the interpreter.
• Tengo's stdlib does not bundle SHA-256, so the harness registers a sha256_sum builtin that wraps Go's crypto/sha256.Sum256. Same shape of "register a host function as a native callout" that every other runner uses, just via Tengo's UserFunction surface.

Why this benchmark exists

This is the only benchmark that exercises the script-orchestrates-compiled-primitive pattern, which is how most production embedded interpreters are actually used (NumPy from Python, engine bindings from Lua, host functions from Tengo). Per-call FFI dispatch overhead is what discriminates runners: with ~7,700 calls per inner iteration, a 1µs-per-call difference adds up to ~8 ms of wall time, visible against a ~100 ms baseline. Every runner uses the same SHA-256 algorithm routed through the same compression primitive (OpenSSL on Python, Go's crypto/sha256 with ASM where available on Go family), so the per-block hash cost is comparable across the board.