[HN Gopher] Deegen: A JIT-Capable VM Generator for Dynamic Langu...
___________________________________________________________________
Deegen: A JIT-Capable VM Generator for Dynamic Languages
Author : mpweiher
Score : 83 points
Date : 2024-11-24 11:00 UTC (12 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| Rochus wrote:
| Discussed here: https://news.ycombinator.com/item?id=42186507
| tekknolagi wrote:
| It is very exciting to get a multi-tier VM from just bytecode
| encoded version of VM spec.
| Rochus wrote:
| See also https://stefan-marr.de/papers/oopsla-larose-et-al-ast-
| vs-byt... which demonstrates that we can do that with
| GraalVM/Truffle, and the generated VM from the AST based
| interpreter is even faster than the bytecode interpreter.
| tekknolagi wrote:
| There is significant warmup required, which is not good for
| most programs. Deegen's approach is very promising for
| interactive use or other situations that require low latency.
| bobajeff wrote:
| If this can generate a v8/spidermonkey class engine for new
| scripting languages that would be incredible.
| taylorius wrote:
| I wonder if this would work for python.
| 082349872349872 wrote:
| do you mean more specifically than the generally similar
| approach that worked for https://pypy.org ?
| tekknolagi wrote:
| ~~It didn't work; PyPy moved away from partial evaluation
| years ago~~
|
| Sorry, I think I was responding to completely the wrong
| comment. I would also like a more general-purpose tool for
| writing fast programming language implementations
| ivoflipse wrote:
| The Faster CPython team at least is aware of the paper and
| probably will look into it
|
| https://github.com/faster-cpython/ideas/issues/707
| chc4 wrote:
| CPython merged[0] an experimental JIT compiler into mainline
| based on the author's previous paper, Copy-and-Patch
|
| 0: https://peps.python.org/pep-0744/
| sitkack wrote:
| > We implement LuaJIT Remake (LJR), a standard-compliant Lua 5.1
| VM, using Deegen. Across 44 benchmarks, LJR's interpreter is on
| average 179% faster than the official PUC Lua interpreter, and
| 31% faster than LuaJIT's interpreter. LJR's baseline JIT has
| negligible startup delay, and its execution performance is on
| average 360% faster than PUC Lua and only 33% slower (but faster
| on 13/44 benchmarks) than LuaJIT's optimizing JIT.
|
| presentation by the author
|
| Deegen: A LLVM-based Compiler-Compiler for Dynamic Languages
| https://www.youtube.com/watch?v=5cAUX9QPj4Y
|
| Slides
| https://aha.stanford.edu/sites/g/files/sbiybj20066/files/med...
|
| Ongoing work documented here https://sillycross.github.io/ and
| some comments here
| https://lobste.rs/s/ftsowh/building_baseline_jit_for_lua
|
| https://github.com/luajit-remake/luajit-remake
| versteegen wrote:
| My heart sank at the description of being LLVM based. (I
| couldn't think of a worse choice for creating a JIT compiler.)
| Thankfully, they don't use LLVM at runtime! LLVM is only for
| static compilation of the JIT.
| hinkley wrote:
| I'm gonna need you to take about 15% off the top there, Squirelly
| Dan.
___________________________________________________________________
(page generated 2024-11-24 23:00 UTC)