Hi Timothy, On Wed, Aug 15, 2012 at 5:45 AM, Timothy Baldridge <[email protected]> wrote: > So I've been playing around with this for about a day now, and I guess I > don't understand the "vritualizable" requirements.
I also tried (although for 15 minutes only), but I gave up because the style is really too different from what we use in the Python interpreter. You have only one instance of Interpreter, and only one list that stores local variables for all functions. It's not really possible to have it work well with PyPy's JIT as far as it is now: it cannot at the same time "virtualize" the places near the top of the list (because that's where variables are currently accessed) and keep the rest of the list concrete. Instead, what we do in PyPy's Python interpreter is to have one Frame class per function, which is the obvious place to store a list of *this function*'s local variables. This would be what you need to mark "virtualizable". Closer to the style you are using is our regexp engine (pypy.rlib.rsre.rsre_core). It is based on only one "Interpreter"-like instance (in this case StrMatchContext) and has recursive invocations of the "interpreter main loop" using the same MatchContext instance. Looking for similarities, it declares as "greens" some attributes of this MatchContext (greens = [..., "ctx.pattern"]), which is a more efficient way than doing greens=["ip"] followed by "ip = self._ip" in the jit_merge_point. But it doesn't have any notion of storing all local variables of all frames of execution. At most it stores the regexp's marks, which is also a stack, but creating this stack is not optimized. I'm unsure if that model can work at all in your case without major efforts in the jit front-end. A bientôt, Armin. _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
