CPython under the bench: the 3.14 interpreter is the win, and what the JIT (doesn't) buy you

The probe payload is a kernel-for-kernel port of the Ruby one: fib34 (recursive calls) and alloc2m (two million string+list allocations), warmed 3× then timed 7× inside each process.

Two findings fall out of this table.

The interpreter line is the win. Plain 3.14.7 runs the call kernel at 0.80× of plain 3.13.15 — that is CPython 3.14’s new tail-calling interpreter doing exactly what upstream says it does. Allocation churn is a wash (1.04×). For a call-heavy payload, moving the runtime line forward buys ~20% before the JIT enters the discussion.

The JIT is a no-op at this horizon — on both lines. On 3.13, ON vs OFF is 0.999× (dead noise; the 3.13 JIT is PEP 744’s experimental stencil tier, and upstream’s own numbers were always "about nothing"). On 3.14, ON vs OFF is 1.005×. The per-build ±3–5% wobble (the jit build is a touch slower on fib34, a touch faster on alloc2m) is build-flag noise, not a JIT effect — it moves nothing when the environment variable toggles.

One finding falls out of the probe rather than the timings: the 3.14 jit flavor defaults ON. The property is measured, not assumed: under a null environment the flavor reports sys._jit.is_enabled() == True, and PYTHON_JIT=0 flips it off (the toggle is honored and the result is recorded). On 3.13 the flavor defaults off, and 3.13 carries no runtime query API at all (the sys._jit namespace is 3.14’s). The packaging posture follows: the 3.14 flavor is safe as a default-on build; the toggle remains one environment variable away, declared by the packager and overridable by the user — the same rule the project landed for YJIT/ZJIT.

Kernels are where JITs are expected to help; real code is where the help is priced. The workload is xml2rfc 3.34.0 (with lxml included — a native-extension payload, ABI-pinned to the 3.13 line, which is why this cell runs the 3.13 arms) rendering RFC 9000, the 726 KB QUIC specification, to text through the mounted payload, with output written to the host.

Every rendered byte is identical across nine of nine comparisons — the JIT never changes output. Every timing is identical as well. On a real one-shot compile the 3.13 JIT does nothing, which is the same finding class as YJIT on the 45-second Metanorma compile, minus the harm (YJIT actively cost 1.5× there; the CPython JIT at least does no damage).

The honest row in that table deserves attention: of the ~6.7-second wall, only ~1.5 s is user CPU. The remainder is process startup — interpreter boot, env-image mount, and site-packages loading from the mounted image. That startup is tebako’s constant on this host, and it is the same class as the Ruby runtime’s ~4.2 s boot. For one-shot tools that constant dominates; the answer to it is the startup-work queue (warm caches, slimmer images), not the JIT. For the record, the JIT’s resident-set-size cost is ~+13 MiB, or 5% — not the GraalVM-class memory tax (TruffleRuby native pays 9.4×, and JRuby pays 13× on the same kernels).

The two windows produced fifty cells (37 kernel + 13 real-workload), every one rc=0 and every output byte-identical — JIT × tebako is new territory, nothing crashed, and there is therefore nothing to file upstream this time. The rule stands for the case in which something does fail: report it or raise an upstream PR, because local patches are temporary by definition.

The conclusion travels from Ruby unchanged: there is no fastest engine, only a fastest engine for the shape of the process — and the packaging layer is where that choice is declared, measured, and overridable. The runtime is a line, and the packager picks the line.