resistor

> * The interpreter should have a fast profiling mode (hashed counting of loop backedges) and a slower recording mode (for every instruction call the recorder first, then execute the instruction).

It already does this. The recording method is specialized for '[' (since loop headers can only be '['). All other opcodes go through a fast path that simply checks if we're in recording mode and stores to the trace buffer.

> * Don't record traces for a long time and then compile everything together.

The tricky part with this is knowing how to start up the profiler when we hit a side-exit. PC 123 may occur at multiple places in the trace tree. If we want to extend the tree on side-exit, we need to be able to recreate the path through the trace tree that led to that point. In essence, we need the compiled trace to continue updating the trace buffer. Certainly possible, but doesn't seem like a great idea offhand.

> * Sink all stores, especially updates of the virtual PC, data pointers etc. Don't count on the optimizer to do this for you.

Because I'm using tail-call based direct threading, there are no stores to the virtual PC or the data pointer. They're passed in registers to the tail-callee.

> * Due to the nature of the source language you may need to preprocess the IR or you need to teach the optimizer some additional tricks.

Yes, there's a whole range of pre-processing tricks that could be used to accelerate both the interpreter and the traces. I haven't even scratched the surface of that.

You could certainly do that, though the interface between statically JIT'd code and trace JIT'd code would get hairy. Plus, as I said above, there's simply not a whole lot of trace specialization going on in the first place, since Brainfuck lacks dynamic dispatch.

The tracing overheads are pretty huge. Running with tracing but without compilation takes 107s.

Also an example of how to implement a direct-threaded interpreter.

Some performance data from a Brainfuck mandelbrot benchmark.

Interpreter: 37.787s

Tracing JIT: 11.716s

Static Compiler: 2.402s

The tracing JIT loses out to the static compiler largely because there's no dynamic dispatch in Brainfuck for the tracer to optimize out. There's probably some performance to be recovered by tuning the tracer thresholds and minor optimizations, but I would be shocked if it ever beat the static compiler at least for Brainfuck.

Hey folks, I'm the actual author of this.

I actually work on LLVM-proper during my day job. This was just a fun exercise to demonstrate that it was possible. I also have plans to write a tutorial based on it.

Hey, I'm the actual author of this.

I actually work on LLVM-proper during my day job. This was just a fun exercise to demonstrate that it was possible. I also have plans to write a tutorial based on it.

> Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means.

They employ around two dozen LLVM developers, comprising half to two-thirds of the regular committers.