NativeJIT: A C++ expression –> x64 JIT
13 comments
·June 30, 2025kookamamie
plq
This line is part of the code that creates an AST-like structure that is then fed into the compiler. The actual multiplication is done by calling the function handle returned from the Compile method.
b0a04gl
how deterministic is the emit really. if i feed same expression tree twice,same node layout same captures. do i get exact same bytes out every time (ignoring reloc) or not. if output produced is byte stable across runs for same input graph ,that opens up memoized JIT paths.worth checking if current impl already does this or needs a pass to normalise alloc order
izabera
this looks convenient to use from c++, but the example code it generates is rather suboptimal (see https://godbolt.org/z/3rWceeYoW in which no normal compiler would set up and tear down a stack frame for that) so i'm guessing there isn't any support for optimisations? what's the advantage of this over just compiling + calling dlopen/LoadLibrary on the result?
anon-3988
Interesting, this is very similar to llvmlite.Builder which is a wrapper over llvm. I am probably going to create something similar for my Python -> C -> assembly JIT.
lhames
The LLVM ORC and Clang-REPL projects would be worth checking out if you haven't already: there's a healthy community of high performance computing folks working in this space over at https://compiler-research.org.
In particular, this talk might be interesting:
"Unlocking the Power of C++ as a Service: Uniting Python's Usability with C++'s Performance"
Video: https://www.youtube.com/watch?v=rdfBnGjyFrc Slides: https://llvm.org/devmtg/2023-10/slides/techtalks/Vassilev-Un...
Twirrim
There's also libgccjit, https://gcc.gnu.org/wiki/JIT, though all of the third party language bindings appear to be stale for it.
globalnode
that project sounds interesting as well, but what do you do with libraries in python.. have the generated C code translate back to python calls?
anon-3988
The point is not to compile entire Python programs, the point is to optimize specific parts of Python that matters. To illustrate, consider a calculating sum of 1 to N in python
def sum(N): x = 0 for i in range(N): x += i return x
There's absolute zero reason why this code has to involve pushing and popping stuff on the python virtual stack. This should be compiled into assembly with a small conversion between C/PyObject.
The goal is to get to a point where we can even do non-trivial things inside this optimized context.
Python will never be able to go down to assembly because Python support doing "weird shit" like dynamically creating modules, hell, even creating a Python file, running eval on that, and loading it as a new module. How are you even going to transpile that to assembly?
So I approach the problem the same way numba is approaching. But hopefully more modern and simpler (implementation wise). Planning on doing it using Rust and the backend should be agnostic (GCC, Clang, whatever C compiler there is)
> auto & rsquared = expression.Mul(expression.GetP1(), expression.GetP1());
This is C++, no? Why not use operator overloading for the project?