Skip to content(if available)orjump to list(if available)

JIT: So you want to be faster than an interpreter on modern CPUs

JIT: So you want to be faster than an interpreter on modern CPUs

4 comments

·October 12, 2025
Visit

stmw

Good read. But a word of caution - the "JIT vs interpreter" comparisons often favor the interpreter when the JIT is inplemented as more-or-less simple inlining of the interpreter code. (Here called "copy-and-patch" but a decades-only approach). I've had fairly senior engineers try to convince me that this is true even for Java VMs. It's not in general, at least not with the right kind of JIT compiler design.

hoten

I just recently upgraded[1] a JIT that essentially compiled each bytecode separately to one that shares registers within the same basic block. Easy 40 percent improvement to runtime, as expected.

But something I hadn't expected was it also improved compilation time by 40 percent too (fewer virtual registers made for much faster register allocation).

[1] https://github.com/ZQuestClassic/ZQuestClassic/commit/68087d...

gr4vityWall

That was a pretty interesting read.

My take is that you can get pretty far these days with a simple bytecode interpreter. Food for thought if your side project could benefit from a DSL!

klipklop

A shame operating systems like iOS/iPadOS do not allow JIT. iPad Pro's have such fast CPU's that you cant even use fully because of decisions like this.