nimforum mirror - JIT landed in nlvm

arnetheduck (orginal) [2023-02-19T09:29:11+01:00] view original

After quite some time stewing in a PR, the first JIT just landed in nlvm: https://github.com/arnetheduck/nlvm/pull/45 .

The normal Nim pipeline goes something like this:


nim -> C -> IR -> object files -> linker -> executable -> run

nlvm shortens the pipeline to take out the C step:


nlvm -> IR -> object files -> linker -> executable -> run

The naive way to run code with a JIT is to simply:


nlvm -> IR -> JIT run

...and that's exactly what nlvm r yourfile.nim will do - it will compile the code to IR, then within the same process, run the code it just compiled. Of course, because we took out some steps, this will start execution faster - good for iterating on tests for example.

However, the above implementation, while simple, has a significant drawback: it must compile the full program before it starts running it - thus we come to the next part: obvious improvements that perhaps one fine day will make it to the codebase:

dynamic optimization: run the optimizer as the code is running, focusing on the bits that run the most - this is another "no-brainer" for JIT: instead of calling a function, we call as stub that counts function calls then runs the function - once we hit a threshold, we optimise the function then replace the stub with the optimised version

instead of compiling the full program, compile it incrementally: this is done by putting a stub where functions would normally be called: the stub then asks nlvm to compile the next bit of nim code and replaces itself with an implementation, similar to how the nim vm works - this technique significantly reduces the time to start running the program: in many applications there's lots of code that doesn't actually run but still must be compiled

symbol reuse from "host" nlvm process - since the code is running in the same process as nlvm and presumably using the same std library, we can skip compilation for some parts and instead reuse what's already present in the nlvm binary

interactivity - an input module (which can be either console or something that reads code from a pipe/socket) reads code on the fly, turning the JIT into a REPL: this allows amortising the "startup cost" that's required to compile the stuff that appears in every nim program (system.nim and friends).

replace the nim vm with the JIT - this would make nim compilation run a lot faster for code that relies heavily on compile-time computation: we can run the optimizer on the IR before running it in the JIT

All of the above are fun PR:s to make if getting into the weeds of compilers is something you've wanted to do but didn't know where to start :) They're also ordered roughly in implementation dependency and difficulty order.

Of course, the first cut JIT implementation has a few gaps - linking is not done yet, meaning external dependencies might not work - the GC also needs polish though I expect ARC will be more simple to support - otherwise, the easiest thing to do might be to share GC between nlvm itself and the program that's running.

Mirror of forum.nim-lang.org

9907 :: JIT landed in nlvm