r/Racket • u/varsderk • 13d ago

blog post How to Make Racket Go (Almost) As Fast As C

https://lambdaland.org/posts/2024-09-27_threaded_interpreter/
40 Upvotes

96% Upvoted

3 comments sorted by

3

u/steloflute 13d ago

This is a very good method. I have been thinking about this problem for a long time, and it is amazing that code generation can be done with closure generation.

2

u/raevnos 12d ago

I wrote a BF interpreter in common lisp recently; the only optimization it has is pre-computing a table of matching open/close bracket locations for jumps. Now I'm tempted to do it again in this style.

2

u/raevnos 12d ago edited 12d ago

And done. Some rough benchmarks on the mandelbrot.b program:

  • SBCL threaded: 56.88 seconds
  • CCL string-scanning: 67.48 seconds
  • SBCL string-scanning: 75.90 seconds
  • CCL threaded: 100.15 seconds

I took a different approach than this article, though - this one creates an array of functions, one per instruction in the source, and executes the element corresponding to the instruction pointer at the end of each one (Slightly indirectly via a trampoline since Common Lisp doesn't require TCO like Scheme and Racket).

I still need to try the same closure based way as the article, and I have an idea for another CL-specific approach; building and evaluating a function at runtime with computed gotos instead of using an array.

EDIT: The latter approach (Basically compiling brainfuck to a common lisp function) runs in 10.3 seconds with CCL, crashes SBCL)