A JIT multiplier buys only the bytecode fraction of a handler's wall clock

Take a handler that spends a fifth of its wall clock executing Python bytecode and the rest querying the database, computing in NumPy and serializing the response ^[2]. Give the bytecode a 2x. End to end that is 1/(0.8 + 0.2/2), about 1.11x, and deleting the bytecode outright caps you at 1.25x ^[1]. CinderX accelerates bytecode, and the number does not extend past the bytecode ^[3]. The proportion of bytecode in your service is a property of your code, not of the extension, and the dev.to writeup is blunt that until it is calculated the adopt decision is guesswork ^[4].

What gets installed is a binary package, into an interpreter you already have. It replaces the frame evaluator, the function CPython calls to execute each frame, and execution proceeds through it from that point on ^[5]. The JIT compiles the entire object code into machine code ^[6]. Static Python is a separate compiler for a typed subset that emits its own opcodes, which the JIT then translates ^[7]. A parallel garbage collector parallelizes the two collection phases and is enabled by a call ^[8]. Lightweight frames fill only the fields the machine code itself needs, and the runtime completes the rest when it asks for a full frame ^[9].

CPython 3.14 already has a JIT of its own, behind --enable-experimental-jit, specified in PEP 744 and known as tier 2 ^[11]. Its copy-and-patch design exists to avoid having a compiler at runtime at all ^[12]. Tools/jit/template.c holds one uop's body wrapped in a function taking (frame, stack_pointer, tstate), with everything that varies at runtime left as named holes: _JIT_OPARG, _JIT_OPERAND0, _JIT_TARGET, _JIT_CONTINUE ^[13]. Clang compiles that stencil once per uop during the CPython build and assembles the results into a stencil table ^[14]. At runtime, _PyJIT_Compile follows a trace, copies the stencil it wants into executable memory and fills the holes, doing no parsing, no analysis and no instruction selection ^[16].

Cheap compilation shows up in the generated code. Adjacent uops share no register, so the value _LOAD_FAST produces lands on the frame value stack in memory for the next uop to fetch, and there is no intermediate representation to allocate over ^[19]. Reference counter operations are not reordered on liveness; the one thing the analyzer does with counters is use the borrowing variant for loading constants that are immortal ^[21]. The win is the dispatch loop with its switch and unpredictable branch disappearing, plus duplicate type version checks that the data flow pass in Python/optimizer_analysis.c can prove redundant ^[20].

Traces have to form first. translate_bytecode_to_trace projects along the hot path from the backtrack and checks branching history at each fork; confidence starts at 1,000, gets multiplied by the fraction of matching transitions, and the projection terminates below 333, with the path capped at 800 uops ^[22]. A fork that goes the same way 60 percent of the time multiplies confidence by 0.6. Two of them leave 360. A third leaves 216, and the projection ends there ^[2].

For a published multiplier to transfer to your service, most of the handler's wall clock would have to be interpreter frames ^[3], the hot path would have to fit in 800 uops, and its forks would have to be lopsided enough to hold confidence above 333 ^[22]. Typing the hot subset so Static Python compiles it is the lever that grows the bytecode side of that ratio ^[7]. The build side has its own bill: LLVM 19 with clang, because the template relies on musttail and GCC does not support it ^[15]. A GCC-only pipeline buys a second toolchain before it can produce the binary whose speedup it then has to measure.