Benchmark Your VM Against CPython

Topic Overview

Benchmarking VM Performance

You cannot optimize what you do not measure. Comparing your interpreter against CPython on the same workload reveals whether dispatch, allocation, or call overhead dominates.

Methodology

Sound micro-benchmarks follow a few rules:

• Warmup: run several iterations so caches and branch predictors stabilize
• Multiple samples: average several timed runs, discard outliers
• Heavy workload: recursive Fibonacci or a prime sieve stresses the interpreter loop

Dispatch styles matter:

• `switch` dispatch: portable, predictable branch mispredicts
• Computed goto: GCC extension building a direct jump table (CPython 3.11's specializing interpreter pushed further)

For example, `fib(35)` in bytecode versus the same algorithm in native C often shows a 50x or larger gap, mostly from per-opcode dispatch.

Use `clock()` from `<time.h>` and report milliseconds per iteration.

Design Notes

Report at least median and spread, not a single timing sample. OS jitter and cache warmth dominate short runs; three warmup iterations plus five measured runs is a minimal credible methodology for comparing interpreter variants.

For This Exercise

This exercise asks you to benchmark recursive Fibonacci in your VM against a C baseline. You will implement warmup runs, timed iterations, and printed comparison so you know where cycles go before optimizing.

Your Task

"Benchmark your VM against CPython" really means understanding where an interpreter spends its dispatches. Wall-clock times differ on every machine, so profile the VM exactly instead: run two fixed Fibonacci programs on a small stack VM with 64-bit values, count every dispatched instruction per opcode, and measure how the recursive version's cost grows. Each step multiplies it by about 1.618, the golden ratio. The iterative version's cost grows linearly. Then convert dispatches into an estimated time.

Input

cCopy
Loading…

The programs (instruction index: instruction)

Recursive, argument in local 0 of the main frame:

cCopy
Loading…

Iterative, n in local 0, with a in local 1 and b in local 2:

cCopy
Loading…

Semantics

• LT pops b, then a, and pushes a < b. JZ pops and jumps if the value is 0.
• CALL pops one argument into the new frame's local 0 and remembers the return index and the stack height. RET pops the result, restores the height, pushes the result and returns.
• HALT stops, and its value is the top of the stack. Every executed instruction counts, including HALT.

Output

cCopy
Loading…

• Top opcodes: the three most executed, by count (ties by name), with their share of the total rounded half up to 1 decimal.
• Time: total × NS nanoseconds, shown as ms with 3 truncated decimals.
• Growth line: after a recursive run whose n is exactly one more than the previous recursive run's n, the instruction ratio rounded half up to 3 decimals.
• Errors: recursive: n must be 0..30, iterative: n must be 0..90, and dispatch: 1..1000 ns.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Run the listed programs exactly. The counts depend on every instruction.
2. Count inside the dispatch loop, once per fetched instruction. That is the unit of interpreter overhead.

Hidden tests cover fib(0) and fib(1), consecutive recursive runs at larger n, the iterative version at n = 90 (the result needs 64 bits), a custom dispatch cost, and out-of-range arguments.