Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Reminds me of the 2024 blog post Look ma, I wrote a new JIT compiler for PostgreSQL [0]. Both articles lament that Postgres's LLVM-based JIT [1] takes a while to generate code.

> The rarity of JIT compilers makes me believe that implementing a JIT compiler historically was too difficult for it to be worthwhile.

That's only true of writing a JIT from scratch. There's no rarity of JITs, it's just that LLVM (and other frameworks) are often used. Every major interpreter has a JIT compiler. PCRE2 has a JIT compiler. There are JIT frameworks out there with much faster code-generation than LLVM: Cranelift, GNU Lightning, Mir. I doubt they could do code-generation faster than a custom copy-and-patch JIT, but they'd be much faster than LLVM.

[0] https://www.pinaraf.info/2024/03/look-ma-i-wrote-a-new-jit-c... , discussed: https://news.ycombinator.com/item?id=39742916

[1] https://www.postgresql.org/docs/current/jit-reason.html

View on HN

A few other small and fast JITs: https://github.com/zherczeg/sljit (used by libpcre), https://github.com/asmjit/asmjit (RPCS3 and FBGEMM) and https://webkit.org/blog/5852/introducing-the-b3-jit-compiler... (only used by JSC in Webkit, I think)

Thanks, sljit looks somewhat similar to GNU lightning.

On reflection I wonder if I overstated the widespread use of JIT and of JIT compiler frameworks. All the 'major' well-resourced high-profile JIT-based interpreters I can think of don't use an off-the-shelf JIT framework for their backend, which makes sense as they want to carefully tune the code-generation. OpenJDK, OpenJ9, .Net, V8, SpiderMonkey, JavaScriptCore. LuaJIT and Python's new JIT don't use one either, nor does the Linux kernel's BPF engine.

The Guile Scheme interpreter uses a fork of the GNU Lightning JIT library. [0] Julia and (as mentioned) Postgres use LLVM for their JITs. I'm trying to think of other projects that use a JIT framework/library.

Similarly, I can't think of many problem domains where it makes sense to use JIT. The ones that spring to mind are interpreters (of course), regex engines, and DBMSs. JIT can also help in high-performance computing, to tailor the code to the particular problem and the particular CPU. [1] I don't think there are many other contexts where it makes sense to use JIT though.

JIT compilation brings its own drawbacks in portability (both between hardware platforms and operating systems), complexity, and perhaps cybersecurity, which might also limit its adoption, even if a good JIT framework could help with all three.

[0] https://doc.guix.gnu.org/guile/latest/en/html_node/Just_002d...

[1] https://www.intel.com/content/www/us/en/developer/articles/t...

> There's no rarity of JITs, it's just that LLVM (and other frameworks) are often used

Except that using LLVM has high latency limitting it's applicability. Postgres just disabled LLVM by default because of this[0].

[0] https://www.postgresql.org/message-id/E1w8GWU-002bSL-31%40ge...

Interesting, thanks for the link. LLVM isn't the only game in town though, nobody using it (or libgccjit) for JIT should be surprised to see relatively long compile times. I wonder if the postgres project will try a different backend.

There's a strong 'diminishing returns' effect in striking a balance between compile time and the performance of the generated code. I'd expect a more lightweight (less optimising) JIT engine to be able to produce code with pretty respectable performance while taking only a fraction of the time that LLVM takes. There's a follow-up to the blog post I linked above, which bears this out. [0] (I don't know if that JIT solution is production-ready or viable for merging into postgres, mind.)

The blog post [0] gives this performance comparison:

> So, on our stupid benchmark, doing 10 times a simple SELECT * FROM demo WHERE a = 42 on a 10 million rows table...

    PostgreSQL             No JIT          LLVM JIT               Copyjit
    ----------             ------          --------               -------
    Average time (ms)      120             106 (-12%)             101 (-15%)
    Compilation time (ms)  0               19                     0.06
    Instructions           13,350,766,209  10,643,820,667 (-21%)  12,769,013,536 (-5%)
    Cycles                 4,660,821,596   4,005,881,863 (-14%)   3,924,602,439 (-16%)
    Branches               2,322,470,659   1,798,221,785 (-23%)   2,031,456,214 (-13%)

[0] https://www.pinaraf.info/2025/12/jit-episode-iii-warp-speed-...

The original Dartmouth BASIC had a JIT like approach, the REPL would compile to machine code before execution.

It was the limits of 8 bit home computers hardware that made the interpreter version be more widely known.

Same to Lisp, Smalltalk, and many other languages.

Fully agree with you.

Reply on news.ycombinator.com