Approaches for speeding up Novika

[homonoidian]

TL;DR: write what's currently in src/novika/ in a smaller subset of Novika, which is at least theoretically compileable, and whose data structures and GC and everything else are optimized for Novika rather than being general purpose. Refer to Raku and NQP relationship.

Novika is very slow at the moment.

Rev10 is pretty much unoptimizable. Injection of minor statistics code shows that even the simpler examples like the HTML one give horrible results, mainly in terms of reads (tens if not hundreds of millions) / inserts (about 157 000, in more complex scenarios goes to tens and hundreds of millions while reads go into billions) / deletes (about 151 000). See, DSLs are bread-and-butter for Novika, they are one of its killer features. Things like $( a b c ) implementable in under a dozen words are, too, but currently they're super slow for being used anywhere important. As is everything else. The moment you try to write something serious in Novika, it slows down.

One approach for speeding up Novika is to consider Novika itself a DSL, implemented (or being contained) in a smaller subset of the language. A huge inspiration for this is Raku sitting on top of NQP, a comparatively smaller and, most importantly, optimizable language.

An important note on the subset under discussion is that it shouldn't have native-code understanding of ahead, cont, conts, stack, and everything in-between. Having one global stack will suffice. Having no access to the call (continuation) stack will also suffice. The stack should not necessarily be a block: because it is inaccessible, we could use any data structure we'd like to implement it. Blocks still exist, can be passed around, and have the same behavior as those of rev10. They're just not used as stacks by the native-code infrastructure.

This and a few other omissions should make the subset compileable (at least into bytecode) and optimizable. There is much to clarify in the idea, and much to think about, but I believe this will work.

Also, the Not-Quite-Novika thingy should be optimized to extents unimaginable, perhaps using JIT, and/or doing heavy runtime optimization, and/or doing heavy compilation work, and/or hand-writing it in assembly (although Zig, Odin, perhaps even low-level Crystal may give similar if not exactly the same results in terms of performance). As far as I know, some of these things are already done by/in MoarVM, the VM aimed at executing NQP.

Note: this is just one little idea. I didn't think about performance when I've started writing Novika, and thanks to Crystal's awesome speed, I've gotten all the way to this point. Now it's time to think a little. No matter how fast Crystal is, thousands of lines of code would cause problems if they are being run naively (as they are at the moment).