Towards a semi-performant recursive interpreter #37
Commits on Jan 27, 2019
-
-
-
-
-
-
-
-
Add
enter_call(meth, args...; kwargs...)This is essentially the new implementation of JuliaStackFrame(meth, ...). It fixes what was broken and adds keyword arg support.
-
Improve the performance of the interpreter
This almost entirely eliminates dynamic dispatch during execution of the interpreter. On a simple sum-the-elements-of-an-array test, this results in a 2x speedup. This also eliminates lookup_var_if_var.
-
-
Split JuliaStackFrame into two pieces, with code being a singleton
This avoids the need for fetching the AST and copying the CodeInfo repeatedly for the same method. This also stashes an updated pc for each frame. This seems more consistent with the notion that the state of all the locals, ssavalues, etc, is dependent on the pc, so allowing these two to diverge seems inconsistent.
-
-
Switch interpreter/compiler decision to a trait-or-stack-based approach
This is more flexible if we want to do a wider variety of things with the stack.
-
These are used when running in fully-interpreted mode to reduce the number of calls to `which`. Recently-called methods are maintained in a LRU cache at each call site; if the types match one of the cached methods, the framecode is looked up in the cache thus bypassing the need to call `which`. Building the frame itself is the biggest remaining bottleneck, in particular the allocation of storage for local variables. While this results in an order-of-magnitude improvement, the interpreter is still pretty slow, requiring of order 32us per iteration in a simple sum-a-Vector{Float64} demo. (With `--compile=no` it is more like 4us per iteration. Though I am not sure that nothing is compiled under those circumstances--- what about methods already built into the system image?) -
Switch local method tables to a "parallel" TypeMapEntry lookup
Adding an unsupported type to the CodeInfo source breaks too many things (e.g., basic-block computation, SSA usage analysis, etc.). We circumvent that by storing the local method table in a parallel structure. Some day, however, we may want to consider adding LocalMethodTable as a supported AST component; basing it on TypeMapEntry, as done here, is nevertheless a better approach than using arrays.
-
-
Memory allocation is a significant bottleneck; this reduces the burden. Cuts the execution time almost in half.
-
-
-
-
-
-
Work around some bugs in difficult cases
It's difficult stepping into inference because it uses some of the same types used here to mark slots/ssas, and as a consequence `lookup_var` and others can get confused. There also seem to be some issue wrt generated functions and/or keyword args. So these changes just prevent recursion in known-bad cases.
-
-
Lookup GlobalRefs during optimize!
This also necessitates changing how Builtins are handled, but this is more robust than the previous module/symbol check.
-
Record position prior to entering new frame
This is needed for debugging
-
For generators, index by argtypes when caching lowered code
The generator can in principle return arbitrary expressions depending on the exact type.
-
-
-
-
-
-
Add docstrings for key interpreter methods.
This also makes minor code cleanups.
-
-
-
At least module-scope code can use Ints for :gotoifnot expressions.
-
Actually copy the code in copy_codeinfo
Because we run the optimizer we don't want to contaminate the original.
-
A few improvements useful for external callers
Separates out the `JuliaFrameCode` constructor, generalizes `moduleof`, adds pc utilities
-
checkout untagged test-deps in travis script
fixup some toml files and .travis
