JIT-Compiler in 5 Mikrosekunden: So baut man einen mit KI-Unterstützung

JIT Compiling Code in 5μs

JIT-Compiler in 5 Mikrosekunden: So baut man einen mit KI-Unterstützung

Früher galt schnelle JIT-Kompilierung als schwarze Kunst, doch mit KI-Unterstützung wird sie zum Kinderspiel. Der Autor zeigt am Beispiel einer einfachen Regex-Engine, wie man mit dem Copy-and-Patch-Ansatz direkt Assembler-Code generiert und in unter 5 Mikrosekunden kompiliert. Das ermöglicht es, jede SQL-Abfrage in der Datenbank pgrust per JIT zu beschleunigen – ein Bereich, in dem neue Datenbanken alte überholen können.

Der pgrust-JIT-Compiler kompiliert Code in etwa 5 Mikrosekunden, was es uns ermöglicht, jede SQL-Abfrage per JIT zu kompilieren, nicht nur eine Teilmenge davon.
  1. MaxBarraclough

    Das erinnert mich an den Blogbeitrag von 2024 "Look ma, I wrote a new JIT compiler for PostgreSQL" [0]. Beide Artikel beklagen, dass Postgres' LLVM-basierter JIT [1] eine Weile braucht, um Code zu generieren.

    > Die Seltenheit von JIT-Compilern lässt mich glauben, dass die Implementierung eines JIT-Compilers historisch zu schwierig war, um sich zu lohnen.

    Das gilt nur, wenn man einen JIT von Grund auf neu schreibt. Es gibt keine Seltenheit von JITs, es ist nur so, dass LLVM (und andere Frameworks) oft verwendet werden. Jeder große Interpreter hat einen JIT-Compiler. PCRE2 hat einen JIT-Compiler. Es gibt JIT-Frameworks mit viel schnellerer Codegenerierung als LLVM: Cranelift, GNU Lightning, Mir. Ich bezweifle, dass sie die Codegenerierung schneller hinbekommen als ein maßgeschneiderter Copy-and-Patch-JIT, aber sie wären viel schneller als LLVM.

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

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

  2. agnishom

    Ich empfehle Russ Cox' Artikel zur Implementierung einer Regex-Engine: https://swtch.com/~rsc/regexp/

    Es ist sehr relevant

  3. catlifeonmars

    Das ist vielleicht ein wenig meta, aber es war eine angenehme Lektüre. Es ist erfrischend, einen Artikel über die Verwendung eines LLM zu lesen, der nicht so klingt, als wäre er auch von diesem LLM geschrieben worden.

    Ich könnte diesen Ansatz verwenden, um die Schablonen für eine JIT-Firewall zu generieren, mit der ich experimentiere.

    Mir kommt auch der Gedanke, dass man damit auch eBPF-Bytecode im laufenden Betrieb generieren könnte.

  4. glum64

    Ähm, Common Lisp, wo JIT nicht nur verfügbar, sondern auch handhabbar ist: Der Programmierer kann entscheiden, was es wert ist, kompiliert zu werden, und was nicht.

    Neben der Laufzeit ist JIT auch verfügbar, wenn der Code kompiliert oder zur Ausführung geladen wird (d.h. hast du eine Kompilier- oder Ladegeschwindigkeitssteigerung im Sinn? kein Problem, du kannst diese Steigerung auch in nativen Maschinencode kompilieren, und so weiter ins Unendliche...).

  5. mgaunard

    Das Problem mit dem Ansatz ist, dass es kein echtes JIT-Compiling ist, sondern nur Assembly-Templates mit grundlegenden Substitutionen.

    Indem man LLVM nicht verwendet, verpasst man all die Optimierungen, die es durchführt.

  6. malisper

    Autor hier. Lasst es mich wissen, wenn ihr Fragen zum Beitrag oder zu pgrust habt.

  7. glenjamin

    pgrust klingt sehr interessant, aber mit den tiefgreifenden Änderungen gibt es keinen praktikablen Weg, es upstream zu bringen - ist das Endziel, robust genug zu sein, dass es breite Akzeptanz findet?

  8. hamilyon2

    Es verwendet Copy-and-Patch-Kompilierung, um das zu erreichen.

Mehr von diesem Tag

2026-08-23