The algorithm I'm talking about is at the very end of the book. If you start reading it from start to finish you might stop before you reach it. Certainly happened to me. Someone had to point it out for me to realize SICP had the answer all along.

https://eng.libretexts.org/Bookshelves/Computer_Science/Prog...

The explicit control evaluator. It's a register and stack machine which evaluates lisp expressions without transforming them into bytecode.

▲

hinkley 4 days ago | parent [-]

A common story with JIT languages is to go back and forth between having a bytecode interpreter and not.

The paradox is that when the interpreter is fast enough then you delay JIT because it takes longer for the amortized cost to be justified. But that also means the reasons for that high amortization cost don’t get prioritized because they don’t really show up as a priority.

Eventually the evidence piles so high nobody can ignore it and the code gets rearranged to create a clearer task list. And when that list runs out they rearrange again because now that other part is 2x too slow.

Personally I’d love to see a JIT that was less just in time. Queuing functions for optimization that only get worked on when there are idle processors. So there’s a threshold where the JIT pre-empts, and one where it only offers best effort.

▲

matheusmoreira 4 days ago | parent [-]

I wanted to preserve the "code is just lists" property of lisps. Compiling the lists away means that property is lost: the code becomes bytecode or native code instead, sacrificing lisp's soul in exchange for performance.

I want to implement a partial evaluator one day. That should go a long way to improving performance by precomputing and inlining things as much as possible.

	▲	hinkley 4 days ago \| parent [-]
		Sometimes people avoid that by making a stupidly cheap code generator that goes straight from the input file format to unoptimized machine code. Because you only have to reach a fraction of what the optimized code would achieve for throughput.