Hacker News new | ask | show | jobs
by kspp 2547 days ago
It seems to be fast enough for SQL JIT-compiler in PostgreSQL 11+ and shader compilation in the *nix OpenGL stack (mesa), both of which are sort-of-realtime systems.
6 comments

SQL queries and GL shaders tend to be much shorter than a typical program.

There are exceptions of course, but it's rare to find shaders with thousands of lines of code or more.

There is an ongoing work to move Mesa away from LLVM because LLVM is slow.
Another HN thread on projects that found LLVM to be slow.

https://news.ycombinator.com/item?id=16956589

That's the best way to learn — post a stupid thing on the internet and let the internet prove you wrong. Thanks to everyone who replied!
Can't say anything about shaders but I do know a thing or two about database queries:

1. Queries are often repeated, i.e. most of backend DBs get the same requests over and over again. Even a slow jit compiler is fine here as things just get cached. 2. Queries usually take some time to complete, and this offsets the jit-related latency.

Also, Postgres has a very limited kind of jit compilation, i.e. for expressions only.

Notice that javascript jit compilers usually have a multi-tiered compilation. That's because proper compilation takes time, and sometimes it is more efficient to just do some basic template jiting (or no additional compilation) instead of firing the heavy guns.

None of them use LLVM, btw.

I'm not sure I follow your reasoning, Go isn't JITed, is it?
Language != Implementation.

And yes, there are Go interpreters as well.

https://github.com/go-interpreter

Rust compilation is slow, and a large part of that is due to the use of LLVM.
LLVM is slow but swapping for CraneLift only improves compile times 33%. Other work is needed for a dramatic reduction in compile times: https://github.com/bjorn3/rustc_codegen_cranelift/issues/133...