<p><strong>TL,DR: looking for repos/bloggers/projects that focus (usually in "interpreter" contexts I guess) on highest-perf approaches to <em>runtime</em> encoding (then execution) of general-purpose turing-complete computations — whether via stack-based VMs with own minimalist opcode/bytecode 'languages' or other approaches — ie. regardless of source language, just focusing mostly on what internal representation and 'compilation' schemes allow for fastest ultimate evaluation/execution. Specifically in a Go context (because failing that, I can <em>still</em> proceed to easily locate stuff in other-langs/lang-independent landscapes if need be).</strong></p>
<p>I'm currently <a href="https://github.com/metaleap/go-corelang">implementing from papers some early-90s FP VMs</a> but it occurs to me that the FP aspect doesn't matter too much for the part where you want to (ponder how to most optimally) encode (to then perform fast-ish) 'computation in general' at runtime.</p>
<p>What I'm talking about is 'compiling' into an in-memory 'machine' state that can then (by very simple state transition rules) run fairly fast until termination (if any), eg. separating one-time transformations/validations/etc tasks from the actual computations, aka compilation (just to memory, not to an executable binary file).</p>
<p>Do any of you know of some 'advanced' projects in Go that (by their real-world nature, user base size, or project maturity) go beyond "naive eval traversal of some AST" / interpreterbook / the ubiquitous stuff that advertises itself as "demo to showcase basics focusing on readability/user-friendliness not performance"? (All useful stuff, just not what I'm looking for right here, right now.)</p>
<p>To better gauge the area where I'm looking to learn new tricks, let's say this is my "byte-code IL":</p>
<p><a href="https://github.com/metaleap/go-corelang/blob/8a5ae65b1393140d41aa956aa1c2711bb558ac1c/impl-02-gmachine-mark6/instruction.go#L20">https://github.com/metaleap/go-corelang/blob/8a5ae65b1393140d41aa956aa1c2711bb558ac1c/impl-02-gmachine-mark6/instruction.go#L20</a></p>
<p>Speed of compilation-to-it (gm-compile.go) is not the most pressing issue, vs. execution starting in (and everything below) line #34 <a href="https://github.com/metaleap/go-corelang/blob/8a5ae65b1393140d41aa956aa1c2711bb558ac1c/impl-02-gmachine-mark6/gm-basics.go#L34">https://github.com/metaleap/go-corelang/blob/8a5ae65b1393140d41aa956aa1c2711bb558ac1c/impl-02-gmachine-mark6/gm-basics.go#L34</a></p>
<p>I tried a jump-table <a href="https://github.com/metaleap/go-corelang/blob/8a5ae65b1393140d41aa956aa1c2711bb558ac1c/impl-02-gmachine-mark6/gm-basics.go#L100">L100-106</a> based on anecdotes I read about big-switch-blocks, but that slowed down execution a fair bit (approx. doubling the time cost) — even now all the instructions in separate methods was a slowdown vs. an earlier all-instructions-inlined-in-the-one-big-switch-block in <code>step()</code>.</p>
<p>In the end I'll probably go for a more minimalist IL and one more general-purpose / less graph-reduction-focused/inspired, and am sure I'll keep running into opportunities-galore to reduce compile-time generation of redundant instructions. But on a slightly higher level, I'm wondering if there have been efforts (ideally by doers tinkerers & hackers vs. PhD for comprehensibility reasons & metrics priorization) to evaluate whether a stacks+heap-based VM is really the most optimal design for "runtime-generated executable code generation", blogging-or-FOSSing enthusiasts probing various ideas from the design space and coming to conclusions or discovering tricks that would be relevant to me here. <strong>Heard of any?</strong> (I've only run into stuff that looks no less messy, perf-insensitive and "first throw" than my own stuff during my initial look-arounds.)</p>
<p>Last note, I'm sure lots of relevant stuff abounds in languages that wouldn't be very applicable/transferable to the Go backdrop here, especially in even lower-level languages — I reckon I can later on as the last resort utilize <code>unsafe</code> for the last-mile perf squeeze (I'm thinking omitting bounds checks the various stacks and instruction-stream slices etc) — but for now I'm interested in slightly higher("just above pointer-arith or C/asm-level shenanigans")-level performance considerations / investigations / benches / ponderings — cheers guys, thanks in advance for sharing what you know of that I should, too!</p>
<p>I should add that my benchmark is simply <code>factorial 15</code> essentially. This is about 1000-10000x slower (ever-varying) via the VM than compiled Go (ensuring of course that the say 15 is never constant to the compiler) — ie. the difference between 150-200ns and "anywhere between 200 and 2000 µs". I'd rather hope & aim for an at-worst 10x slow-down, rather than 1000-10000x of course ;) am doing too many allocations still, I'm sure — the <code>instruction</code> shouldn't be such a big struct either — will also manually inline <code>step</code> into <code>eval</code> obviously — <em>just looking as a side-track for other prior work out there playing in very similar sandboxes</em>..</p>
<p>As a general rule I'll never want to emit actual physical-machine code, assembly or LLVM byte-code or anything-like-that, so really-not-married to the notion of "VMs / state-transition machines emulating stack-based machines" at all. But other there any other?</p>
<hr/>**评论：**<br/><br/>sbinet: <pre><p>a few pointers:</p>
<ul>
<li><a href="https://github.com/glycerine/zygomys" rel="nofollow">https://github.com/glycerine/zygomys</a></li>
<li><a href="https://github.com/mattn/anko" rel="nofollow">https://github.com/mattn/anko</a> (used by buffalo)</li>
<li><a href="https://github.com/go-interpreter/wagon" rel="nofollow">https://github.com/go-interpreter/wagon</a> (not used much (yet?))</li>
</ul></pre>meta_leap: <pre><p>Most promising, thx! Let's not forget your own that I just happened upon: <a href="https://github.com/sbinet/go-eval" rel="nofollow">https://github.com/sbinet/go-eval</a> ;)</p></pre>
