Lightening run-time code generation

Re:Lightening run-time code generation by chrisseaton on Friday May 24, 2019 @05:31PM (#20005455)

Guile is a really interesting story in that they've spent ages doing some fantastic optimisations, of the kind you usually don't do when your final execution engine is just an interpreter. I used to read Andy's blog posts about compilers unaware that the pipeline didn't actually end in machine code. Hopefully that makes the template JIT they have here enough to get good performance as the input should already be in really good shape.

I wonder why Andy didn't chose to write the JIT in Guile itself, with a binding to Lightening, rather than in C. Guile is designed to be embedded and have bindings written for it.

[ Parent | on HN ]

Re:Lightening run-time code generation by bjoli on Saturday May 25, 2019 @03:22AM (#20007582)

What I love about the guile optimizer (and some lisp optimizers in general) is that you usually have a first step of source to source optimization. That means I can write some code and see what gets inined, hoisted, unrolled and removed without having to read the bytecode assembly.

That is especially nice when writing complex macros. I remember writing a loop utility and realized I couldn't run the optimizer on code where everything was known at compile time, since guile usually optimized the loop away. (for/sum ((i (in-range 5)) i) expanded into 20 lines of code, but optimized to the integer 15 :)

[ Parent | on HN ]

Re:Lightening run-time code generation by chrisseaton on Saturday May 25, 2019 @05:01AM (#20007852)

The tricky think about a source-to-source transformation, is where do you store the meta-data to map the new source back to the old source, for the purposes of error reporting, debugging, and deoptimisation? You can't just map from one list to another as your optimisation function.

[ Parent | on HN ]

Re:Lightening run-time code generation by bjoli on Saturday May 25, 2019 @07:37AM (#20008424)

I think it is the same system as used when doing macro expansion. Macros use syntax objects with embedded metadata.

Both chez and guile usually produces proper error sites, so it is done in some fashion.

[ Parent | on HN ]

Re:Lightening run-time code generation by jlg23 on Friday May 24, 2019 @06:40PM (#20005925)

> I wonder why Andy didn't chose to write the JIT in Guile itself, with a binding to Lightening, rather than in C. Guile is designed to be embedded and have bindings written for it.

OP states "eventually I should be migrating this code over to Scheme anyway. And, of course, simple can mean fast, and I needed fast code generation.". That does not anwer you actual question (and neither does the article), but I gather this was to make the project finite (solve one and only one problem only at a time), not because the author was not aware.

[ Parent | on HN ]

Re:Lightening run-time code generation by chrisseaton on Friday May 24, 2019 @06:52PM (#20005990)

Yes that’s the statement I’m responding to “I didn't want to add more complexity to the C side of Guile“ but this is more C code. Maybe speed of generation was more important than anything else then.

[ Parent | on HN ]