4 ms·
I've been considering compiling the interpreter as a shortcut to native executables, but to Go rather than its AST since that allows reusing the existing runtim
by codr7 7y ago
I've been considering compiling the interpreter as a shortcut to native executables, but to Go rather than its AST since that allows reusing the existing runtime.
The main idea behind G-Fu is to complement Go by providing a more expressive experience while delegating the heavy-lifting. Which means that performance is far from the top priority.
- aasasd 7y agoThere's an approach to compilation where you take the input program, but instead of running it you output what the interpreter would do, as a new program. So you get meh performance but you have an executable. Here's a project doing that: https://news.ycombinator.com/item?id=19508616 https://news.ycombinator.com/item?id=19508616 This is a theory around this approach: https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...
- codr7 7y agoYep yep, we're talking about the same thing. I like to call it an inline interpreter. It's a nice compromise. The emit-logic can be kept fairly uniform and low-maintenance since its more or less identical to the regular interpreter. I got around 10% increased performance on a Forth in C for whatever that's worth. One thing to keep in mind is to use functions in the emitted code rather than simply dumping everything in a pile. Most compilers don't deal well with code piles from my experience , which makes the code both compile and run slower than it could.